10. Спецификация требований. Виды требований.

Требования – возможности или условия, которым должна соответствовать система или проект.

Согласно исследованиям 37% риска связаны с требованиями.

1. Слабое участие пользователей

2. Неполные требования

3. Изменение требований

4. Низкий уровень специалистов

5. Плохой подбор кадров

6. Остальное

Выделяют 3 вида требований:

1) Пользовательские требования

Описание на естественном языке функций и ограничений + поясняющие диаграммы.

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

2) Системные требования

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

Используют: конечные пользователи, специалисты организации заказчика, разработчики системной архитектуры и системы.

3) Проектная системная спецификация.

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

Используют: специалисты организации заказчика (не всегда), разработчики системной архитектуры, разработчики системы.

Приведенная классификация требований выполнена по уровню детализации.

11. Функциональные требования.

Функциональные требования - перечень функций, которые должна выполнять система. Должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях. Иногда указывается чего система не должна делать.

Спецификация функциональных требований должна быть комплексной и непротиворечивой. Комплексность подразумевает описание всех функций. Непротиворечивость - отсутствие противоречивых и взаимоисключающих функций.

12. Нефункциональные требования.

Делятся на 3 группы:

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

2. организационные требования - отражают политику и организационные процедуры заказчика и разработчика. (стандарты разработки ПО, требования к реализации, требования по срокам изготовления, сопутствующая документация).

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

Примеры:

1. Все взаимодействия между интерфейсом и пользователем осуществляются с помощью стандартного множества символов командного языка.

2. разработка системы и создание сопутствующей документации выполняются на основе стандартов ЕСПД.

3. Система не должна раскрывать конфиденциальную информацию о заказчике кроме его имени и номера телефона системного оператора.

Основная проблема нефункциональных требований - их сложно проверить. Часто бывает сложно реализовать требования из-за того, что они нечетко сформулированы.

Пример плохо сформулированного требования:

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

Такое требование надо детализировать:

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

Наиболее просто проверять нефункциональные требования, выраженные через количественные показатели. Кроме того жесткая фиксация требований ограничивает скорость разработки.

Типовые количественные показатели:

1. Скорость (количество транзакций в секунду, время реакции на действия пользователя, время обновления экрана.

2. Размер (мегабайт ОЗУ, кол-во модулей памяти).

3. Простота эксплуатации (время обучения персонала, количество статей в справочной системе).

4. Надежность (время между двумя последовательными появлениями ошибок в системе)

5. Устойчивость к сбоям (время восстановления системы после сбоя, процент событий приводящий к сбоям, вероятность порчи данных при сбое).

6. Переносимость (процент машинно-зависимого кода, количество машинно-зависимых подсистем).

Нефункциональные требования часто конфликтуют с другими требованиями. Функциональные и нефункциональные требования должны быть разнесены по разным разделам документа.