Unetway

Спецификация требований

Списки требований

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

Преимущества

  • Обеспечивает контрольный список требований.
  • Обеспечивает договор между заказчиками и разработчиками.
  • Для большой системы может обеспечить описание высокого уровня.

Недостатки

  • Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.
  • Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования
    • Эта абстракция лишает возможности видеть, как требования связываются между собой или работают вместе.
    • Эта абстракция мешает верно, расположить требования по приоритетам; в то время как список, действительно облегчает приоретизацию отдельных пунктов, удаление одного пункта из контекста может сделать весь сценарий использования или деловое требование бесполезным.
    • Эта абстракция увеличивает вероятность неверного трактования требований; поскольку, чем больше число людей будет их читать, тем большее будет число (различных) интерпретаций системы.
    • Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.
  • Эти списки создают ложное чувство взаимопонимания между заинтересованными лицами и разработчиками.
  • Эти списки дают заинтересованным лицам ложное чувство защищённости, что разработчики должны достигнуть определённых вещей. Однако, из-за природы этих списков, они неизбежно упускают важные требования, которые будут выявлены позже в процессе. Разработчики могут использовать новые требования для пересмотра сроков и условий в их пользу.

Альтернативы спискам требования

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

Измеримые цели

Лучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут выявлены истинные деловые цели. После этого заинтересованные лица и разработчики могут разработать тесты, измеряющие, какой уровень каждой цели был достигнут. Такие цели изменяются медленнее, чем длинный список определённых, но неизмеримых требований. Как только маленький набор критических, измеримых целей установлен, быстрое прототипирование и короткие этапы разработки могут дать заинтересованным лицам реальную ценность ещё до окончания проекта.