Управління вимогами користувачів при розробці сед: збираємо, аналізуємо, використовуємо

Висуваючи будь-які вимоги треба розуміти, що процес їх збору, а особливо їх акумуляції та аналізу досить трудомісткий і вимагає великих затрат часу, що ростуть геометрично з накопиченням загальної маси вимог. З іншого боку, вимоги - це та основа, при грамотному узагальненні та структуруванні якої може бути побудована потрібна організації система. У цій статті ми розберемося в тому: що таке управління вимогами? як обробляти вимоги? за якими критеріями виділити найбільш актуальні з них? як визначитися які з вимог необхідно в першу чергу вжити в розробку, а які можна відкласти? що ми розуміємо під аналізом вимог і як використовувати їх результати?

управління вимогами - це процес збору побажань власників процесів, первинна обробка і аналіз цих запитів, документування вимог, визначення найбільш пріоритетних з них, контроль їх зміни і контроль реалізації.

Під час роботи на будь-якому проекті неминуче виникає велика кількість різноманітних побажань до функціоналу системи. Як же впоратися з цим потоком запитів?

Щоб обробити і використовувати вимоги з максимальною вигодою необхідно їх:

• виявити;
• зібрати;
• зафіксувати;
• проаналізувати;
• максимально корисно використовувати при підготовці документів.

Види вимог, порядок їх надходження

Перші побажання до функціоналу системи починають виникати ще на етапі підготовки до початку проекту або на етапі пресейл (передпродажної активності). Надходять ці запити зазвичай від керівників, що ініціюють впровадження СЕД, і власників процесів. Такі потреби верхнього рівня допомагають визначити Скоуп (сферу застосування) - рамки майбутньої системи.

Крім керівників і ключових учасників автоматизованих процесів джерелом вимог можуть бути і нормативні і законодавчі акти, стандарти, регламенти підприємства та інші документи.

Вимоги можуть запитувати як реалізацію окремих функцій, так і бути загальними нефункціональними вимогами до всієї системи.

функціональні вимоги (FEAT-Functional Requirements) - визначають функціональність (поведінку) програмної системи, яка повинна бути створена розробниками для надання можливості виконання користувачами своїх обов`язків в рамках бізнес-вимог і в контексті призначених для користувача вимог.

Відео: Лекція 10: Розробка та управління вимогами до системи

нефункціональні вимоги (BR-Business Rules) - один з критеріїв роботи системи в цілому, а не окремі сценарії використання. Нефункціональні вимоги описують цілі і атрибути якості, обмеження. Містять або пов`язані з корпоративними регламентами, політиками, стандартами, законодавчими актами, внутрішньокорпоративними ініціативами, обліковими практиками, алгоритмами обчислень і т.д. Вони можуть визначати такі властивості системи в цілому як продуктивність, зручність супроводу, розширюваність, надійність, умови експлуатації.

Функціональні вимоги можна описувати у вигляді сценаріїв використання (Use Case).

сценарій використання, варіант використання, прецедент або ж призначений для користувача сценарій (Англ. Use Case) - у галузі розробки програмного забезпечення та системному проектуванні це опис поведінки системи, яким вона відповідає на зовнішні запити. Іншими словами, сценарій використання описує, «хто» і «що» може зробити з розглянутої системою.

Функціональні вимоги можуть доповнюватися графічними моделями. Візуальне моделювання полегшує сприйняття складних технічних документів. Зазвичай діаграми розробляються відповідно до загальноприйнятих нотаціями - комплексом умовних позначень і правил їх використання (наприклад, UML, BPMN, IDEF0). Однак, цілком допустимо і використання своїх правил і умовних позначень, які повинні бути описані і включені до діаграм.

UML (Англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об`єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це - відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML-моделлю. UML був створений для визначення, візуалізації, проектування та документування, в основному, програмних систем.

BPMN (Англ. Business Process Model and Notation, нотація і модель бізнес-процесів) - система умовних позначень (нотація) для моделювання бізнес-процесів. Остання версія - 2.0.

IDEF0 (англ. Integrated DEFinition) - методологія функціонального моделювання. За допомогою наочного графічного мови IDEF0 досліджувана система постає перед розробниками і аналітиками у вигляді набору взаємопов`язаних функцій (функціональних блоків - в термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи.

Використовуючи візуальне моделювання треба пам`ятати, що без словесного детального опису будь-яка діаграма, незалежно від використовуваної нотації, сенсу не має і може бути прочитана некоректно.

Далі вимоги деталізуються і використовуються при написанні таких документів, як технічне завдання і технічний проект.

Інший варіант фіксування вимог, що отримав популярність останнім часом у зв`язку з використанням методології SCRUM - це User Story.

Відео: PROдвінутое Управління Вимогами

Scrum - методологія управління проектами, активно застосовується при розробці інформаційних систем для гнучкої розробки програмного забезпечення. Scrum робить акцент на якісному контролі процесу розробки. Розробка програмного забезпечення ведеться короткими ітераціями. Після кожної ітерації відбувається здача закінченою частини функціоналу та коригування цілей проекту. Для методології характерно спрощення в частині документування розробки.

User Story - це нам інформацію про те вимог до розроблюваної системі, сформульованих як одне або більше пропозицій на бізнес-мовою користувача.

При використанні західних стандартів вимоги використовуються при підготовці такої документації, як специфікація вимог, концепція, комплексна модель варіантів використання, призначені для користувача історії (user story).

Який би спосіб опису ви не вибрали, вимоги повинні містити зрозумілий опис самої бізнес-ситуації.

Паралельно на першому етапі збору вимог необхідно розробити словник термінів (Glossary). Він дозволить забезпечити одне з найважливіших якостей вимог - зрозумілість. А головне, дозволить говорити розробникам і користувачам на одній мові і уникнути безлічі непорозумінь. Найчастіше під одним і тим же терміном фахівці в різних областях мають на увазі зовсім різне.

Таким чином, можна виділити наступні види вимог:

• Запити користувачів (STRQ - Stake Holder Request) - первинне опис запитів, що надійшли від бізнес-користувачів.
• Вимоги до системи (FEAT) - функціональні вимоги до системи.
• Сценарій використання (BUC - Busyness Use Case) - опис послідовності дій, які може здійснювати система у відповідь на зовнішні впливи користувачів або інших програмних систем.
• Елементи словника (GLS - Glossary) - визначення термінів, які використовуються при визначенні вимог.
• Нефункціональні вимоги (BR - Business Rules) - вимоги до роботи системи в цілому: цілі та атрибути якості, обмеження.

Мал. 1. Види вимог

При зборі і формулюванні вимог до системи необхідно дотримуватися основних критерії їх якості:

• Зрозумілість (недвозначність) - вимога повинна бути зрозуміло сформульовано (виключати неоднозначне тлумачення).

Вимога має бути визначено без використання технічного жаргону. Воно виражає об`єкти і факти, а не суб`єктивні думки. Можлива одна і тільки одна його інтерпретація. Визначення не містить нечітких фраз, використання негативних і складових тверджень заборонено.

Відео: Управління вимогами VS Розробка вимог. Принципи та інструменти

• завершеність - вимога повністю визначено в одному місці і вся необхідна інформація присутня.
• Атомарність (неподільність) - вимога не можна розділити на більш дрібні без втрати завершеності.
•  одиничність - вимога описує одну і тільки одну річ.
• унікальність - кожне вимога повинна однозначно ідентифікуватися (повинен використовуватися унікальний ідентифікатор вимоги).
• повнота  - вимога має бути визначено для всіх можливих ситуацій.
• Несуперечливість (послідовність) - вимога не суперечить іншим вимогам і документації в цілому.
• Достатність деталізації - необхідно дотримуватися достатній ступінь деталізації для того щоб була можливість завершити реалізацію вимоги.
• Відстеження - вимога відповідає діловим потребам як заявлено зацікавленими особами і задокументовано.
• Верифікованість - реалізація вимоги може бути перевірена (протестована).

джерела вимог

Беручи вимоги, необхідно в обов`язковому порядку фіксувати джерело вимог. Важливо для адекватності вимог щоб джерелом вимоги був компетентний співробітник - керівник або власник продукту, власник процесу, ключовою фахівець.

 власник продукту (Product Owner) - це людина, яка відповідає за розробку продукту при роботі за методологією SCRUM. Як правило, це менеджер продукту для продуктової розробки, менеджер проекту для внутрішньої розробки і представник замовника для розробки на замовлення. Власник продукту - це єдина точка прийняття остаточних рішень для команди в проекті.

На етапі пресейл вимоги верхнього рівня визначаються керівництвом компанії. Далі необхідно в ході обстеження спускатися глибше в організацію для деталізації процесів. Як правило, при спілкуванні з керівництвом можна з`ясувати, до кого конкретно з працівників звернутися на більш низькому рівні, щоб дізнатися деталі процесів.

Визначитися з вимогами до системи допоможуть і регламенти організації, якщо вони є актуальними.

Таким чином, джерелами вимог є:

• керівництво (або власник продукту);
• власники процесів;
• ключові користувачі;
• документи.

Хто приймає вимоги

Так як вимоги надходять з різних джерел і в ході проекту можуть змінюватися, то особи, які беруть їх, можуть бути різними. Для того, щоб з`єднати разом ці потоки запитів і акумулювати їх, повинно бути особа, яка приймає і структурирующее вимоги. Зазвичай це аналітик проекту.

На етапі передпроектної підготовки (пресейл) вимоги верхнього рівня, що визначають автоматизує процеси, надходять від керівництва. Вони фіксуються аналітиком, але можуть надходити і до керівника проекту в ході його спілкування з топ-менеджерами.

Подальший збір вимог відбувається на етапі обстеження аналітиком. На підставі зібраних вимог аналітик готує документацію по системі.

Після розробки за технічною документацією, яка враховує зібрані вимоги, система надходить в дослідну експлуатацію. У цей момент починають приходити нові вимоги від безпосередніх користувачів системи. Як правило, якщо система розроблена якісно, то на етапі дослідної експлуатації надходять невеликі вимоги по інтерфейсу і запити на розширення функціональності системи.

Дуже важливо з самого початку виділити співробітника, відповідального за управління вимогами, і визначити процеси зі збору вимог. В іншому випадку, вимоги почнуть губитися. Всі ці домовленості необхідно зафіксувати в документі План управління вимогами.

Як правило, відповідає за управліннями вимог аналітик проекту, саме йому повинні передаватися абсолютно всі вимоги, що надходять від користувачів будь-якого рівня, незалежно від того, кому ці вимоги зі співробітників робочої групи проекту повідомлялися: продавцям, менеджерам, керівнику проекту або інженеру впровадження. Контролює і керує процесом збору вимог і обов`язковістю їх передачі аналітику - керівник проекту.

Інструменти для управління вимогами

Вимоги, що надходять до аналітику з різних джерел треба збирати і зберігати таким чином, щоб вони були доступні всій робочій групі. В принципі, інструмент в процесі збору вимог не настільки важливий як, наприклад, дисципліна і уважність співробітників, які беруть вимоги.

Можна, наприклад, використовувати для збору вимог файл, створений в MS Exel або MS Word. Виглядати це буде приблизно ось так:

Мал. 2. Список надійшли запитів

Однак при використанні додатків MS Office може виникнути ряд проблем, пов`язаних з тим, що такий файл не доступний іншим і легко може бути втрачено при зміні співробітника, відповідального за збір вимог до системи.

Крім того, повинен бути ще ряд можливостей, які повинні забезпечувати інструмент управління вимогами.

Кожен запит повинен заводитися як окремий об`єкт. Тоді можна формувати за заданими правилами відбору уявлення вимог (фільтри), що дозволить робити аналіз.

При цьому можна буде проводити аналітику по цих об`єктах: фільтрувати накопичені вимоги за певними параметрами, переглядати їх подання з заданим набором параметрів, а також вивантажувати їх у вигляді списків для розгляду робочою групою.

Крім того, повинна бути можливість зв`язування вимог між собою.

У нас в країні прийнято оформляти вимоги у вигляді документа, а не списку. Тому необхідна можливість вивантаження вимог в форматі певного документа. Наприклад, у вигляді специфікації вимог. Це потрібно для того, щоб не робити подвійну роботу: на початку заводити вимоги, а потім оформляти їх вручну у вигляді документа.

Джерелом вимоги може бути документ. У цьому випадку зручно зберігати документ цілком, але відображати у вигляді окремих вимог критичні для майбутнього функціоналу СЕД частини документа.

Таким чином, інструмент для управління вимогами повинен забезпечувати:

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

Найпростіше рішення - зберігати вимоги на корпоративному ресурсі. Це може бути папка проекту на мережевому диску або файл з вимогами може бути викладений, наприклад, на порталі організації, а необхідний рівень доступу до нього буде надано співробітникам, які беруть участь в управлінні вимогами.

Однак максимально зручне управління вимогами забезпечують спеціалізовані системи, призначені для управління вимогами: наприклад, спеціальні програмні продукти для управління вимогами компанії IBM - Requisite Pro або більш функціональний Rational DOORS.

Також для управління вимогами можна використовувати такі продукти як HP Requirements Management, RequirementsWin, BorlandCaliber RM, SybasePowerDesigner, і інші.

Нижче на малюнку показаний приклад представлення даних в спеціалізованому інструменті для управління вимогами.

Мал. 3. Приклад подання списків запитів в спеціалізованій системі управління вимогами

У спеціалізованих системах автоматично забезпечується збереження історії зміни вимоги (автор, дата, час зміни), версійність і присвоєння унікального ідентифікатора, забезпечується колективне управління вимогами на різних рівнях доступу, централізоване зберігання інформації, можливість аналізу і побудови різних представлень даних, зв`язування вимог, автоматичного формування документації в заданому форматі, «нарізання» документів на окремі вимоги, трасування виконання.

СЛОВНИК

трасування - відстеження послідовності виконання інструкцій програми використовується як метод налагодження програмного коду при розробці комп`ютерних програм.
Атрибути вимог. Сортування вимог, аналіз

Для того щоб аналізувати і маніпулювати вимогами при розробці системи необхідно супроводити їх атрибутами. Мінімально необхідні для оцінки атрибути вимог - це вартість (або трудомісткість) і важливість. Так само у вашому первинному описі надійшов запиту від зацікавленої особи обов`язково повинна бути інформація про співробітника, від якого надійшла вимога - тобто джерело вимоги (ПІБ та посада власника вимоги або інше джерело).

Крім цього необхідно вказувати для кожного вимоги унікальний ідентифікатор (номер запиту), дату надходження вимоги, хто зафіксував вимога, статус, важливість, трудомісткість, дату розгляду робочою групою проекту, прийняте рішення на вимогу, пов`язані вимоги, категорію.

У спеціалізованих системах для управління вимогами атрибути унікальний номер і автор запису присвоюється вимогам автоматично.

вступники вимоги можна і потрібно аналізувати, групувати і структурувати, щоб створити «скелет», на підставі якого буде побудована система.

Зручно категоризувати вимоги за видами автоматизованих процесів. Таке групування вимог дозволяє побачити структуру всієї системи більш ясно, щоб використовувати її в процесі розробки.

Наприклад, можна поділяти вимоги за категоріями: «процес роботи з вхідними документами», «розробка нового інтерфейсу», «адміністрування та налаштування» і т.д.

При отриманні змін вимог на етапі дослідної експлуатації їх категорирование так само дозволяє побачити слабкі місця (неопрацьований функціонал) системи.

Для того, щоб маніпулювати вимогами вищеописаним чином, зручно, якщо кожне вимога буде фіксуватися і оформлятися як окремий об`єкт.

Таким чином, спеціалізовані програмні продукти для управління вимогами дозволяють робити аналіз вимог в різних розрізах.

Якщо проект планується розвивати, то необхідно подумати про придбання таких інструментів.

формалізація вимог

Після обробки всіх запитів, їх атрибутування і аналізу необхідно описати безпосередньо вимоги, які будуть реалізовані в системі. Вимога до реалізації зазвичай досить сильно відрізняється від початкового запиту користувача (STRQ). І це нормально. Опис вимоги до реалізації повинно мати формалізований характер, а часто аналітик або розробник можуть запропонувати користувачеві інше більш універсальне або просте рішення проблеми, ніж те, яке бачить власник запиту.

З одним призначеним для користувача запитом може бути пов`язано кілька вимог. А іноді вимога визначається на підставі відразу декількох запитів. Всі ці зв`язки так само необхідно відображати в атрибутах запитів і вимог.

Зміна вимог. коригування цілей

Вимоги можуть змінюватися протягом усього проекту реалізації системи (особливо в разі використання методології SCRUM). Правильніше сказати, вони не можуть не змінюватися по ряду об`єктивних факторів і суб`єктивних причин.

Після розробки основних проектних документів і навіть після закінчення розробки системи або її частин (при роботі за методологією SCRUM) надходження запитів від користувачів триває. Великий потік нових вимог або їх змін виникає коли користувачі вперше зустрічаються віч-на-віч з системою: на етапах приймально-здавальних випробувань системи або її частин, на дослідній експлуатації, на презентаціях закінченою частини функціоналу при роботі по SCRUM.

І не завжди те, що користувачі очікували побачити, співпаде з тим, що створили за їхніми вимогами.

На етапі дослідної експлуатації починається «притирання» користувачів і СЕД один до одного. Виникає велика кількість нових запитів. Але вони вже відрізняються від тих, що були на попередніх етапах пресейл і розробки.

Якщо на етапі пресейл і проектування звучали вимоги досить високого рівня, наприклад, про необхідність автоматизувати ті чи інші процеси, а якщо і звучали конкретні вимоги низького рівня, то вони мали хаотичний характер. На етапі дослідної експлуатації при роботі з системою вже надходять вимоги набагато більш детальні.

Будь-які зміни вимог, що надійшли на етапі дослідної експлуатації, фіксуються в журналі дослідної експлуатації інженерами впровадження або аналітиками незалежно від того, чи будуть вони прийняті в розробку і чи планується подальший розвиток системи.

Зміна вимог природний процес і пов`язане це з рядом причин.

• Визначитися з інструментами прийому запитів та управління вимогами відповідно до даних в цій статті рекомендацій.
• Сформувати робочу групу проекту та розподілити обов`язки в команді проекту: хто буде відповідати за управління вимогами, хто буде їх приймати, фіксувати і верифікувати.
• Визначитися з критеріями аналізу і порядком реалізації вимог.
• Визначитися яким чином буде проходити верифікація вимог і їх змін, а так само їх документування.
• Описати вищевказані правила в документі План управління вимогами та узгодити його із зацікавленими особами.

Організація, що впроваджує СЕД, може і повинна брати участь в управлінні своїми вимогами, навіть якщо сам продукт розробляє спеціально запрошена для цього ІТ-компанія.

Маю велику надію, що мої поради допоможуть вам не загубитися в потоці вимог, максимально використовувати їх в розробці і створити актуальну систему, здатну принести вигоду вашій організації.