Требования к системе: характеристики хороших требований

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

  1. Недвусмысленное;
  2. Проверяемое;
  3. Четкое/краткое;
  4. Точное;
  5. Понятное;
  1. Осуществимое;
  2. Независимое;
  3. Атомарное;
  4. Необходимое;
  5. Абстрактное от реализации.

Подробнее перечисленные характеристики требований и характеристики, которыми должен обладать набор требований, описаны ниже.

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

Пример плохого требования: REQ1 Система не должна принимать пароль длиннее 15 символов.

Данное требование не проясняет что же должна делать система:

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

Пример хорошего требования: REQ1 Система не должна принимать пароль длиннее 15 символов. Если пользователь введет больше 15 символов, система должна отобрать сообщение об ошибке с просьбой исправить пароль.

2. Проверяемое – тестировщики должны иметь возможность проверить правильно ли требование реализовано в системе.  Для этого требование должно быть четким, точным, недвусмысленным.

Пример плохого требования: REQ1 Поиск в системе должен осуществляться по имени, фамилии пользователя и т.д.

В данном примере критерии поиска должны быть раскрыты полностью. Иначе нельзя проверить выполняется ли требование в системе.

3. Четкое (краткое) – требование не должно содержать лишней информации. Оно должно быть изложено четко и просто.

Пример плохого требования: REQ1 Пользователь иногда может вводить код аэропорта, который должен определяться системой. Но также иногда код аэропорта должен заменяться названием ближайшего города, таким образом пользователю не требуется знать код аэропорта, но система по прежнему должна знать код аэропорта.

Это требование может быть изменено следующим образом: REQ1 Система должна определять аэропорт как по коду аэропорта так и по названию города.

4. Точное – требование должно содержать в себе истинные факты.

5. Понятное – требование не должно содержать грамматических ошибок, должно быть изложено последовательно.

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

7. Независимое – для понимания требование не нужно знать других требований.

Пример плохого требования: REQ1 Список доступных рейсов должен содержать информация о номере полета, времени посадки и приземления. REQ2 Они должны быть отсортированы по цене.

8. Атомарное – требование должно содержать одну связанную сущность. Пример плохого требования: REQ1 В системе должна быть предусмотрена возможность забронировать полет, купить билет, зарезервировать номер в отеле, арендовать машину.

9. Необходимое – заинтересованные лица должны нуждаться в данном требовании.

10. Абстрактное – в требовании не должно содержаться информации о том, как оно будет реализовано.

Также существуют определенные характеристики, которыми должен обладать набор требований:

а. Постоянное – не должно быть конфликтов между требованиями.

b. Неизбыточное – каждое требование должно быть описано один раз и не должно содержать в себе других требований.

c. Полное – требование должно быть определено для всех возможных ситуаций.

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

Модифицируемость – если требование атомарно и полное, оно модифицируемо.

Трассировка (прослеживаемость) – если требование атомарно и имеет уникальный идентификатор, оно прослеживаемо.

3 комментария

  1. В принципе, характеристики понятны и ничего нового нет, но за практические примеры огромное спасибо 🙂

    1. Несмотря на то, что характеристики понятны и ничего нового нет, не все следуют данным принципам. А стоило бы 😉

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *