Анализ требований

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

Цель анализа – качественно и подробно описать требования, позволяющие оценить затраты на проект, а техническому персоналу начать проектирование, сборку и тестирование.

В процессе анализа требования должны быть классифицированы по следующим признакам:

1. Функциональные/Нефункциональные

2. Внутренние/Внешние

3. Требований к Процессу/Продукту

4. Изменчивость/Стабильность

Анализ требований проходит следующие этапы:

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

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

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

4. Анализ осуществимости требований. Анализируется, насколько реально реализовать каждое требование при реализационных затратах и с приемлемой производительностью в предполагаемой среде. Рассматриваются также риски, связанные с реализацией каждого требования, включая конфликты с другими требованиями в зависимости от внешних факторов, и препятствия технологического характера

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

К таким моделям относят:

- Диаграммы потоков данных DFD;

- Диаграммы «Сущность-связь»;

- Диаграммы переходов состояний (которые также называют автоматами);

- Карты диалогов;

- Диаграммы классов;

- Диаграммы последовательностей;

- Диаграммы взаимодействия, таблицы решений, деревья решений.

6. Создание словаря терминов – в нем собираются определения всех элементов и структур данных, связанные с системой, что позволяет всем участникам проекта использовать согласованное определение данным. На стадии работы над требованиями, словарь должен содержать определения элементов данных, относительно к предметной области, чтобы клиентам и разработчикам было проще общаться.

7. Распределение требований по системам. Включает несколько подсистем, следует соразмерно распределять между программными, аппаратными и операторскими подсистемами, и компонентами. Как правило, это работа системного аналитика, или разработчика. Здесь применяются технологии развертывания функции качества QFD (Quality Function Deployment) – методика, соотносящая возможности и атрибуты качества продукта с их значимостью для клиента. Она позволяет аналитически выявить функцию, которая максимально удовлетворяет потребности клиента.

QFD-технология рассчитана на три класса требований:

1) Ожидаемые (те, о которых клиента может не упомянуть, но будет расстроен, если не увидит).

2) Обычные.

3) Отдельные (специальные) – обеспечивают удобство работы клиента, но отсутствие которых не влечет санкции со стороны клиента.

21. Спецификации требований по Вигерсу.

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

Чаще всего для описания проектов в части требований, используются три основные документа-спецификации:

1) Определение системы (System Definition) – содержание этого документа определяет высокоуровневые требования, часто ??????? цели, для достижения которых создается система. Принципиальный момент то, что такой документ создается и описывается с точки зрения домене предметной области, и в следствии, изложение требований ведется в терминах ПрО.

2) Системные требования (System Requirements) – документация, описывающая программную систему в контексте системной инженерии, описывает деятельность системных инженеров.

3) Программные требования (Software Requirements) – устанавливает основные соглашения между заказчиком и разработчиком, в отношении того, что будет делать система, и что от нее стоит ожидать. Этот документ может включать процедуру проверки ПО на соответствие предъявленных к нему требований, вплоть до содержания планов тестирования, характеристик, определения качества, и методы его оценки, к вопросу безопасности. Главная задача – чтобы содержание спецификации не допускало разночтений и интерпретации.