Однозначные требования

Требование является однозначными тогда и только тогда, когда его можно однозначно интерпретировать [4]. Неоднозначность требования представляет собой не меньшую проблему, чем правильность требования. Если формулировка требования может по-разному пониматься разработчиками, пользователями и другими участниками проекта, это может привести к разработке системы, полностью отличающейся от того, что хотел пользователь. Данная проблема может возникнуть всегда, когда требования пишутся на естественном языке, так как члены разработчики и заказчики настолько привыкли к своему пониманию слов и фраз, что им может никогда не прийти в голову, что другие могут интерпретировать слово иначе. Одним из способов избежать неоднозначности состоит в том, чтобы вместо естественного языка использовать «формализованные» спецификации требований. Формальность спецификации достигается за счет строгого шаблона документа и использования правил для описания требований. Правила описания требований представляют собой шаблоны требований и типовые решения требований. К описанию шаблонов и типовых решений требований вернемся позже в данной работе. Существуют и другие методы борьбы с неоднозначностью, такие как

• эвристика запоминания,

• метод ключевых слов,

• метод ударения,

• графики и рисунки.

Так как приведенные методы являются дополнительными и требуют от команды множества усилий на изучение, в данной работе не расписывается их подробное содержание. Ознакомиться с представленными методами можно в [1 (Глава 26)].

Полные требования

Понятие полноты требований используется для оценки спецификации требований или некоторого набора связанных требований. Стандарт IEEE 830 – 1998 так интерпретирует полноту требований:

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

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

Непротиворечивые требования

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

Ранжированные требования

В качественном наборе требований разработчики, клиенты и другие заинтересованные лица упорядочивают требования по их важности для клиента (приоритету) и стабильности [4]. Процесс ранжирования требований полезен для управления масштабом проектом. Под масштабом проекта понимаются его ресурсы: персонал, бюджет и сроки. Если недостаточны человеческие ресурсы, чтобы в отведенное время и бюджет реализовать все требования, необходимо знать какие требования являются не столь обязательными, а какие критичными для пользователя или заказчика. При использовании атрибутов требований, таких как стабильность, приоритет, сложность реализации, риски аналитики могут ранжировать требования, а руководитель проекта планировать проект в соответствии с требованиями [5].