Доклад А.Левенчука "Тренды в инженерии требований" на 104 заседании Русского отделения INCOSE, 23 сентября 2015

1. Тренды в инженерии требований
23 сентября 2015

2. На что менеджер должен добавить денег?
2
Стадия обнаружения
ошибки
Стоимость
исправления
Требования x1 (единица
отсчета)
Проектирование x5
Строительство x12
Проверки X40
Эксплуатация X250
Данные INCOSEЗаповедь системной инженерии:
перетаскивай затраты с логического конца ЖЦ на его начало!!!

3. Инженерия требований
• Практика инженерии требований
– Дисциплина инженерии требований
(стандарты)
– Технология инженерии требований (софт,
оргструктура, репозитории документов)
– Дисциплинированные и тренированные люди
(профессионалы)
3

4. Дисциплина инженерии требований
• Поддисциплина системной инженерии
• Поддисциплина программной инженерии (самые серьезные
разработки сейчас идут там)
• Есть свои поддисциплины
• ВУЗовские учебные курсы (но не полноценная магистерская
специализация)
• Международные общества – IREB (International Requirements
Engineering Board), https://www.ireb.org, ReSG (Requirements
Engineering Specialist Group, в British Computer Society)
• Профессиональная сертификация (CPRE, 27тыс. сертификатов)
• Конференции – в этом году 23я International Requirements
Engineering Conference (http://requirements-engineering.org/),
множество по требованиям к софту (типа REFSQ, conference on
Requirements engineering: foundation for software quality, в этом
году 21я),
• Журналы – Requirements Engineering Magazine (http://re-
magazine.ireb.org/) 4

5. Инженерия требований: практики
(классическое понимание, устарело)
http://www.processimpact.com/articles/telepathy.html
• Инженерия требований
• Разработка требований
• Выявление требований
• Анализ требований
• Спецификация требований
• проверка
• Управление требованиями

6. Тренды отхода от классики
• отдельные подпрактики для каждого вида (извлекать
stakeholder needs нужно не так, как открывать требования
стейкхолдеров, и не так, как формулировать системные
требования), трассировки между видами требований – ISO
15288:2015 только что реализовал очередное разделение,
хотя и не слишком формально
• Проверка и приёмка требований, не только проверка
• Моделеориентированность [специальное понимание,
вдобавок к обычному пониманию]: упор на выражение
намерения и интереса, документирование источника
(стейкхолдеров) и организационного контекста (а не только
целевой системы)
• Работа с требованиями это отнюдь не «выявление и запись»
– это прежде всего решение противоречий между
стейкхолдерами, активная работа. Инженеры по
требованиям – не аналитики, не наблюдатели, а деятели!

7. Умения инженера по требованиям
(подробнее: http://ailev.livejournal.com/810548.html)
• Быть лидером (leadership) – упаковывать исполнителей
с их личными интересами в культурно-обусловленные
позиции стейкхолдеров. Работает с людьми.
• Быть социотехником – найти и извлечь все требования
из человека в позиции. Работает с диаграммами
целеполагания (early requirements engineering), т.е.
грамотный по Alan Key [моделирует].
• Быть инженером – понимать архитектуру, разбираться в
инженерных обоснованиях, читать чертежи и
моделировать...
• Изменять ситуацию: «решать все проблемы со
стейкхолдерами», проводить переговоры по
согласованию позиций.
7

8. Стандарты инженерии требований
Приказ Госкорпорации «Росатом» от 26.12.2008 г № 710 «О подготовке к внедрению в организациях
Госкорпорации «Росатом» международных стандартов ISO/IEC 15288:2008 и ISO 15926». – имеет
историческое значение, стандарты поменялись.
Новости:
• 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
– …..
Проблема: что выразишь одними иероглифами, не найдёшь в другом наборе иероглифов.
• Если отрасль: поддерживать все стандарты, если предприятие – придётся выбрать!
8

9. Практики ЖЦ требований (по ISO 15288:2015) - 1
• 6.4.2 Stakeholder needs and requirements definition process
• Подготовиться (идентифицировать стейкхолдеров, определить стратегию определения
потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и
сервисы)
• Определить потребности стейкхолдеров (определить контекст использования,
идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности,
определить потребности стейкхолдеров и их обоснование)
• Разработать Концепцию функционирования (operational concept) и другие концепции
жизненного цикла (определить набор сценариев, определить взаимодействия пользователей
и системы)
• Преобразовать потребности стейхколдеров в требования стейкхолдеров (идентифицировать
ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все
функции для требований качества, гармонизировать требования стейкхолдеров)
• Анализировать требования стейкхолдеров (анализировать полное множество требований
стейкхолдеров, определить критические показатели результативности, которые позволят
оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать,
устранить все проблемы и противоречия со стейкхолдерами)
• Управлять определением потребностей стейкхолдеров и требованиями (получить явное
согласие на требования стейкхолдеров, поддерживать трассировку потребностей и
требований, обеспечивать сведения по базисам)
9

10. Практики ЖЦ требований (по ISO 15288:2015) - 2
6.4.3. System requirement definition process
• Подготовиться (определить функциональную границу системы в терминах
поведения и свойств, которые нужно обеспечить, определить стратегию
определения системных требований, идентифицировать и спланировать
обеспечивающую систему для определения системных требований, получить
или купить обеспечивающую систему)
• Определить системные требования (определить каждую функцию, которую
должна выполнять система, определить необходимые реализационные
ограничения, определить системные требования, которые относятся к риску,
критичности системы или критические характеристики качества, определить
системные требования и их обоснование)
• Анализировать системные требования (анализировать полный набор
системных требований, определить критические характеристики качества,
которые делают возможным оценку технического достижения, предоставить
требования системы подходящим стейкхолдерам для рассмотрения, решить
все возникшие проблемы с требованиями)
• Управлять системными требованиями (получить явное соглашение по
системным требованиям, поддержать трассировку по системным
требованиям, обеспечить информацию базиса)
10

11. Инженерия требований в других
технических процессах (ISO 29148:2011)
Список процессов уже другой в 2015, но основная
идея сохраняется:
• Архитектура (основные решения)
• Системный анализ (альтернативные решения,
моделирования)
• Проверка (против требований)
• Приёмка (против потребностей)
• Управление требованиями (управление
конфигурацией, изменениями, информацией,
измерения требований)
11

12. 12
Практики в MBRD
Анализ
заинтересованных
сторон
Моделирование
контекста
Моделирование
целей
Приоритезация
Написание требований,
повторное
использование,
шаблоны, стандарты
Анализ
обоснований
Анализ
развилок
Анализ
словаря
Анализ
измерений
Моделирование
сценариев
23
(с) Ян Александер, 2010

13. Предупреждение про стандарты
• Стандарты обеспечивают прогресс, но не везде и не
всегда!!!
• Стандарты ISO обычно сходу устаревшие и прошлых
поколений технологий!!!
• Стандарты отвязаны от технологий, поэтому требуют
напряжения ума при привязке к технологиям!!!
• Не учитывают требований нормативных актов и
стандартов, как они есть сейчас (только требования при
разработке – «требования ТЗ»)
• Стандарты системной инженерии должны быть
адаптированы к условиям предприятия
• Нужно понимать «дух» этих стандартов, а не прямо
брать «букву» (тем более, что буква там английская)
13

14. Тренд, пока совсем не учтённый в
стандартах
• Обработка полнотекстовых требований новыми
лингвистическими (необязательно семантическими)
методами – МЫ ЭТОГО ПОЧТИ КАСАТЬСЯ НЕ БУДЕМ,
ЭТО ДОЛЖНА БЫТЬ ТЕМА ОТДЕЛЬНОГО СЕМИНАРА.
• Автоматизация меняет практики! Автоматизация
меняет жизненные циклы! Этот тренд может
изменить всю ситуацию!
• Соображение: от текстовых требований не удастся
избавиться никогда, но и требований-моделей будет
всё больше и больше. «Истины» тут нет.

15. Тренды в управлении требованиями
(по SE VISION 2025)
• интеграция инструментов системной инженерии
(моделеры требований и архитектуры, среды
тестирования/испытаний) с традиционными
инженерными инструментами CAD/CAE/PLM – в том
числе модели требований, архитектуры, проекта-
design и даже проекта-project сливаются в одну
модель. [ISO 15926 называл себя в том числе
стандартом работы с требованиями]
• Коллаборативная инженерия, позволяющая
интегрировать работы (workflow) и данные по всему
жизненному циклу – тоже тренд на слияние всего в
одну модель.
15

16. Два понимания требований
• Особая часть определения системы (наряду с архитектурой и
проектом/design): описания «черного ящика» (что делает система по
отношению к её системному окружению).
– Потребности (требования к использующей системы) и ограничения (требования к
подсистемам) в отличие от требований. Для организаций – стратегия (цели).
• Определение системы (любое), данное в деонтической модальности.
Например, «требования архитектуры». Assertion+привязка к части системы –
уже в Modelica
– Отражает иерархичность (субъективную!) системы – что на одном уровне «часть
решения» (архитектуры), то на другом уровне «требования», «постановка проблемы»
• Требования могут быть набором требований (декомпозиция)
• Контрольная точка = требование+время достижения. На
контроле не требования, а контрольные точки!
16

17. Виды требований (Donald Firesmith)
Архитектурные
ограничения
Проектные
ограничения
Ограничения
изготовления
Ограничения
интеграции
Ограничения
разворачивания
Ограничения
Интерфейсные
требования
Поддерживающие
требования
Требования
основного
назначения
Требования к
данным
Качественные
требования
Нефункциональны
е требования
Функциональные
требования
Требования
продукта
Требования
процесса
(метода)
Требования
Требования
эксплуатации
Требования
сопровождения
Требования
поддержания
Требования
обучения
Требования
вывода из
эксплуатации
Производные
(технические)
требования
Требования
закона или
регулятора
Негативные («не
должно»)
требования
Позитивные
(«должно»)
требования
Требования
данных
Объектные
требования
Требования к
материалам
Аппаратные
требования
Требования к
программам
Требования к
людям (роли)
Требования
документации
Требования к
сущностям
Требования
помещения
Процедурные
требования
Системные /
подсистемные
требования
Требования
заинтересованной
стороны
Ограничения
производства
Классификаций множество! Главной классификации не бывает!
Формализмы разные – для разных стейкхолдеров!

18. Большие требования
• по аналогии с BigData – ничего
содержательного, просто «маркетинговое
слово» для указания на volume, velocity,
variety, veracity требований:
– Все уровни системы (потребности, требования
стекйхолдеров, системные требования, требования
к подсистемам)
– Требования нормативных актов
– Требования стандартов
– Требования технических заданий (госконтракты)
18

19. Организации и общество:
«Тоже требования»
• Требования к организации:
– В инженерии встречаются регулярно
(например, в контрактах, в техрегулировании –
«когда нельзя решить проблему технически,
используем организационные меры»)
– Не называются требованиями (motivation
model, cтратегия: требования к предприятию)
• Требования ко всем: законы (проверка
выполнения и трассировка: после аварии, а
не в ходе испытаний!!!)
19

20. Системная схема предпринятия
20
Технологический
менеджмент и
предпринимательство
Инженерный
менеджмент
Инженерия
Технологический
менеджмент
Использующая
система
Целевая
система
Обеспечивающая
система
2015г.

21. Определение «чёрного» и «прозрачного» ящиков
требования архитектураНужды
стейкхолдеров
Использующая
система Целевая система

22. Определение системы
22
Функция:
требования
со стороны
использующей
(над)системы
Архитектура
(совмещение
функциональной и
физической
декомпозиции)
Конструкция:
рабочий проект
(изготавливаемые
части) целевой
системы
Описывается
«чёрный ящик»
(реверс-
инжиниринг
системы
использования)
Описывается
«прозрачный
ящик» с
детальностью,
достаточной для
изготовления
Описываются основные
принципы структуры
«прозрачного ящика»,
который выполнит роль
«чёрного ящика»
Фокусирование (сужение пространства решений)
Архитектурное проектирование/конструирование
«Просто» проектирование/конструирование

23. V-диаграмма сущностей инженерного решения
23
Подальфы
определения
системы
проверка
проверка
Использующая
система
Целевая система
Подсистемы
целевой
системы

24. Verivication & validation
24
The Vee Activity Diagram (Prosnik 2010) Released by the Defense Acquisition
University (DAU)/U.S. Department of Defense (DoD). – из SEBoK v0.71
http://www.sebokwiki.org/075/index.php/System_Realization

25. Целеориентированная инженерия
требований и инженерные обоснования
(http://ailev.livejournal.com/811715.html)
• Общие корни: логика
• GORE – “motivation” (ArchiMate, OMG BMM)
• Assurance case (GSN, CAE)
• Design rationale
Нет требований – нет обоснований!
Обоснования через имитационные модели
«взрывают» традиционную V-диаграмму.
25

26. Требования к требованиям по ISO 29148
(но таких наборов требований множество)
Группа
1. Полнота (complete)
2. Согласованность с другими (consistent)
3. Выполнимость (Affordable, проходимы по бюджету и срокам)
4. Ограниченность (bounded)
Одно требование
1. Необходимость (nessesary)
2. Абстрактность (abstract)
3. Недвусмысленность (unambiguous)
4. Согласованность с другими (consistent)
5. Полнота (complete)
6. Лаконичность (concise)
7. Достижимость (feasible)
8. Трассируемость (traceable)
9. Проверяемость (verifiable)
26

27. Формат требований (псевдокод)
• Множество специализированных языков
• Включение глагола (action) это норма!
• В программной инженерии (Mike Cohn, 2008, Advantages of the
“As a user, I want” user story template, blog post,
http://www.mountaingoatsoftware.com/blog/advantages-of-the-
as-a-user-i-want-userstory-template):
Я как __стейкхолдер__ хочу, чтобы система ___формулировка
требования___, для того чтобы ___хотелка-для-using-system___
• В ISO 29148
27

28. Состояния требований (по OMG Essence)
28
Требования в целом проходят следующие состояния:
• Начаты (concieve) – согласована потребность в системе
• Ограничены (bounded) – назначение и тема новой системы
ясны.
• Непротиворечивы (coherent) – требования обесечивают
непротиворечивое описание существенных характеристик
новой системы.
• Приемлемы (acceptable) – требования описывают систему,
которая будет принята стейкхолдерами
• Отвечены (addressed) – достаточное количество требований
было отвечено, чтобы удовлетворить потребность в новой
системе способом, приемлемым для стейкхолдеров.
• Удовлетворены (fulfilled) – требования, которые были
адресованы, полностью удовлетворяют потребность в новой
системе.
Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии
одной стадии выполняются не одновременно.
Concurrent requirements engineering – параллельная инженерия
требований: возможность только

29. I* -- задаёт тон в GORE
http://www.cs.toronto.edu/km/istar/
Goal-oriented requirements engineering
1995г.: Agents attribute intentional properties (such as goals, beliefs, abilities, commitments)
to each other and reason about strategic relationships. Dependencies between agents give rise
to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a
qualitative reasoning approach. Agents consider alternative configurations of dependencies to
assess their strategic positioning in a social context.
Стандарты: 2008г. ITU-T Z.151 (Goal-oriented Requirements Language + Use Case Maps)
29

30. Motivation model ArchiMate 2.1
[инженерия предприятия – поддисциплина системной инженерии]
30

31. Мета-модель требований в Modelica
31
ModelicaML – совместное использование Modelica и UML (генерация кода на
Modelica из UML), http://www.ep.liu.se/ecp/084/003/ecp13084003.pdf

32. Modelica
• ModelicaML – описание требований
приписыванием «утверждений» к
компонентам реализации системы
• Архитектурный язык – тоже Modelica
• Имитационное моделирование (и проверка
требований моделированием в том числе)
• Мультифизика+дискретные модели
• Добавка «разного» моделирования через FMI
(Functional Mock-up Interface, https://fmi-
standard.org).
32

33. Спецификации в Julia
• Доклад Using Julia as a Specification Language for the
Next-Generation Airborne Collision Avoidance System
(https://youtu.be/19zm1Fn0S9M)
• Фишка: язык научных/инженерных вычислений,
компьютерный язык общего назначения.
• Генерация исполняемого кода авионики: после
сертификации Julia (сейчас это «не хуже псевдокода»)
• Мотив: «это в разы дешевле, чем псевдокод с
независимыми реализациями для валидации. Мы
генерируем выполняемые спецификации сейчас» –
там где-то 200 алгоритмов, 30 сложных структур
данных, много коллективов разработчиков
(полудюжина университетов).
33http://julialang.org/

34. Deep Learning
• Широко известно с 2012г.
• Надувается очередной инвестиционный
пузырь
• Прямой конкурент всем «семантическим» и
«онтологическим» разработкам (быстро
воспроизводит state-of-the-art)
• Требует жутких объемов данных («корпусная
инженерия»).
• В предметной области требований пока не
замечены, ждём-с на днях.
34

35. Автоматизация интеллектуальной работы
• Онто (логичность, hard computing) против
эпистемологичности (soft computing, learning)
• Почему нельзя избавиться от онтологии
(проблема множественности онтологий)
• Почему нельзя избавиться от текста (проблема
ансамблевости моделей)
• Итого:
– нужен гибридный подход
– Будет консилиум «умных систем» инженерии
требований (не так, как с «редакторами»: писец
один справится, а экспертов для надёжности
нужно несколько)
35

36. Мультимодальность
(геометрия: на уровне средней школы)
http://phys.org/news/2015-09-ai-sat-geometry-average-human.html
Сегодняшний уровень state-of-the-art: экзамены в университеты -- http://allenai.org/aristo.html
36

37. Всеохватность в hard computing
• Теория категорий -- ?
• SysMoLan – прихват ISO 15926, ISO 81346 и (может
быть) теории категорий
• GSLS – goal and contract specification language, на
базе OCL (UML/SysML) и Contract Specification
language (текстовые паттерны) -- http://danse-
ip.eu/home/109-gcsl.html
• Modelica – объект-ориентированность, зато
акаузальность
• Julia – нет акаузальности, нет
моделеориентированности (но возможны
расширения и отличные библиотеки)
• «Псевдокод»: ArchiMate – i*, и только. Даже
воплощения системы нет.
37

38. Нет в жизни счастья: чей Roadmap?
• Прогресс в инженерии требований стремительный,
содержание дисциплины меняется
• Со стороны hard computing неожиданные прорывы и
новые имена (Modelica, Julia).
• Подходов и теорий тьма, но всё решат инструменты. Кто
заплатит за создание инструментов, того и тапки.
• Интеллект и требования: программирование против
обучения – будет главная битва.
• Мы можем не обращать внимания, можем наблюдать, а
можем участвовать в развитии инженерии требований.
38

39. 39
Спасибо за внимание
Анатолий Левенчук,
http://ailev.ru
ailev@asmp.msk.su
Виктор Агроскин
vic5784@gmail.com