Инженерия требования, как и в целом системная инженерия, может быть документоориентированная (олдскул), может быть моделеориентированная (ньюскул).
Прошлое поколение – это когда вся информация о системе лежит в документах. Требования – тоже в каких-то документах, не важно, бумажных или электронных. Скажем, бумажка, в которой зафиксирован список требований. А скорее не одна бумажка, а несколько разных, плюс к ним еще кучка документов с изменениями требований. И всё это в кучу, в целостную картинку сводится только в голове системного инженера.
Моделеориентированная системная инженерия– это когда есть модель, она в компьютере где-то лежит. В любой момент можно сделать представление этой модели на экране компьютера и посмотреть состояние на текущий момент. Здесь же и конфликты какие-то видно сразу. Думать проще, когда модель есть. И коммуницировать проще – не надо махать руками, чтобы показать что-то, можно просто показать представление модели. Ну а если нужны документы - их можно генерировать на основе модели. При этом модель будет первична, а документ лишь отображает какие-то части модели.
В моделеориентированной инженерии требований требование – это модель (или кусок модели или её элемент), с указанием на то, что система должна следовать этой модели. Требование состоит из 3 частей:
1. Модель
2. Деонтический оператор. Он предписывает: “должен”, “не должен”, “must”, “recommended”, “insist” и т.п.
3. Стэйкхолдер, заинтересованная сторона. Это тот, чьё требование. При этом должно проверяться, имеет ли он право на то, чтобы говорить, что должно быть так.
Ох, запутанно как-то написал… Ну ничего, как поглубже вникну в эту связку документы vs модели – напишу понятней.
–