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

Требования являются частью определения системы, и они в силу этого всегда есть: о них не принято говорить, что их разрабатывают (их не придумывают!), их обычно выявляют (discover) в разговорах с различными стейкхолдерами, а также в экспериментах. О требованиях хорошо думать примерно так же, как о цвете системы (который тоже может входить в требования, так что это не самый плохой пример).

Цвет – это не сама система, и это не часть описания системы (описанием для цвета был бы фрагмент текста с номером цвета из каталога цветов, или длиной волны для этого цвета, или названием цвета, или пятно краски нужного цвета, или значения интенсивностей красного-зелёного-голубого в составе цвета, и т.п.). Мы можем обсуждать цвет системы, можем выявлять пожелания к цвету у разных стейкхолдеров, а затем описывать выявленный цвет после выбора адекватного метода описания. Вот и самые разные требования как часть определения системы мы можем обсуждать, выявлять, а затем описывать после выбора метода описания.

Приключения требований на этом не заканчиваются: требования анализируют, затем их наборы делают непротиворечивыми, после чего обеспечивают к ним доступ самых разных стейкхолдеров (это обеспечение доступа и называется управление требованиями/requirements management). Всё вместе называют инженерия требований (requirements engineering). Обратите внимание, что как выявление требований входит в инженерию требований, так и управление требованиями. Управлять нельзя тем, чего ещё нет, а выявленные требования это только сырьё для дальнейшей работы.

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