Відстеження вимог до програмного забезпечення до подальших елементів забезпечує численні переваги як під час розробки, так і під час додаткових покращень.
Зміни в програмному забезпеченні, які здаються простими, часто мають далекосяжні наслідки, вимагаючи змін у багатьох частинах системи. Аналіз впливу змін простіший, якщо у вас є дорожня карта, яка показує, де кожна вимога була реалізована в програмному забезпеченні. Інформація про трасування (або простежуваність) вимог документує логічні зв’язки між окремими вимогами та іншими елементами системи: іншими вимогами різних типів, бізнес-правилами, компонентами дизайну, об’єктами коду, тестами, довідковими файлами тощо.
Відстеження вимог – це інвестиція, яка збільшує ваші шанси на надання підтримуваного рішення, яке задовольняє всі заявлені потреби клієнтів. Ця інвестиція окупиться щоразу, коли вам доведеться модифікувати, розширити або замінити продукт. Збір даних трасування не вимагає особливих зусиль, якщо ви записуєте інформацію в міру виконання роботи, але майже неможливо відновити її для готового продукту.
Навіщо потрібні вимоги до трасування?
У мене був досвід, коли я писав програму, а потім розумів, що ненавмисно проігнорував вимогу. Це мене розчаровує. Відстеження вимог може продемонструвати повноту, а також відповідність специфікації, правилу, обмеженням, контракту або регламенту. На організаційному рівні впровадження відстеження вимог може покращити якість вашої продукції, зменшити витрати на технічне обслуговування та полегшити повторне використання. Ви повинні прийняти відстеження вимог з правильних причин, шукаючи переваги в цих категоріях.
- Відсутні вимоги. Шукайте бізнес-вимоги, які не пов’язані з вимогами користувачів або функціональними вимогами.
- Відокремлені вимоги (вимоги–сироти). Шукайте будь-які функціональні вимоги, які не пов’язані з якимось походженням.
- Тестування. Коли тест зазнає невдачі, зв’язки між вимогами, тестами та кодом вказують на ймовірні області для пошуку проблеми.
- Сертифікація та відповідність. Дані трасування свідчать про те, що вимоги, які вимагаються для дотримання нормативних вимог, були включені та враховані.
- Аналіз впливу змін. Без відомостей про трасування можна пропустити системний елемент, на який вплине додавання, видалення або змінення певної вимоги.
- Підтримка. Коли змінюється корпоративна політика або державне регулювання, програмні системи часто необхідно оновлювати. Таблиця, що показує, де було розглянуто кожне бізнес-правило у функціональних вимогах, дизайні та коді, є великою підмогою.
- Відстеження статусу. Дані трасування показують стан реалізації запланованого функціоналу. Відсутні посилання вказують на роботу, яку ще належить виконати.
Відстеження вимог
На малюнку 1 показані чотири типи вимог трасування зв’язків. Потреби клієнтів (бізнес-цілі, вимоги ринку, вимоги користувачів) простежуються відповідно до вимог, тому ви можете сказати, на які вимоги вони вплинуть, якщо ці потреби зміняться під час або після розробки. Повний набір прямих звʼязків дає впевненість у тому, що набір вимог відповідає всім заявленим потребам клієнта. І навпаки, ви можете простежити зворотний шлях від вимог до потреб замовника, щоб визначити походження кожної вимоги до програмного забезпечення.
Малюнок 1. Чотири типи відслідковування вимог.
Під час розробки ви можете відслідковувати вимоги, визначаючи зв’язки між окремими вимогами та конкретними елементами системи. Цей тип звʼязків перевіряє, що ви виконали всі вимоги, оскільки ви знаєте, які компоненти дизайну та коду відповідають кожному з них. (Однак це не підтверджує, що вони були реалізовані правильно!) Четвертий тип звʼязків відстежує конкретні елементи продукту назад до вимог, щоб ви знали, чому кожен елемент був створений.
Припустимо, тестувальник стикається з несподіваною функціональністю без відповідних вимог. Можливо, розробник впровадив вимогу, що мається на увазі або усно повідомлену. Або це може бути екземпляр надмірної імплементації («gold plating»), якому не місце у продукті. Звʼязки трасування можуть допомогти вам розібратися в таких ситуаціях і побудувати більш повну картину того, як частини вашої системи поєднуються одна з одною.
Тести, які пов’язані з вимогами, можуть виявити нереалізовані вимоги, оскільки очікувана функціональність буде відсутня. Трасування звʼязків також допомагає відстежувати залежності між окремими вимогами. Ця інформація розкриває поширення змін, яке може виникнути при видаленні або зміні певної вимоги.
Малюнок 2 ілюструє багато видів зв’язків простежуваності, які може визначити проект. Вам не обов’язково керувати всіма цими типами трасованих звʼязків. Можливо, вам потрібно лише відстежити системні тести відповідно до функціональних вимог або вимог користувача. Не просіть членів команди витрачати час на запис інформації, якщо ви не знаєте, як вони можуть її використовувати.
Малюнок 2. Деякі можливі вимоги трасування посилань.
Матриця простежуваності вимог
Поширеним способом запису зв’язків між елементами системи є матриця відстеження вимог, яку також називають матрицею відображення вимог або таблицею простежуваності. Коли я створював такі матриці в минулому, я створив таблицю, викладену як Таблиця 1, починаючи з вимог користувача. У міру того, як члени команди створювали додаток, ми поступово заповнювали порожні клітинки в матриці.
Таблиця 1. Один зі стилів матриці простежуваності вимог.
У таблиці 1 показано, як кожна функціональна вимога пов’язана з конкретним випадком використання і вперед до одного або декількох елементів дизайну, коду і тестування. (Звичайно, одна вимога користувача, як правило, породжує кілька функціональних вимог.) Елементи дизайну включають архітектурні компоненти, таблиці бази даних або класи об’єктів. Елементами коду можуть бути методи, збережені процедури, імена файлів вихідного коду або модулі у вихідному файлі. Включення більшої кількості деталей трасування вимагає більше роботи, але дає вам точне розташування пов’язаних програмних елементів.
Заповнені клітинки в матриці простежуваності вказують на виконану роботу. Заповнюйте інформацію в міру виконання роботи, а не так, як вона запланована. Тобто, вводити catalogSort у стовпці Code Element першого рядка таблиці 1 лише тоді, коли цей код буде повністю реалізовано.
Трасуючі зв’язки можуть визначати зв’язки «один-до-одного», «один-до-багатьох» або «багато-до-багатьох» між елементами системи. На малюнку 3 зображена двостороння матриця простежуваності. Кожна клітинка на перетині двох пов’язаних компонентів містить символ для позначення з’єднання. На малюнку 3 використовується стрілка, щоб вказати, що певна функціональна вимога простежується з конкретного випадку використання. Наприклад, FR-2 відстежується від UC-1, а FR-5 — як від UC-2, так і від UC-4. Це вказує на те, що функціональна вимога FR-5 повторно використовується у двох варіантах використання: UC-2 та UC-4.
Малюнок 3. Матриця простежуваності вимог, що показує зв’язки між варіантами використання та функціональними вимогами.
Деякі вимоги до атрибутів якості не простежуються безпосередньо в коді, але інші простежуються. Вимоги безпеки для автентифікації користувачів призводять до похідних функціональних вимог, які можуть бути реалізовані за допомогою паролів, біометрії або інших схем. У таких випадках ви можете простежити відповідні функціональні вимоги назад до їх батьківських нефункціональних вимог і вперед до подальших результатів, як зазвичай. малюнок 4 ілюструє можливий ланцюжок простежуваності, що включає нефункціональні вимоги.
Малюнок 4. Зразок ланцюжка відстеження для вимог, пов’язаних з безпекою додатків.
Хто виконує всю цю роботу?
Вам потрібно визначити ролі та осіб, які повинні надавати кожен тип інформації про трасування для вашого проекту. У таблиці 2 визначені деякі типові джерела знань про зв’язки між різними типами вихідних і цільових об’єктів. Переконайтеся, що члени команди розуміють відстеження вимог, чому це приносить користь і чому їх просять зробити свій внесок у процес. Додаткові витрати на фіксацію інформації про звʼязки під час виконання роботи невеликі. Це питання звички, дисципліни, налагодженого механізму зберігання та підтримки актуальності інформації.
Таблиця 2. Ймовірні джерела інформації про звʼязки.
Інструменти для трасування вимог
Неможливо виконати трасування вимог вручну для будь-яких, крім дуже малих додатків. Ви можете використовувати електронну таблицю для кількох сотень вимог, але більші системи вимагають більш надійного рішення. Відстеження вимог не може бути повністю автоматизоване, оскільки знання посилань зароджується в головах членів команди розробників. Однак після того, як ви визначили зв’язки, інструменти можуть допомогти вам керувати величезною кількістю інформації про трасування.
Більшість інструментів управління вимогами мають потужні можливості відстеження вимог. Ви можете зберігати вимоги та іншу інформацію в базі даних інструмента та визначати зв’язки між різними типами збережених об’єктів, включаючи однорангові зв’язки між двома вимогами одного типу. Інструмент, який зберігає як користувацькі історії, так і акцептанс тести, може пов’язати їх разом, але ви все одно не знатимете, де історії перетворилися на код.
Деякі інструменти можуть автоматично позначати посилання трасування як підозріле щоразу, коли об’єкт на обох кінцях посилання змінюється. Це нагадує вам перевірити, чи потрібно змінювати зв’язані елементи, щоб вони залишалися узгодженими зі зміненим об’єктом.
Процедура відстеження вимог
Розгляньте ці кроки, коли почнете впроваджувати трасування вимог:
- Визначте частини продукту, для яких ви хочете зберегти інформацію про простежуваність. Почніть з критично важливих основних функцій, частин з високим ризиком або частин, які, як ви очікуєте, зазнають найбільших змін протягом терміну служби продукту.
- Виберіть зв’язки, які потрібно визначити, з можливостей, показаних на малюнку
- Виберіть механізм зберігання даних: таблицю в текстовому документі, електронну таблицю або (набагато краще) інструмент.
- Визначте правила маркування, які ви будете використовувати, щоб надати кожному системному елементу унікальний, постійний ідентифікатор, щоб елементи можна було зв’язати разом.
- Визначте, хто відповідає за запис інформації про кожен тип посилання.
- Навчайте учасників розробки, щоб вони знали, коли і як оновлювати інформацію про посилання під час виконання завдання.
Чи можливе відстеження вимог? Чи це потрібно?
Ви можете вирішити, що накопичення інформації про трасування вимог коштує дорожче, ніж це вартує для вашого проекту. Це ваш вибір. Придбання інструменту з необхідними можливостями, його налаштування, введення даних та підтримання в актуальному стані потребує часу та грошей. Тільки ваша команда може вирішувати, чи додає відстеження вимог цінність вашому проекту та в якому ступені, а також його вартість.
Дані про звʼязки є важливими для певних життєво важливих продуктів. Наприклад, Федеральне управління цивільної авіації США вимагає простежуваності від вимог до конструкцій для сертифікації авіаційного програмного забезпечення. Аналогічним чином, Управління з санітарного нагляду за якістю харчових продуктів і медикаментів США (Food and Drug Administration) виступає за те, щоб виробники медичних виробів продемонстрували простежуваність вимог до продукту в подальших результатах в рамках процесу його валідації.
Навіть якщо ваша продукція не загрожує життю чи здоров’ю, ви повинні серйозно поставитися до відстеження вимог. Генеральний директор корпорації, який чув, як я описую відстеження вимог на навчальному курсі, запитав: «Чому б вам не зробити це для ваших стратегічних бізнес-систем?» Це глибоке питання. Як і у випадку з усіма програмними процесами, враховуйте як витрати на застосування будь-якої вдосконаленої практики, так і ризики, пов’язані з її невиконанням.
Оригінальна стаття – Links in the requirements chain, переклад – Іван Вільчавський. Оригінальне фото зі статті автора.