Специальные требования

В этом разделе, являющимся сердцевиной спецификации, описываются специальные требования к программному продукту. Приемлемость программного продукта с точки зрения пользователей будет оцениваться на основе анализа соответствия фактических потребительских свойств программного продукта специальным требованиям. Каждое требование должно иметь уникальный идентификатор. Возможность обеспечения трассируемости требований, соответствующих этой стадии проекта, требованиям, в которые они преобразуются на последующих стадиях проекта, зависит от того, будет ли каждое требование иметь уникальный идентификатор. Для того чтобы программный продукт оказался приемлемым с точки зрения конечного пользователя, в первую очередь должны быть реализованы обязательные (ключевые) требования. Если требование относится к классу обязательных, это должно быть отмечено соответствующим значком. Не ключевые (желательные) требования должны быть маркированы по степени желательности реализации (например, по шкале 1.2.3).

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

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

Нестабильные требования также должны быть помечены. Содержание этих требований определяется информацией, поступающей по каналам обратной связи о результатах формирования требований пользователей, системных требований, а также результатах проектирования архитектуры. Обычным приемом выделения нестабильных требований является маркировка их признаком «TBC» (To Be Confirmed – требует подтверждения). Должны быть установлены источники возникновения требований (т.е. требованиям должны быть присвоены «имена собственные»). Этим источникам могут быть присвоены обозначения, формируемые на базе идентификаторов системных требований; на основе документирования перекрестных ссылок; либо даже используя имена тех персон, с которыми ассоциировано требование. Обратная трассируемость зависит от того, насколько ясно определены ссылки на источники требований.

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

• «...программный продукт будет работать хорошо»;

• «...программный продукт будет вести себя дружественно по отношению к пользователю»;

• «...обычно программная система выдает результаты в течение 10 секунд»

не являются верифицируемыми, так как термины «хорошо»; «дружественное по отношению к пользователю» и «обычно» не имеют объективной интерпретации. Такое же утверждение как: «...выходной результат будет получен за время, не превышающее 20 сек., в случае возникновения события Х в 60% случаев; и будет получен за время, не превышающее 30 сек., в случае возникновения события Х в 99% случаев» верифицируемо, т.к. представлено в конкретных терминах и допускает проверку путем измерений.

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

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