Найповніший посібник із керування вимогами та відстеження
Як запровадити інструмент керування вимогами
Зміст
Як запровадити інструмент керування вимогами?
Щоб запровадити інструмент керування вимогами, ви можете зробити кілька кроків.
По-перше, вам потрібно визначити зацікавлених сторін і користувачів інструменту. Це включає керівників проектів, бізнес-аналітиків, розробників, тестувальників та інших людей, які використовуватимуть його. Ви також повинні визначити, який тип системи управління вимогами найкраще підходить для вашої організації на основі її розміру, складності проектів та інших факторів.
Далі вам слід вирішити, який програмний інструмент або платформу ви хочете використовувати для процесу керування вимогами. Сьогодні на ринку доступно багато різних типів, наприклад Visure. Після того, як ви вирішили, який з них найкраще відповідає потребам вашої організації, настав час налаштувати систему. Це може включати створення облікових записів користувачів, налаштування рівнів доступу для різних користувачів і налаштування параметрів для забезпечення належної роботи програмного забезпечення.
Коли ваш інструмент керування вимогами налаштовано належним чином, настав час почати ним користуватися! Ви повинні визначити шаблони для збору та організації вимог від зацікавлених сторін. Крім того, вам слід створити процес і набір правил, які гарантуватимуть правильне документування кожної вимоги, щоб вони відповідним чином відстежувалися протягом усього життєвого циклу. Нарешті, ви повинні встановити процес перевірки, щоб усі зміни або оновлення вимоги були належним чином перевірені перед впровадженням.
Навіщо потрібен інструмент керування вимогами?
Ні для кого не секрет, що низькі вимоги призводять до неякісних продуктів і що ці проекти часто наповнені розмахом. Проблем, пов’язаних із підходом до вимог, що базується на документах, є багато, включаючи той факт, що їх важко оновлювати в умовах розробки програмного забезпечення, що постійно змінюється. Навіть якщо ви зробили чудову роботу зі збору та документування вимог користувачів, завдання керування вимогами тільки почалося.
Ось кілька основних причин використання автоматизованого інструменту управління вимогами згідно з Карлом Вігерсом (стаття www.processimpact.com про автоматизацію управління вимогами).
Керуйте версіями та змінами. Сьогодні більшість систем випускаються ітеративним (або гнучким) способом. Це означає, що вимоги матимуть версії, пов’язані з випуском. Вміння відстежувати зміни та визначати вплив змін на контроль змін і повзучість масштабу.
Зберігайте додаткову інформацію про вимогу в атрибутах вимог. Нам потрібно знати набагато більше про вимогу, окрім формулювання вимоги. Наприклад, статус вимог, пріоритет, запитувач і статус перевірки. Це лише деякі пропозиції.
Пов'язати вимоги з іншими елементами системи. Щоб переконатися, що всі вимоги є частиною продукту, усі вимоги перевірені, зміни оцінені тощо, ми повинні мати можливість зв’язувати вимоги з іншими елементами системи.
Відстежити статус. Подумайте про можливість створити список усіх вимог, які не затверджені, усіх вимог, які не пов’язані з вимогами нижчого рівня, і всіх вимог, які не перевірені. Саме така інформація допомагає нам справді знати статус проекту.
Перегляд підмножин вимог. Подумайте про можливість перегляду всіх вимог з високим пріоритетом, яким не призначено метод тестування. Або служба безпеки, яка хоче переглянути лише вимоги, пов’язані з безпекою. Можливість фільтрувати вимоги, щоб включати лише інформацію, яку цікавить користувач, скорочує час, необхідний для перегляду цих вимог.
Контроль доступу. Ви захочете переконатися, що бізнес-аналітики можуть лише змінювати вимоги користувачів; системні аналітики можуть лише змінювати системні вимоги тощо. Після схвалення доступ до вимог має бути обмежено, щоб не можна було вносити подальші зміни без перевірки.
Спілкуйтеся із зацікавленими сторонами. Повідомлення про зміни має важливе значення для того, щоб зацікавлені сторони були в курсі всіх потенційних змін. Більшість інструментів керування вимогами можуть допомогти в автоматичному наданні сповіщень такого типу.
Для тих із нас, хто користувався інструментами керування вимогами, важко уявити собі повернення до виконання цієї роботи на папері. І я вважаю, що мало хто з нас вирішив би повернутися до цього методу. Я особисто віддав би перевагу будь-якому інструменту керування вимогами документальному підходу. Однак мене вражає те, що багато організацій будь-якого розміру продовжують покладатися на інструменти, засновані на документах, для управління своїми вимогами. Використання інструменту керування вимогами є обов’язковим першим кроком до отримання контролю над вимогами.
Перш ніж купувати інструмент керування вимогами...
Не секрет, що професійні інженерні рішення вимог допомагають підвищити ефективність роботи з вимогами. Вони також допомагають мінімізувати кількість помилок, які, як правило, призводять до дорогих виправлень, якщо їх виявити на пізніших етапах життєвого циклу розробки.
Тому багато компаній шукають такі рішення для розробки вимог, але, на жаль, те саме правило, що майже для будь-якого іншого типу програмного засобу, також застосовується до рішень для розробки вимог: дурень з інструментом залишається дурнем…
Найкращі у своєму класі інженерні рішення вимог, як-от платформа Visure Requirement ALM, є дуже гнучкими та здатні підтримувати практично будь-який процес розробки вимог. Звичайно, ми, як постачальники інструментів, раді продати вам програмне забезпечення, але ми переконані, що одне це вам не допоможе. Натомість ми хочемо допомогти вам досягти успіху у використанні наших продуктів.
Отже, перш ніж придбати рішення для розробки вимог, переконайтеся, що у вас є належний процес розробки вимог, визначений певними діями, призначеними певним ролям. Звичайно, ми також можемо поділитися з вами нашим досвідом у цій сфері. Якщо ви знаєте детальні характеристики свого процесу, вам набагато легше знайти відповідне рішення, яке відповідає потребам вашого процесу.
6 порад для успішного впровадження інструменту керування вимогами
Багато років тому я кілька років працював над дуже складною системою керування зброєю. Як ви можете собі уявити, вимоги були великими, складними та часто змінювалися. Ми витратили багато часу, просто намагаючись впоратися з тими неприємними змінами, які надходили як від клієнтів, так і від розробників. У ті перші дні у нас не було інструментів керування вимогами, які б допомогли оцінити ці зміни. Ми використовували Interleaf і Excel (тепер я чую стогони болю). Усе робилося вручну, включно з нашим комплексним відстеженням. У нас була пара людей, які нічого не робили, крім підтримки матриць відстеження та оцінки впливу змін. У цей час у нас була відстежуваність лише від концепції операцій до системних вимог до вимог до підсистеми. Я кажу «тільки», але на той час мати такий рівень відстеження було великим досягненням.
Коли у нас було достатньо змін, ми видали новий документ системних вимог і новий документ вимог до підсистеми. Тим бідним підрядникам довелося пройти через величезні вимоги до підсистеми та вручну визначити, що змінилося. Я не можу уявити, скільки часу підрядники витратили на те, щоб зрозуміти, про які зміни їм потрібно потурбуватися.
Саме в середині цього проекту оновлення клієнт сказав, що достатньо, і доручив моїй команді оцінити та вибрати інструмент керування вимогами. Інструмент, який ми вибрали, не є важливим для цієї конкретної дискусії, але те, що ми дізналися з цього вибору та впровадження інструменту, є важливим. Ось деякі з уроків.
(1) – Не існує жодного інструменту, який би сподобався всім. У нас були користувачі, яким сподобався наш вибір, і ті, хто боровся з нами на кожному кроці. Без клієнта, який підтримує та запроваджує зміни, це було б неможливо для такої великої програми, як ця. Один користувач скаржився на розмір стовпця матриці відстеження, створеної інструментом, повністю ігноруючи той факт, що це заощадило йому кілька днів ручних зусиль.
(2) – Наше ручне відстеження було не дуже чистим. Після того як ми імпортували всю нашу інформацію в інструмент і пов’язали її, ми виявили багато прогалин у відстежуваності. Більше тривожило те, що ми мали посилання, які насправді не мали жодного сенсу. Нам довелося виконати багато роботи, щоб очистити наші матриці відстеження.
(3) - Просто відстежувати вимоги було чудово, але тепер ми могли використати ті самі зусилля, щоб пов’язати вимоги з планами тестування, і пішли настільки далеко, що зв’язали вимоги до підсистеми з проектними документами, які ми могли переглянути. Це не сталося відразу, але це сталося. Згодом ми могли б відстежити системні вимоги від вимог до підсистеми до проектного документа до модуля коду. Ми навіть використовували інструмент для визначення складності модулів коду та використовували його, щоб допомогти визначити, наскільки складно буде впровадити та протестувати зміни.
(4) – Показники інструменту вимог є ключовими для розуміння повноти тестування. Ми часто думали, що завершили тестування на 50%. Адже 50% тестів виконано. Однак ми виявили, що ми схильні спочатку тестувати найпростіші та зрозумілі частини системи. Отже, хоча ми завершили роботу на 50%, усе, що залишилося, було дуже ризикованим. Ми навчилися розставляти пріоритети для нашого тестування, дивлячись на пріоритети вимог і складність програмного забезпечення, інформацію, яку ми не могли визначити за допомогою відстеження вручну.
(5) – Це було дуже легко бути приголомшеним. Почніть з простого. Нам довелося відмовитися від наших амбітних ідей і почати з простої моделі відстеження. У міру того, як ми дізналися та набули більше досвіду роботи з інструментом, ми додали більше інформації до нашої моделі. Ми постійно оцінювали наш процес, щоб зрозуміти, що ще можна зробити, щоб покращити його.
(6) - Не економте на навчанні та наставництві. Ми навчили всіх учасників проекту та створили експертів, які допомагали користувачам подолати початкові перешкоди. Ми надсилали наших експертів до наших підрядників на тижні, щоб допомогти їм навчитися швидко користуватися інструментом. У нас навіть була своя внутрішня група користувачів. Будьте готові до таких зусиль.
Який чудовий досвід навчання був для мене. Якщо ви зацікавлені в подібних змінах, щоб покращити процес виконання своїх вимог, зверніться до Visure Solutions. Ми будемо раді обговорити з вами ваш процес.
Не забудьте поділитися цим постом!
Почніть наскрізну відстежуваність своїх проектів із Visure вже сьогодні
Почніть 30-денну безкоштовну пробну версію вже сьогодні!