Инженерия требований

Инженерия требований (Requirements Engineering, RE) — поддисциплина системной инженерии, которая занимается разработкой требований.

Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.

Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.

Инженерия требований включает в себя:

• Учет требований
• Проверку непротиворичивости требований

Классическая инженерия требований: http://www.requirementsnetwork.com/

Управление требованиями

Инженерия требований должна начинаться с управления требованиями.

Требование — это приписанное к части системы утверждение (assertion).

Контрольная точка — это достижение этого требования к какому-то моменту.

Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.

Инженер по требованиям

Кто должен делать требования?

1. Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: “вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим”. Это неверная позиция. Заказчик может представить только свои нужды, а не требования к системе. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить “требования стейкхолдера”. Но это ещё не требования к системе.
2. Разрабатывает требования обычно команда проекта, они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы: часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер.

Обязанности инженера по требованиям

Инженер по требованиям (вид системного инженера) занимается тем, что:

• выявляет стейкхолдеров,
• узнает потребности стейкхолдеров (нужды, needs),
• разрабатывает требования стейкхолдеров,
• проводит переговоры между стейкхолдерами в тех случаях, когда их требования противоречивы, или когда команда проекта оказывается не в состоянии их выполнить и требования нуждаются в коррекции,
• согласует требования стейкхолдеров между собой,
• готовит требования к системе.

Качества инженера по требованиям

Инженер по требованиям должен быть:

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

Моделеориентированная инженерия требований

В инженерии предприятий (enterprise engineering) модели требований (к предприятию/к архитектуре предприятия) часто называют мотивационными моделями (motivation не только «движущая сила, побуждение», но и обоснование – reason, justification).

Моделеориентированность (как шаг к формальным требованиям) хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование). Требования должны документироваться и затем использоваться для проведения испытаний (проверок и приёмок) как чеклисты.

Примеры языков для моделей требований

• GRL,
• подход i*),
• Motivational Extension 2.0,
• Model-based requirement discovery от Яна Александера.

Программное обеспечение

• Modelica
• IBM Rational DOORS
• 3SL Cradle
• Requirements Quality Suite
• ReqView

Другие практики с использованием моделеориентированных требований

• Test driven development – это когда разработка системы начинается с того, что требования разрабатываются сразу в виде тестов (исполняемых!). Увы, качество разработки по TDD получается примерно такое же, как и при любых других видах разработки – что не снижает популярности этого подхода. Требования как правило разрабатываются с помощью сценариев (use cases), в которых рассказывается, что делает система в ответ на последовательности действий (сценарии) с участием разных стейкхолдеров.
• Использование user story в формулировках по шаблону (Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post): Я как [стейкхолдер] хочу, чтобы система [формулировка требования], для того чтобы [хотелка-для-using-system].

Целеориентированная инженерия требований

Все целевые-обосновательные подходы образуют анклавы в разных частях V-диаграммы:

• GORE в начале,
• architecture/design rationale поближе к середине,
• assurance case в конце.

Вся эта “целеориентированность” и “обоснованность” выражает обычный ход рассуждений (reason), доказательств (proofs) и аргументирования (argumentation). Литературы на эту тему более чем достаточно, достаточно вспомнить про дедуктивный и индуктивный метод.

Еще более правильно считать, что “это просто логика, сынок” — именно логика озабочена правильностью рассуждений и аргументации.

Понятно, что вариаций на эти темы более чем достаточно — особенно, если учесть, что логика это раздел гносеологии/эпистемологии (а в гегелевско-марксистском понимании так и вообще это про одно и то же: поищите слово “логика” на этой странице).

Традиционно аргументирование развивалось не только в науке, но и в юридической практике — поэтому первые работы, на которые опираются очень многие “инженерные” подходы, касаются тематики legal argument, причем в варианте case-based theory (а не rule-based, см. статью аж 1997г. С тех пор в этой сфере довольно далеко ушли, и не факт, что инженеры или даже софтовые инженеры продвинулись дальше).

Международные общества

• IREB (International Requirements Engineering Board)
• ReSG (Requirements Engineering Specialist Group, в British Computer Society)

Профессиональная сертификация

• CPRE

Журналы

• http://re-magazine.ireb.org

Стандарты инженерии требований

• IEC/IEEE/ISO 15288:2015 – задаёт инженерию требований в других дисциплинах (инженерии системной архитектуры, управления конфигурацией и т.д.)
• IEC/IEEE/ISO 29148:2011 – специализированный по требованиям, на базе ISO 15288
• ISO/IEC TR 24766:2010
• SEBoK – стандарт, используемый в сертификации системных инженеров

Взаимосвязь основных стандартов инженерии требований отражена на диаграмме:

См. также

• Стандарты представления самих требований