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

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

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

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

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

  • Разработка требований
  • Управление требованиями

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

  • CPRE


Журналы


Стандарты

  • ISO/IEC/IEEE 15288:2015 – задаёт инженерию требований в других дисциплинах (инженерии системной архитектуры, управления конфигурацией и т.д.)
  • ISO/IEC/IEEE 29148:2011 – специализированный по требованиям, на базе ISO 15288
  • SEBoK – стандарт, используемый в сертификации системных инженеров
  • Стандарты машинного представления требований
    • SysML
    • AP233
    • RIF
    • ISO 29148
    • ITU Z.151 (URN=GRL+UCM) и другие из GORE (i*, BMM, ArchiMate, MBRD, Planguage): выражение оппозиции цели-средства (ends – means)
    • ISO 15926


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

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


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


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


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

  • Modelica
  • Julia


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

  • 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].
Источник — «http://sewiki.ru/index.php?title=Инженерия_требований&oldid=85»