Практика 1

Практика 1

. ТРЕБОВАНИЯ К ИНФОРМАЦИОННЫМ СИСТЕМАМ. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ

4.1. Типы требований

Работа с требованиями является важнейшей составной частью процесса создания ИС. Это очень непростой этап, и ошибки, допущенные при определении требований к ИС, очень дорого обходятся разработчикам, поскольку весь процесс проектирования или его существенную часть приходится проводить заново. Следует отметить, что выбор основных архитектурных решений осуществляется на этапе формирования требований. Правильное определения требований и эффективное управление требованиями — это краеугольные камни успеха любого IT-проекта. До настоящего времени сохраняется ситуация, при которой около 10 % проектов оканчиваются крахом и не менее 20 % существенно превышают смету расходов по причине неправильного определения требований к системе [58]. В последние годы практически все разработчики уделяют самое пристальное внимание работе с требованиями, но ситуацию это не спасает, поскольку дело не в том, что аналитики не учли требования тех или иных заинтересованных сторон, а в том, что требования постоянно изменяются. Прежде всего, изменяется окружение, в котором работает или должна работать система: на рынке появляются конкурирующие продукты, появляются новые ИТ-технологии и т.д. Таким образом, аналитик, вырабатывающий требования к системе, должен прогнозировать развитие ситуации и учитывать возможность появление новых требований. Основным документом, регулирующим работу с требованиями, на момент написания книги является стандарт [59]. Подробное описание возможных подходов к работе с требованиями можно найти в [60, 61, 62].

В соответствии со стандартом[59], требование — это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо, измеримо и необходимо для приемки продукта или процесса заказчиком.

Требование должно обладать следующими свойствами:

1. Единичность — требование описывает одну и только одну сущность.

2. Завершенность — требование полностью определено в одном месте.

3. Реализуемость — требование может быть исполнимо с учетом возможностей доступных технологий и ресурсов.

4. Непротиворечивость — требование не противоречит другим требованиям и соответствует документации.

5. Атомарность — требование нельзя разделить на более мелкие требования.

6. Отслеживаемость — требование полностью или частично соответствует бизнес-потребностям заинтересованных лиц.

7. Актуальность — требование не стало устаревшим с течением времени.

8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Требование должно выражать объекты и факты, а не субъективные мнения. Возможна единственная интерпретация требования. Определение не должно содержать нечетких фраз. Использование отрицательных и составных утверждений запрещено.

9. Проверяемость — возможность составление теста, с помощью которого можно проверить выполнено ли требование.

10. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована, однако это не исключает ранжирование требований. Необязательное требование — противоречие самому понятия требования.

Основные типы требований. На рис. 4.1 приведена укрупненная схема классификации требований.

Рис. 4.1. Классификация требований

Требования могут быть сформулированы на 3 разных уровнях: бизнес-уровне, пользовательском уровне и системном уровне.

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. Бизнес-требование – это описание целей, которые должны быть достигнуты за счет создания системы.

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии, т.е. требования пользователей описывают то, что они могут делать с помощью системы.

Термином системные требования (system requirements) обозначают высокоуровневые требования, как ко всей ИС, так и к отдельным подсистемам. Системные требования к подсистемам формируются на основе требований ко всей системе. Системные требования формулируются в терминах, которыми пользуются разработчики системы.

Можно выделить 4 основные группы источников требований (заинтересованных сторон): потенциальные пользователи ИС, внутренние требования к продукту, внешние требования к продукту. Потенциальные пользователи, это те, кто непосредственно работает или будет работать с системой. Внутренние требования – это требования организации, например, ИС должна позволить организации выйти на новый для нее рынок. Это, как правило, бизнес требования. Доменные требования отражают требования окружения, в котором работает создаваемая ИС. Доменные требования формулируются в терминах предметной области и могут использовать профессиональную терминологию. Например, это могут быть специфические требования ко всем системам военного назначения, или всем медицинским системам. Внешние требования – это требования со стороны государственных и негосударственных организаций. Чаще всего они выражаются в форме стандартов.

С точки зрения предмета требований, их принято делить на функциональные и нефункциональные требования.

Функциональные требования. Функциональные требования описывают, что должна делать ИС в соответствии с ожиданиям потенциальных пользователей ИС. Функциональные требования описываются на языке понятном пользователю. Обычно основные функциональные требования описываются на естественном языке с использованием терминологии принятой в соответствующем бизнес сообществе. Для описания более тонкого поведения системы, например, работы с исключениями, могут использоваться и формализованные описания. Функциональные требования ко всей ИС могут носить разноплановый характер. С одной стороны, это могут быть требования ко всей системе, а, с другой стороны, требования которые относятся к конкретной подсистеме, но являющиеся важными с точки зрения конкретного пользователя. Надо заметить, что формулирование функциональных требований это процесс, в котором, с одной стороны, участвуют конечные пользователи (обычно это их представители, которые уверены, что знают истинные требования конечных пользователей), а, с другой стороны, представители разработчиков. Часто заказчики выдвигают крайне трудно реализуемые требования, а разработчики стремятся их интерпретировать таким образом, чтобы их можно было реализовать максимально просто.

К совокупности функциональных требований предъявляются 2 основных требования – список требований должен быть полным, а требования не должны быть противоречивыми. Полнота предполагает, что список требований является исчерпывающим, и он не будет расширяться, а непротиворечивость предполагает, что требования не должны быть взаимоисключающими. На первый взгляд эти требования кажутся естественными и даже тривиальными, но на практике при проектировании крупных ИС полный перечень непротиворечивых требований оказывается практически невозможно. Первая причина состоит в том, что при составлении списка требований, включающих сотни, а иногда и тысячи позиций очень легко пропустить те или иные требования. Вторая причина состоит в том, что список требований обычно готовится некоторой командой, члены которой могут иметь свои точки зрения на требуемую функциональность, а могут продвигать и собственные интересы.

Нефункциональные требования. Это требования, которые напрямую не связаны с конкретными сервисами, которые проектируемая ИС предоставляет конечному пользователю. Нефункциональные требования можно рассматривать как ограничения, накладываемые на конкретные свойства ИС, например требования, связанные с поддержанием интерфейсов с определенными внешними системами, такими как, например, MS Office. К нефункциональным требованиям относят такие требования как время реакции, надежность, удобство обслуживания и т.п. Такие нефункциональные характеристики как производительность, безопасность, доступность относятся ко всей ИС. В определенных ситуациях нефункциональные характеристики могут оказаться даже более важными, чем функциональные. Например, если графический редактор не удобен в работе, то наличие некоторой дополнительной функциональности не сможет обеспечить его успех на рынке. Иногда бывает трудно определить, какой именно компонент реализует ту или иную функцию, но еще труднее это сделать применительно к нефункциональным требованиям. Достаточно часто одно функциональное требование может определить архитектуру всей системы. Типовая проблема, которая появляется при работе с нефункциональными требованиями, состоит в том, что очень часто потенциальные пользователи формируют их в форме целей. Например, пользователь считает, что проектируемая система должна быть проста в использовании, или система должна быть спроектирована таким образом, чтобы минимизировать ошибки оператора. Очевидно, что проверить удовлетворяет ли система таким требованиям невозможно. Поэтому при формулировании нефункциональных требований насколько это возможно надо использовать метрики, которые можно проверить. Например, указанные выше требования можно сформулировать следующим образом. Для подготовки оператора достаточно 16 часового курса, после прохождения которого оператор допускает в течение смены не более 3 ошибок.

Однако на практике потенциальным пользователям бывает трудно сопроводить свои требования соответствующими метриками, а для таких нефункциональных характеристик часто просто трудно придумать адекватные метрики. Например, достаточно сложно определить количественно ремонтопригодность системы. Пользователи должны понимать, каким образом они могут интерпретировать подобные метрики в понятных им бизнес-терминах. Заказчики системы хотят знать каким образом та или иная нефункциональная характеристика отобразится на стоимости системы. Нефункциональные требования могут быть связаны между собой и вступать в конфликт между собой и функциональными требованиями. Например, в качестве в качестве одного из требований безопасности выступает требование, в соответствии с которым пользователи получают доступ к системе только с помощью пластиковой карты, т.е. все рабочие станции должны иметь карт-ридеры. При этом одновременно требуется, чтобы пользователи могли получать удаленный доступ к системе с помощью принадлежащих им ноутбуков и планшетов. Очевидно, что для этой группы пользователей придется обеспечить другой механизм контроля доступа.

При составлении документации по требованиям к системе не рекомендуется очень жестко разделять функциональные и нефункциональные требования, поскольку в этом случае оказывается сложно проследить взаимосвязи между ними.

Практика 1