Атрибуты требований

Каждое требование должно включать семь атрибутов, перечисленные ниже:

а) идентификатор – каждое требование должно включать идентификатор для облегчения трассировки требований при последовательном выполнении фаз проекта;

б) необходимость – каждое существенное требование должно быть помечено особо, так как они не обсуждаются, они обязательны; другие требования могут быть менее важны и быть предметом обсуждения для выбора их приемлемого варианта;

в) приоритет –каждое требование должно включать уровень приоритета с тем, чтобы разработчик мог обоснованно составить календарный график разработки;

г) стабильность –некоторые требования могут быть постоянными на протяжении жизненного цикла программного обеспечения; другие могут изменяться на протяжении этого жизненного цикла, поэтому такие непостоянные требования должны быть помечены;

д) источник –источник каждого требования должен быть установлен, это может быть ссылка на внешний документ или на группу пользователей, выработавших требование;

е) ясность –требование является ясным, если оно имеет одну и только одну интерпретацию, т.е. отсутствует двусмысленность, неоднозначное требование должно быть заменено другим, более конкретным;

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

- контроль за тем, чтобы требование было включено в проект;

- доказательство того, что требование принято к реализации;

- проверка того, что требование реализовано в программном обеспечении.

Но требования к программному обеспечению должны характеризоваться еще следующими тремя категориями:

- полнота;

- корректность;

- дублирование.

Полнота. Суть. Нет неучтенных требований заказчика; для каждого возможного набора входов данных или состояний должен быть определен процесс (т.е. последовательность изменений).

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

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

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