Я – Юрій Ізбенко, консультант в компанії GlobalLogic, працюю в медичному домені більше 10 років (Quality Assurance). В даній статті хочу розповісти про три підходи до написання вимог з використанням природної мови, які відповідають стандартизованим критеріям якості, – підходах, запропонованих в IREB, IEEE 29148 і EARS. Стаття може бути корисною тим, хто працює з написанням, імплементацією та верифікацією формалізованих функціональних вимог – архітекторам, бізнес-аналітикам, менеджерам проектів, розробникам, тестувальникам.
Чому написана ця стаття
При розробці ПЗ всі команди в тій чи іншій мірі стикаються з інжинірингом вимог (Requirements Engineering, RE) – виявленням (elicitation), написанням (documentation), валідацією/узгодженням (validation & negotiation) і менеджментом (management) вимог. У різних джерелах перераховані активності можуть мати трохи інші назви або послідовності, але суть RE не змінюється.
Ми з колегами працюємо на медичних проектах, які передбачають формальну верифікацію, і робота з вимогами займає значну частину нашого часу. Кожна недостатньо добре сформульоване вимога тягне за собою часові витрати на з’ясування з клієнтом того, про що ж саме йдеться у вимозі; неправильно зрозуміла/реалізована/протестована вимога призведе до необхідності повторити всі пов’язані з нею активності, можливо – до затримки випуску продукту або до втрат для бізнесу, якщо помилка не виявляється вчасно. У якийсь момент у мене назріла необхідність докопатися до першоджерел (а не апелювати до Гуглу) і систематизувати свої знання в цій галузі. Коли на одному з проектів мені довелося писати SRS (Software Requirements Specification), виявилося, що просто знати критерії якості вимог для написання такого документа недостатньо, тому знання підходів до написання вимог теж стало актуальним завданням.
Метою статті є скорочення часу колег на пошук/читання букварів з написання вимог і систематизація відомих рішень (не всім вони можуть здатися безперечними). Постараюся дати матеріал стисло і тезово, але іноді теоретична підводка буде необхідна. Найбільш нетерплячі можуть відразу починати з розділу 1. У статті буде багато англомовних термінів і прикладів – англійська є фактичним стандартом для компаній, що працюють в аутсорсі; можливо, комусь таким чином буде легше орієнтуватися в термінології.
Роль і місце Requirements Engineering в System і Software Engineering
Міжнародні стандарти ISO / IEC / IEEE 12207 Systems and software engineering – Software life cycle processes [1] і ISO / IEC / IEEE 15288 Systems and software engineering – System life cycle processes [2] визначають кінцеву безліч процесів для управління життєвим циклом ПЗ і відносять Requirements Engineering процеси до групи з 14 технічних процесів, однією з чотирьох груп процесів життєвого циклу ПЗ (Technical Processes). У свою чергу, міжнародний стандарт ISO / IEC TR 19759 Software Engineering Body of Knowledge (SWEBOK) [3] відносить Requirements Engineering (Software requirements в стандарті) до однієї з 15 областей знань розробки ПО (далі для простоти найменування стандартів будемо просто вказувати назву останнього інституту і номер стандарту).
Джерела інформації
У якості відправної точки були обрані наступні джерела:
- IREB, Certified Professional for Requirements Engineering, Foundation Level (Сертифікований, [4]);
- IEEE 29148 Requirements Engineering [5];
- EARS, Easy Approach to Requirements Syntax [6, 7];
- (Повністю осилити BABOK [8], як і пройти будь-які IIBA сертифікації для бізнес-аналітиків, руки не дійшли – побіжний перегляд BABOK показав, що він описує критерії якості вимог, але не відповідає на питання яким чином написати вимоги, що задовольняють цим критеріям ).
Чому IREB, IEEE 29148, EARS
IREB (International Requirements Engineering Board) заснований в Німеччині з метою підтримки єдиної, загальновизнаної, міжнародної схеми кваліфікації, спрямованої на розробку вимог для професіоналів. Члени IREB – це міжнародні експерти в області розробки вимог з університетів, економіки і освіти. Прибуткова організація, проводить сертифікацію як самостійно, так і під крилом iSQI (International Software Quality Institute). Матеріали IREB часто мають відсилання до IEEE 29148 як базових знань. Основна відмінність IREB від IEEE 29148 з точки зору пропонованого матеріалу, на мій погляд, полягає в тому, що якщо IEEE 29148 подає суху витримку знань і відповідає на питання «Як?», То в IREB матеріал більш розгорнутий і крім відповіді на питання «Як ? » відповідає на питання «Чому?».
ISO, IEC, IEEE (International Organization for Standardization, International Electrotechnical Commission, Institute of Electrical and Electronics Engineers) – неприбуткові організації, метою яких є стандартизація в області електротехніки, електроніки, зв’язку, обчислювальної техніки, інформатики та інформаційних технологій. Їх спільні гармонізовані стандарти де-факто є світовими стандартами. Стандарт IEEE 29148 Requirements Engineering гармонізований з IEEE 12207, IEEE 15288 і визначає, зокрема, перелік процесів Requirements Engineering-у (Розділ 6), підхід для написання хороших вимог (5.2.4), характеристики індивідуальних вимог (5.2.5) і безлічі вимог (5.2.6), є ітеративним і рекурсивним застосуванням Requirements Engineering процесів протягом усього життєвого циклу (5.3), структуру SRS. З практичної точки зору IEEE 29148 цілком самодостатнє і повне джерело в галузі інжинірингу вимог; якщо не хочете винаходити велосипед в області Systems and Software Engineering – це ваш кейс.
EARS (Easy Approach to Requirements Syntax). Даний підхід написання вимог був розроблений інженерами компанії Rolls-Royce (Великобританія). Серед іншого, компанія розробляє системи управління газотурбінних авіаційних двигунів, які характеризуються підвищеною складністю, надійністю, поліпшеною стійкістю до відмов (т.зв. safety critical, або mission critical системи). Очевидно, існуючі підходи не задовольняли команду розробників і вони вирішили розробити свій підхід до написання вимог, який би підвищив точність опису вимог і мінімізував такі проблеми природної мови як неоднозначність, неясність, упущення.
Передісторія проблем з написанням вимог
В цілому, написання вимог здійснюється двома основними способами – з використанням природної мови, ПМ (user stories, вимоги) та з використанням концептуальних моделей (model based – Use Case Diagrams, Class Diagrams, Activity Diagrams, State Diagrams). Найбільш широке поширення отримав перший підхід як найбільш гнучкий – за допомогою мови ми можемо вільно висловити будь-яку думку, для цього не потрібна спеціальна підготовка всіх учасників процесу; другий підхід носить допоміжний характер. Разом з тим, використання неструктурованої ПМ при написанні вимог привносить такі проблеми:
- Неоднозначність (ambiguity) – слово або фраза має два або більше різних значення.
- Неясність (vagueness) – відсутність точності, структури і / або деталей.
- Складність (complexity) – складові вимоги, що містять складні підпункти і / або декілька взаємопов’язаних тверджень.
- Упущення (omission) – відсутність вимог, особливо вимог по обробці небажаної поведінки.
- Дублювання (duplication) – повторення вимог, що визначають одну і ту саму потребу.
- Багатослівність (wordiness) – використання непотрібної і зайвої кількості слів.
- Неадекватна реалізація (inappropriate implementation) – твердження про те, як повинна бути побудована система, а не що вона повинна робити.
- Нетестопридатність (untestability) – вимоги, істинність або хибність яких неможливо довести при реалізації системи.
Відповідно, основними критеріями якості вимог є (наш чек-лист):
- однозначність (unambiguous);
- несуперечливість (consistency);
- повнота (сomplete);
- атомарность (singular);
- здійсненність (feasible);
- тестопридатність (verifiable).
В якості тривіального прикладу проблем з написанням вимог можна розглянути постановку задачі менеджером: Колеги, нагадую – зробіть плз те, про що ми з вами говорили.
Виникає кілька питань: всі колеги, або конкретні (може я вже це зробив?), Про що саме говорили (ми багато про що говорили), коли ми про це говорили, зробити до якого конкретного терміну, якщо це документація – в якому форматі і куди викласти і т. п. Проблеми з постановкою завдання тут – неясність, упущення (а то і позбавлення бонусів).
Для мінімізації проблем, що вносяться ПМ при документуванні вимог, і були розроблені нижченаведені підходи.
1. IREB (International Requirements Engineering Board).
1.1. Ефекти природної мови.
У IREB кажуть, що крім суб’єктивного сприйняття інформації, природна мова (байдуже яка – англійська, німецька, …) володіє наступними трансформаційними ефектами, що сприяють потенційній втраті інформації:
- Номіналізація.
- Іменники без референтного індексу.
- Універсальні квантифікатори.
- Неповністю визначені умови.
- Неповністю визначені дієслова процесу.
Номіналізація. Суть номіналізації полягає в тому, що якийсь процес (навіть тривалий) може бути описаний всього лиш одним іменником, наприклад input, booking. Ці іменники говорять нам про те, що такі процеси є, але номіналізація приховує від нас як ці процеси відбуваються. Ці дієслова / процеси повинні бути виявлені.
Приклад: The system shall provide support of a water level sensor.
Виникає питання – які процеси ми маємо на увазі під іменником support?
Іменники без референтного індексу. Як і дієслова процесу, іменники також можуть мати неповний опис, наприклад the user, the data.
Приклад: The data shall be displayed to the user.
Виникають питання – які саме дані, який саме тип користувача?
Універсальні квантифікатори. Визначають кількість або частоту, групують набір об’єктів і роблять твердження про поведінку всього цього набору. Існує ризик, що вказана поведінка або властивість не може бути застосовано до всіх об’єктів, що входять в зазначену множину. Ідентифікуються такими тригерними словами, як never, always, every, all, some, nothing.
Приклад: The system shall show all data sets in every submenu.
Виникають питання – точно всі датасети? Точно в кожному підменю?
Неповністю визначені умови. Вимоги, що містять умови, визначають поведінку, яка має відбутися при виконанні умови. Частина, яка часто відсутня – яка поведінка має відбутися, якщо умова не виконується. У складних умовних структурах таблиці рішень є хорошим інструментом для пошуку невизначених варіантів умов або дій. Тригерними словами є if. . . then, in case, whether, depending on.
Приклад: The restaurant system shall offer all beverages to a registered guest over the age of 20 years.
Виникають питання – гостям молодше 20 років напої не відпускаються? Напої – алкогольні / безалкогольні для різних категорій гостей?
Неповністю визначені дієслова процесу. Деякі дієслова процесу вимагають більш одного іменника, щоб вважатися повністю визначеними. Наприклад, дієслово transmit вимагає як мінімум трьох доповнень, щоб вважатися повним: що передається, звідки передається і куди передається. Використання неповністю визначених дієслів процесу можна уникнути або звести до мінімуму, якщо формулювати вимоги в активному, а не в пасивному стані
Приклад (passive voice): To log a user in, the login data is entered.
Приклад (active voice): The system shall allow the user to enter his username and password using the keyboard of the terminal.
1.2. Підхід до написання вимог.
Для зниження трансформаційних ефектів, IREB пропонує використовувати наступні 5 кроків при розробці вимог, виділяючи 3 типи вимог:
Крок 1. Визначити юридичне зобов’язання
Обов’язкове shall, рекомендоване should, майбутня вимога will і бажане may.
Крок 2. Ядро вимоги
Ядро кожної вимоги – це функціональність, яку вона визначає (наприклад, print, save, calculate). Ця функціональність описує процес, який описується виключно за допомогою дієслів.
Крок 3. Охарактеризувати діяльність системи
Для функціональних вимог, діяльність системи може бути класифікована як один з трьох відповідних типів вимог:
- Автономна діяльність системи. Даний тип використовується при побудові вимог, які описують дії системи, виконуються без участі користувача. Шаблон виглядає як:
The system shall / should / will / may <process verb>. - Взаємодія з користувачем. Даний тип використовується для опису випадків, коли система надає функціональність користувачеві (наприклад, за допомогою інтерфейсу введення), або система безпосередньо взаємодіє з користувачем:
The system shall / should / will / may provide <whom?> With the ability to <process verb>. - Вимога інтерфейсу. Використовується для опису виконання системою процесів, що залежать від третьої сторони (наприклад, іншої системи); система пасивна і очікує зовнішнього події:
The system shall / should / will / may be able to <process verb> ..
Крок 4. Додати об’єкти (завершити дієслова процесу)
Визначаються потенційно відсутні об’єкти і доповнення об’єктів (прислівники). Наприклад, шаблон вимог для дієслова процесу print доповнюється інформацією про те, що друкується і де друкується.
Крок 5. Визначити логічні та часові обмеження (додати умови)
Логічне if або тимчасове обмеження as soon as. Слід уникати when (незрозуміло, це логічне або тимчасове обмеження).
Структурно підхід виглядає наступним чином:
2. IEEE 29148 Requirements Engineering.
2.1. Керівництво з написання добре сформульованих вимог.
При написанні вимог стандарт рекомендує використовувати заздалегідь узгоджені терміни і правила при написанні вимог для мінімізації негативних ефектів ПМ:
- Використання shall для обов’язкових вимог, will для заяв про щось в майбутньому або декларації намірів (рекомендується уникати), should для бажаних необов’язкових вимог, may для припущень, уникнення must.
- Використання позитивних тверджень і уникнення негативних shall not.
- Використання активного способу, уникнення пасивного назразок shall be able to select.
- У вимозі повинно бути вказано, що необхідно зробити, а не як.
- Уникнення використання необмежених або неоднозначних типів термінів.
- найвищого ступеня (таких як best, most);
- суб’єктивної лексики (user friendly, easy to use, cost effective);
- невизначених займенників (таких як it, this, that);
- неоднозначних прикметників (таких як almost always, significant, minimal);
- необмежених, неперевірених термінів (такі як provide support, but not limited to, as a minimum);
- порівняльних фраз (такі як better than, higher quality);
- лазівок (таких як if possible, as appropriate, as applicable);
- негативних тверджень (таких як тверджень про те, чого система не буде надавати);
- неповних посилань (відсутності посилання з датою і номером версії).
2.2. Підхід до документування вимог.
Виділяється три типи вимог:
Таблиця 1. IEEE 29148 шаблони написання вимог
| Тип вимоги | Шаблон |
| Тип 1 | <Subject> <Action> <Value> |
| Тип 2 | <Condition> <Subject> <Action> <Object> <Constraint> |
| Тип 3 | <Condition><Action or Constraint> <Value> |
Приклад для першого типу вимог:
The Invoice System <Subject> shall display pending customer invoices <Action> in ascending order <Value> in which invoices are to be paid.
Приклад для другого типу вимог:
When signal x is received <Condition>, the system <Subject> shall set <Action> the signal x received bit <Object> within 2 seconds <Constraint>.
Приклад для третього типу вимог:
At sea state 1 <Condition>, the Radar System shall detect targets at ranges out to <Action or Constraint> 100 nautical miles <Value>.
Не можу сказати, що згоден з наведеними типами 1 і 3 – в обох шаблонах тег <Object> відсутній (поглинений тегами <Action “і” Action or Constraint> відповідно), в типі 3 пропущений тег <Subject>.
3. EARS (Easy Approach to Requirements Syntax).
3.1. Підхід.
Для усунення або мінімізації основних проблем, привнесених в вимоги природною мовою, автори підходу пропонують використовувати наступний узагальнений підхід (порядок проходження елементів важливий):
<Optional preconditions> <optional trigger> the <system name> shall <system response>
Даний підхід при написанні вимоги стимулює враховувати:
- preconditions – умови, при яких вимога виникає (опціонально);
- trigger – подія, що робить вимогу актуальною, при виконанні умови (опціонально);
- system response – необхідна реакція системи тоді і тільки тоді, коли попередні умови і тригер істинні.
Автори виділяють 5 типів вимог, за допомогою яких можна описати їх систему: Ubiquitous, Event-driven, Unwanted behaviors, State-driven, Optional features, під кожен з яких адаптується узагальнений підхід.
Ubiquitous (повсюдні) вимоги. Не мають попередніх умов або тригера. Чи не викликаються будь-якою подією і не є реакцією на певний стан системи, вони є активними завжди. Шаблон для такого типу вимог виглядає наступним чином:
The <system name> shall <system response>
Приклад: The control system shall prevent engine overspeed.
Це поведінка системи, яка повинна бути активною в будь-який час; отже, це повсюдна вимога.
Event-driven вимоги. Такий вид вимог використовується тільки тоді, коли настає подія, що є тригером для подальшої реакції системи на цей тригер. Для цього типу вимог використовується ключове слово When. Шаблон для такого типу вимог:
When <optional preconditions> <trigger> the <system name> shall <system response>
Приклад: When continuous ignition is commanded by the aircraft, the control system shall switch on continuous ignition.
Реакція системи «switch on …» настає тоді і тільки тоді, коли відбувається тригерна подія «commanded».
Unwanted behaviors вимоги. «Небажана поведінка» – це загальний термін, який використовується для небажаних ситуацій: збоїв, порушень, відхилень від бажаної поведінки користувача, несподіваної поведінки взаємодіючих систем. На думку авторів небажана поведінка є основним джерелом упущень в ранніх вимогах, що призводить до необхідності дорогого доопрацювання. Вимоги до небажаного поводження позначаються за допомогою ключових слів If і Then:
If <optional preconditions> <trigger>, Then the <system name> shall <system response>
Приклад: If the computed airspeed fault flag is set, then the control system shall use modelled airspeed.
У цьому прикладі небажана поведінка «computed air speed fault flag is set» ініціює реакцію системи «system shall use modelled airspeed.
Використання структури If – Then дозволяє пом’якшити вплив небажаної події, або запобігти входженню системи в небажаний стан.
State-driven вимоги. Даний вид вимог актуальний, коли система знаходиться в певному стані, і використовує ключове слово While (або During):
While <in specific state> the <system name> shall <system response>
Приклад: While the aircraft is in-flight, the control system shall maintain engine fuel flow above XXlbs / sec.
Тут реакція системи «maintain engine fuel flow …» необхідна щоразу, поки система знаходиться в стані «in-flight».
Optional features. Даний вид вимог використовується тільки в системах, що включають частковий функціонал, і використовує ключове слово Where:
Where <feature is included> the <system name> shall <system response>
Приклад: Where the control system includes an overspeed protection function, the control system shall test the availability of the overspeed protection function prior to aircraft dispatch.
Тут функціональність «… shall test the availability of the overspeed protection» має сенс (і отже потрібна) тільки в тому випадку, якщо у системи дана функціональна можливість визначена (overspeed protection function).
3.2. Результати.
Грунтуючись на застосуванні наведеного підходу до деякого набору вимог до існуючої системи, автори (з деякими припущеннями і обмеженнями) стверджують, що запропонований підхід дозволив позбутися в вимогах наступних п’яти проблем з восьми: складності (complexity), упущень (omission), дублювання (duplication ), неадекватної реалізації (inappropriate implementation), нетестопридатності (untestability), і значно знизити, але не усунути, неоднозначність (ambiguity), неясність (vagueness), багатослівність (wordiness).
Таблиця 2. EARS шаблони написання вимог
| Тип вимоги | Шаблон |
| Ubiquitous | The <system name> shall <system response> |
| Event-Driven | When <optional preconditions> <trigger> the <system name> shall <system response> |
| Unwanted Behavior | If <optional preconditions> <trigger>, Then the <system name> shall <system response> |
| State-Driven | While <in specific state> the <system name> shall <system response> |
| Optional Feature | Where <feature is included> the <system name> shall <system response> |
| Complex | (комбінація вищенаведених шаблонів) |
висновки
З точки зору практичного застосування наведених підходів я виділив для себе наступні тези:
- IREB, Foundation level – хороша точка входу в Requirements Engineering.
- Знання трансформаційних ефектів мови, наведених IREB, дозволяє більш повно описати поведінку системи – виявити приховані процеси (номіналізація), повністю визначити дієслова цих процесів (уникнути пасивного стану) і умови, при яких вони відбуваються, повністю описати іменники (іменники без референтного індексу), уникнути узагальнень (універсальні квантифікатори).
- IEEE 29148 дає хороший список типів термінів, що вносять невизначеність у вимоги
- Для більшості систем найбільш оптимальними підходами для написання вимог будуть підходи, представлені IREB і IEEE 29148.
- Для Safety Critical і Mission Critical систем найбільш підходящим підходом буде EARS підхід як підхід, що дозволяє найбільш повно описати вимогами складні системи з великою кількістю внутрішніх станів і переходів.
- В описаних підходах є несуттєві протиріччя (наприклад, IREB рекомендує уникати використання умови when, в той час як IEEE 29148 і EARS використовують). Для уникнення цих протиріч є сенс заздалегідь домовитися з клієнтом / командою про використовувані підходах написання вимог і який сенс ми вкладаємо в ту чи іншу термінологію (свій глосарій може бути актуальне).
Окреме спасибі старшому (за рівнем зрілості) колезі Анатолію Сахно, який ознайомив мене з EARS, переглянув цю статтю і дав цінні коменти.
Література
[1] ISO / IEC / IEEE 12207 Systems and software engineering – Software life cycle processes
[2] ISO / IEC / IEEE 15288 Systems and software engineering – System life cycle processes
[3] ISO / IEC TR 19759 Software Engineering Body of Knowledge
[4] Klaus Pohl, Chris Rupp. Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam
[5] ISO / IEC / IEEE 29148 Systems and software engineering – Life cycle processes – Requirements Engineering
[6] EARS (Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09)
[7] Big EARS: The Return of Easy Approach to Requirements Syntax, Alistair Mavin et al, 18th IEEE International Requirements Engineering Conference (RE 10)
[8] BABOK. A Guide to the Business Analysis Body of Knowledge, v.3
[9] IEEE 24765 System and Software Engineering – Vocabulary