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

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

© О.А. Галкіна,

провідний аналітик департаменту розробки тиражних програмних продуктів «Бос-референт» компанії «Логіка бізнесу 2.0»

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

• Що таке управління вимогами?

• Як обробляти вимоги?

• За якими критеріями можна виділити найбільш актуальні з них?

Відео: Управління вимогами в agile-команді (частина 1)

• Як визначитися, які з вимог необхідно в першу чергу вжити в розробку, а які можна відкласти?

• Що ми розуміємо під аналізом вимог і як використовувати їх результати?

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

Відео: Аналітичні досліди. Управління вимогами в agile-проектах

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

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

Відео: 254) Управління вимогами в великих agile проектах - до, після, або замість

• виявити;

• зібрати;

• зафіксувати;

• проаналізувати;

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

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

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

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

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

Відео: IBM Rational для систем і програмного забезпечення. управління вимогами

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

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

Сценарій використання, варіант використання, прецедент або ж призначений для користувача сценарій (англ. 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.

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

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

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

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

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

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

• Запити користувачів (STRQ - Stake Holder Request) -первинна опис запитів, що надійшли від бізнес-користувачів.

• Вимоги до системи (FEAT) - функціональні вимоги до системи.

• Сценарій використання (BUC - Busyness Use Case) -Опис послідовності дій, які може здійснювати система у відповідь на зовнішні впливи користувачів або інших програмних систем.

• Елементи словника (GLS - Glossary) - визначення термінів, які використовуються при описі вимог.

• Нефункціональні вимоги (BR - Business Rules) -Вимоги до роботи системи в цілому: цілі та атрибути якості, обмеження.

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

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

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

• завершеність - вимога повністю визначено в одному місці і вся необхідна інформація присутня.

• Атомарність (Неподільність) - вимога не можна розділити на більш дрібні без втрати завершеності.

• одиничність - вимога описує одну і тільки одну річ.

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

• повнота - вимога має бути визначено для всіх можливих ситуацій.

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

• Відстеження - вимога відповідає діловим потребам, як заявлено зацікавленими особами та задокументовано.

• Верифікованість - реалізація вимоги може бути перевірена (протестована).

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

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

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

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

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

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

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

• власники процесів;

• ключові користувачі;

• документи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• колективний доступ різного рівня до запитів і требованіям-

• інформаційний обмін між співробітниками при зміні членів команди-

• зв`язування окремих вимог між собою-

• документірованіе-

• використання частин документів як джерела вимог-

• відстеження статусу кожного вимоги.

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

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

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

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

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

Атрибути вимог. Сортування вимог, аналіз

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

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

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

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

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

словник

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

На замітку!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Суб`єктивними причинами зміни вимог можуть бути:

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

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

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

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

• Незнання керівництвом конкретики внутрішніх процесів, які вони планують автоматизувати.

У цьому випадку, щоб знизити ризики, доцільно запрошувати на зустрічі виконавця (підрядника) та замовника фахівців в області діловодства - власників процесів, які будуть відповідати за проект.

• Неготовність потенційних користувачів до автоматизації або зміни процесів.

Справитися з цією проблемою допомагає навчання.

Об`єктивні причини полягають в тому, що:

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

• В процесі реалізації проекту змінюються власник продукту або власники процесів.

• На тривалих проектах можуть змінюватися самі процеси компанії.

Це нормально, так як будь-яка компанія розвивається, може рости і змінювати свою структуру і бізнес-процеси.

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

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

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

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

Верифікація змін вимог

Для мінімізації ризиків проекту всі зміни вимог повинні проходити верифікацію (позднелат. Verificatio - доказ, підтвердження, від лат. Verus - істинний і facio -Робиться), так як вони впливають на функції системи, які вже були позначені в затвердженій відповідальними особами документації.

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

документування вимог

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

• Технічне завдання.

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

• Технічний проект.

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

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

• Специфікація вимог (Requirements Specification).

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

• Use Case Model (Моделі прецедентів (варіантів використання)).

Це комплексна графічна модель варіантів використання з описом.

• User Story (Призначена для користувача історія).

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

На замітку!

У разі роботи з SCRUM відповідальність за верифікацію (відбір вимог) бере на себе власник продукту (product owner).