Инженерия требований — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) м (→Программное обеспечение) |
||
| (не показаны 33 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
| − | '''Инженерия требований''' — | + | '''Инженерия требований''' (Requirements Engineering, RE) — поддисциплина [[Системная инженерия|системной инженерии]], которая занимается разработкой [[Требования|требований]]. |
| − | Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания | + | Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания "чёрного ящика". |
| − | ''Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.'' | + | ''Проблема: все требования проходят по [[ЖЦ]] асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.'' |
| − | Инженерия требований | + | Инженерия требований включает в себя: |
| − | * | + | * Учет требований |
| − | * | + | * Проверку непротиворичивости требований |
| − | + | Классическая инженерия требований: http://www.requirementsnetwork.com/ | |
| − | Инженерия требований должна начинаться с управления требованиями | + | == Управление требованиями == |
| + | Инженерия требований должна начинаться с [[Управление требованиями|управления требованиями]]. | ||
| − | '''Требование''' | + | '''[[Требования|Требование]]''' — это приписанное к части системы утверждение (assertion). |
| − | '''Контрольная точка''' | + | '''[[Гейты и вехи|Контрольная точка]]''' — это достижение этого требования к какому-то моменту. |
Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут. | Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут. | ||
| − | |||
== Инженер по требованиям == | == Инженер по требованиям == | ||
| − | |||
=== Кто должен делать требования? === | === Кто должен делать требования? === | ||
| − | + | # Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: "вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим". Это неверная позиция. '''Заказчик может представить только свои нужды, а не требования к системе'''. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить "требования стейкхолдера". Но это ещё не требования к системе. | |
| − | # Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: | + | |
| − | + | ||
# '''Разрабатывает требования обычно команда проекта''', они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). '''За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы''': часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер. | # '''Разрабатывает требования обычно команда проекта''', они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). '''За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы''': часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер. | ||
| − | |||
=== Обязанности инженера по требованиям === | === Обязанности инженера по требованиям === | ||
| − | |||
Инженер по требованиям (вид системного инженера) занимается тем, что: | Инженер по требованиям (вид системного инженера) занимается тем, что: | ||
* выявляет [[Стейкхолдер|стейкхолдеров]], | * выявляет [[Стейкхолдер|стейкхолдеров]], | ||
| Строка 38: | Строка 33: | ||
* согласует требования стейкхолдеров между собой, | * согласует требования стейкхолдеров между собой, | ||
* готовит требования к [[Система|системе]]. | * готовит требования к [[Система|системе]]. | ||
| − | |||
=== Качества инженера по требованиям === | === Качества инженера по требованиям === | ||
| Строка 47: | Строка 41: | ||
* способным изменять ситуацию (решать проблемы со стейкхолдерами, проводить переговоры по согласованию позиций). | * способным изменять ситуацию (решать проблемы со стейкхолдерами, проводить переговоры по согласованию позиций). | ||
| − | == | + | == Моделеориентированная инженерия требований == |
| − | + | В [[Инженерия предприятия|инженерии предприятий]] (enterprise engineering) модели требований (к предприятию/к архитектуре предприятия) часто называют '''мотивационными моделями''' (motivation не только «движущая сила, побуждение», но и обоснование – reason, justification). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | '''Моделеориентированность''' (как шаг к формальным требованиям) '''хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование)'''. Требования должны [[документирование|документироваться]] и затем использоваться для проведения испытаний ([[Проверки и приемки|проверок и приёмок]]) как [[Практика контрольных вопросов|чеклисты]]. | ||
| − | + | === Примеры языков для моделей требований === | |
| − | * | + | * [http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome GRL], |
| − | + | * [http://istar.rwth-aachen.de/ подход i*] (этот подход родоночальник и классика [[GORE]]), | |
| − | * | + | * [http://pubs.opengroup.org/architecture/archimate2-%20doc/chap10.html#_Toc371945252 Motivational Extension] в [[ArchiMate]] 2.0, |
| − | * | + | * [http://www.scenarioplus.org.uk/papers/mbrd/Model-based_Requirements_Discovery.PDF Model-based requirement discovery] от Яна Александера. |
| + | === Программное обеспечение === | ||
| + | * [[Modelica]] | ||
| + | * [[DOORS|IBM Rational DOORS]] | ||
| + | * [https://www.threesl.com 3SL Cradle] | ||
| + | * [https://www.reusecompany.com/requirements-quality-suite Requirements Quality Suite] | ||
| + | * [https://www.reqview.com/ ReqView] | ||
| + | |||
| + | === Другие практики с использованием моделеориентированных требований === | ||
| + | * '''Test driven development''' – это когда разработка системы начинается с того, что требования разрабатываются сразу в виде тестов (исполняемых!). Увы, качество разработки по TDD получается примерно такое же, как и при любых других видах разработки – что не снижает популярности этого подхода. Требования как правило разрабатываются с помощью сценариев ([[Сценарий использования|use cases]]), в которых рассказывается, что делает система в ответ на последовательности действий (сценарии) с участием разных стейкхолдеров. | ||
| + | * Использование '''[[Пользовательские истории|user story]]''' в формулировках по шаблону ([http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-userstory-template Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post]): Я как [стейкхолдер] хочу, чтобы система [формулировка требования], для того чтобы [хотелка-для-using-system]. | ||
| + | |||
| + | == Целеориентированная инженерия требований == | ||
| + | Все целевые-обосновательные подходы образуют анклавы в разных частях [[V-диаграмма|V-диаграммы]]: | ||
| + | * [[GORE]] в начале, | ||
| + | * [[Обоснование архитектуры|architecture/design rationale]] поближе к середине, | ||
| + | * [[Обоснование заявленных свойств|assurance case]] в конце. | ||
| + | |||
| + | Вся эта "целеориентированность" и "обоснованность" выражает обычный ход рассуждений (reason), доказательств (proofs) и аргументирования (argumentation). Литературы на эту тему более чем достаточно, достаточно вспомнить про [http://physics.suite101.com/article.cfm/induction_vs_deduction_in_science дедуктивный и индуктивный метод], в совокупности составляющих "научный метод" и далее утонуть в разговоре о соотношении [[Инженерия и наука|инженерии и исследований/науки]]. | ||
| + | |||
| + | Еще более правильно считать, что [http://philosophy.lander.edu/logic/index.html "это просто логика, сынок"] — именно логика озабочена правильностью рассуждений и аргументации. | ||
| + | |||
| + | Понятно, что вариаций на эти темы более чем достаточно — особенно, если учесть, что логика это раздел гносеологии/эпистемологии (а в гегелевско-марксистском понимании так и вообще это про одно и то же: поищите слово "логика" [http://ru.wikipedia.org/wiki/%D0%93%D0%BD%D0%BE%D1%81%D0%B5%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F на этой странице]). | ||
| + | |||
| + | Традиционно аргументирование развивалось не только в науке, но и в юридической практике — поэтому первые работы, на которые опираются очень многие "инженерные" подходы, касаются тематики legal argument, причем в варианте case-based theory (а не rule-based, см. [http://logic.stanford.edu/classes/cs204/readings/mccarty1997.pdf статью аж 1997г]. С тех пор в этой сфере довольно далеко ушли, и не факт, что инженеры или даже софтовые инженеры продвинулись дальше). | ||
== Международные общества == | == Международные общества == | ||
* [https://www.ireb.org/ IREB] (International Requirements Engineering Board) | * [https://www.ireb.org/ IREB] (International Requirements Engineering Board) | ||
* ReSG (Requirements Engineering Specialist Group, в British Computer Society) | * ReSG (Requirements Engineering Specialist Group, в British Computer Society) | ||
| − | |||
== Профессиональная сертификация == | == Профессиональная сертификация == | ||
* CPRE | * CPRE | ||
| − | |||
== Журналы == | == Журналы == | ||
| − | |||
* http://re-magazine.ireb.org | * http://re-magazine.ireb.org | ||
| + | == Стандарты инженерии требований == | ||
| + | * IEC/IEEE/[[ISO 15288]]:2015 – задаёт инженерию требований в других дисциплинах (инженерии системной архитектуры, управления конфигурацией и т.д.) | ||
| + | * IEC/IEEE/[[ISO 29148]]:2011 – специализированный по требованиям, на базе ISO 15288 | ||
| + | * [[ISO 24766|ISO/IEC TR 24766]]:2010 | ||
| + | * [[SEBoK]] – стандарт, используемый в сертификации системных инженеров | ||
| − | + | Взаимосвязь основных стандартов инженерии требований отражена на диаграмме: | |
| − | + | [[Файл:RE relation.png|center]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | == См. также == | ||
| + | *[[Требования#Стандарты представления требований|Стандарты представления самих требований]] | ||
| − | |||
| − | |||
| − | |||
[[Категория:Дисциплины]] | [[Категория:Дисциплины]] | ||
Текущая версия на 00:16, 21 декабря 2018
Инженерия требований (Requirements Engineering, RE) — поддисциплина системной инженерии, которая занимается разработкой требований.
Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания "чёрного ящика".
Проблема: все требования проходят по ЖЦ асинхронно, и даже критерии одной стадии выполняются не одновременно. Concurrent requirements engineering – параллельная инженерия требований.
Инженерия требований включает в себя:
- Учет требований
- Проверку непротиворичивости требований
Классическая инженерия требований: http://www.requirementsnetwork.com/
Содержание
Управление требованиями
Инженерия требований должна начинаться с управления требованиями.
Требование — это приписанное к части системы утверждение (assertion).
Контрольная точка — это достижение этого требования к какому-то моменту.
Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.
Инженер по требованиям
Кто должен делать требования?
- Иногда между командой инженеров и заказчиком можно услышать следующий разговор со стороны инженеров: "вы предоставьте нам подробные требования, иначе мы и пальцем не пошевелим". Это неверная позиция. Заказчик может представить только свои нужды, а не требования к системе. Если у заказчика есть инженеры (или заказ на разработку системы делает инженерная фирма), то есть шанс получить "требования стейкхолдера". Но это ещё не требования к системе.
- Разрабатывает требования обычно команда проекта, они не приходят извне проекта. Другое дело, что без активного участия стейкхолдеров (в том числе представителей организации заказчика) требования не подготовишь. Но в любом случае, ответственность за требования лежит на команде проекта, а не на заказчике. Заказчик же может, например, завизировать разработанные командой проекта требования — но и в этом случае, изготовленная система, которая не удовлетворит его нуждам (needs) по причине того, что требования были сформулированы командой проекта неправильно, может встретить серьёзные проблемы при приёмке/validation (хотя блестяще пройдёт проверку/verification — инженеры подтвердят сами себе, что изготовили ровно то, что планировали, хотя это не то, в чём нуждался клиент). За требования ответственен инженер потому что он должен сделать реверс-инжиниринг использующей системы: часто клиент на это не способен, хотя он обычно и весьма знающ об особенностях используемой системы, но эти знания могут быть совсем не такими, на которые мог бы расчитывать инженер.
Обязанности инженера по требованиям
Инженер по требованиям (вид системного инженера) занимается тем, что:
- выявляет стейкхолдеров,
- узнает потребности стейкхолдеров (нужды, needs),
- разрабатывает требования стейкхолдеров,
- проводит переговоры между стейкхолдерами в тех случаях, когда их требования противоречивы, или когда команда проекта оказывается не в состоянии их выполнить и требования нуждаются в коррекции,
- согласует требования стейкхолдеров между собой,
- готовит требования к системе.
Качества инженера по требованиям
Инженер по требованиям должен быть:
- лидером (упаковывать исполнителей с их личными интересами в культурно-обусловленные позиции стейкхолдеров);
- социотехником (найти и извлечь все техники из человека, работать с диаграммами целеполагания);
- инженером (понимать архитектуру, разбираться в инженерных обоснованиях, читать чертежи и моделировать);
- способным изменять ситуацию (решать проблемы со стейкхолдерами, проводить переговоры по согласованию позиций).
Моделеориентированная инженерия требований
В инженерии предприятий (enterprise engineering) модели требований (к предприятию/к архитектуре предприятия) часто называют мотивационными моделями (motivation не только «движущая сила, побуждение», но и обоснование – reason, justification).
Моделеориентированность (как шаг к формальным требованиям) хороша для проведения проверок самих требований (хотя она не поможет найти пропущенное требование). Требования должны документироваться и затем использоваться для проведения испытаний (проверок и приёмок) как чеклисты.
Примеры языков для моделей требований
- GRL,
- подход i* (этот подход родоночальник и классика GORE),
- Motivational Extension в ArchiMate 2.0,
- Model-based requirement discovery от Яна Александера.
Программное обеспечение
Другие практики с использованием моделеориентированных требований
- 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
Журналы
Стандарты инженерии требований
- IEC/IEEE/ISO 15288:2015 – задаёт инженерию требований в других дисциплинах (инженерии системной архитектуры, управления конфигурацией и т.д.)
- IEC/IEEE/ISO 29148:2011 – специализированный по требованиям, на базе ISO 15288
- ISO/IEC TR 24766:2010
- SEBoK – стандарт, используемый в сертификации системных инженеров
Взаимосвязь основных стандартов инженерии требований отражена на диаграмме:
