Выделение и анализ требований
После получения общего представления о деятельности и целях организаций, в которых будет работать будущая программная система, и о ее предметной области, можно определить более четко, какие именно задачи система будет решать. Кроме того, важно понимать, какие из задач стоят наиболее остро и обязательно должны быть поддержаны уже в первой версии, а какие могут быть отложены до следующих версий или вообще вынесены за рамки области ответственности системы. Эта информация выявляется при анализе потребностей возможных пользователей и заказчиков.
Потребности определяются на основе наиболее актуальных проблем и задач, которые пользователи и заказчики видят перед собой. При этом требуется аккуратное выявление значимых проблем, определение того, насколько хорошо они решаются при текущем положении дел, и расстановка приоритетов при рассмотрении недостаточно хорошо решаемых, поскольку чаще всего решить сразу все проблемы невозможно.
Формулировка потребностей может быть разбита на следующие этапы.
1. Выделить одну-две-три основных проблемы.
2. Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных.
3. Определить ограничения на возможные решения.
На основе выделенных потребностей пользователей, отнесенных к области ответственности системы, формулируются возможные функции будущей системы, которые представляют собой услуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групп пользователей (или других заинтересованных лиц). Идеи для определения таких функций можно брать из имеющегося опыта разработчиков (наиболее часто используемый источник) или из результатов мозговых штурмов и других форм выработки идей.
Предлагая те или иные функции, нужно уметь аккуратно оценивать их влияние на структуру и деятельность организаций, в рамках которых будет использоваться ПО. Это можно сделать, имея полученные при анализе предметной области модели их текущей деятельности.
При этом часто нужно учитывать, что ПО является частью программно-аппаратной системы, требования к которой надо преобразовать в требования к программной и аппаратной ее составляющим.
Правила работы с требования к ПО и более общими системными требованиями (к программно-аппаратной системе), определяются следующими двумя стандартами IEEE:
· IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7] (рекомендуемые методы спецификации требований к ПО ).
Описывает структуру документов для фиксации требований к ПО.
Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований.
o Корректность или адекватность (соответствие реальным потребностям).
o Недвусмысленность (однозначность понимания).
o Полнота .
o Непротиворечивость (согласованность между различными элементами).
o Упорядоченность по важности и стабильности.
o Проверяемость.
o Модифицируемость (оформление в удобных для внесения изменений структуре и стилях).
o Прослеживаемость в ходе разработки.
· IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications (руководство по разработке спецификаций требований к системам).
Описывает правила построения требований для программно-аппаратных систем в целом. Он выделяет следующие необходимые свойства набора требований:
o Однократное упоминание отдельных требований.
o Отсутствие пересечений между требованиями.
o Явное указание связей между требованиями.
o Полнота.
o Непротиворечивость.
o Определение ограничений, области действия и контекста для каждого требования.
o Модифицируемость.
o Конфигурируемость, удобство поддержки.
o Подходящий для определения системы уровень абстракции.
Варианты использования
Наиболее широко распространенными техниками фиксации требований в настоящий момент являются структурированные текстовые документы и диаграммы вариантов использования, о которых уже заходила речь при обсуждении RUP.
Вариантом использования (use case) называют некоторый сценарий действий системы, который обеспечивает ощутимый и значимый для ее пользователей результат. На практике в виде одного варианта использования оформляется сценарий действий системы, который будет, скорее всего, неоднократно возникать во время ее работы и имеет достаточно четко определенные условия начала выполнения и завершения.
Примеры вариантов использования:
Покупатель в Интернет-магазине выбирает товар. Для этого он может выбрать категорию товара, фирму-изготовителя или группу таких фирм и отфильтровать оставшиеся товары по цене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующем значке мышкой.
В языке UML вариант использования изображается в виде овала, помеченного именем представляемого варианта. Варианты использования могут быть связаны с участвующими в них действующими лицами (actors), изображаемыми в виде человечков и представляющими различные роли пользователей системы или внешние системы, взаимодействующие с ней.
Варианты использования могут быть связаны друг с другом тремя видами связей: обобщением (generalization), расширением (extend relationship) и включением (include relationship).
Хорошо описанный вариант использования имеет следующие атрибуты :
1. Имя, ясно говорящее о назначении варианта использования.
2. Описание. Несколько предложений, описывающих этот вариант использования.
3. Частота. Насколько часто данный вариант использования возникает.
4. Предусловия. Все условия запуска варианта использования.
5. Постусловия. Все условия, которые должны быть выполнены после успешного выполнения варианта использования.
6. Основной сценарий работы, который используется в большинстве случаев.
7. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценария указываются условия его запуска.
8. (Необязательно) Задействованные действующие лица.
9. (Необязательно) Расширяемые варианты использования.
10. (Необязательно) Включаемые варианты использования.
11. (Необязательно) Статус: "в разработке", "готов к проверке", "в процессе проверки", "подтвержден", "отвергнут".
12. (Необязательно) Допущения об окружении и ходе работы системы, использованные при разработке данного варианта. В полностью готовом варианте эти допущения либо должны быть подтверждены и стать ограничениями системы, либо должны давать начало различным сценариям работы.