Признаки проблем со спецификацией:

1) Терминологическая неопределенность – никаких многозначных слов; если термин многозначен, то его необходимо внести в глоссарий.

2) Отсутствие представлений о классификации требований – заполнить пробелы.

3) Фокусировка на деталях пользовательского интерфейса

4) Излишнее акцентирование на деталях реализации.

5) Слабая формализация процесса.

22. Спецификации требований по Вигерсу: принцип документирования Бизнес-правил.

При документировании следует придерживаться следующих принципов:

1) Использовать шаблоны в спецификации требований к программному обеспечению.

Шаблон представляет собой согласованную структуру, позволяющую фиксировать описание нужной функциональности, а также прочую информацию, касающуюся требований. Многие компании используют шаблон специальных требований к ПО, описанные в стандарте IEEE 830-1998 (IEEE, 1998b).

Шаблонные процессы должны быть масштабируемыми.

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

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

Источники требований устанавливается на основе связей, или определяются для этой цели атрибут требований.

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

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

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

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

23. Валидация требований по Вигерсу.

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

Инспекция (обзор требований)

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