Варіанти формалізації вимог
Взагалі кажучи, вимоги як такі - це деяка абстракція. У реальній практиці вони завжди існують у вигляді якогось уявлення - документа, моделі, формальної специфікації, списку і т.д. Вимоги важливі як такі, тому що осідають у вигляді розуміння розробниками потреб замовника і майбутніх користувачів створюваної системи. Але так як в програмному проекті багато різних аспектів, видів діяльності і фаз розробки, то це розуміння може приймати дуже різні уявлення. Кожна вистава вимог виконує певне завдання, наприклад, служить "мостом", фіксацією угоди між різними групами фахівців, або використовується для оперативного управління проектом (відстежується, в якій фазі реалізації знаходиться та чи інша вимога, хто за нього відповідає і ін.), Або використовується для верифікації і модельно-орієнтованого тестування. І в першому, і в другому, і в третьому прикладі ми маємо справу з вимогами, але формалізовані вони будуть по-різному.
Отже, формалізація вимог в проекті може бути дуже різною - це залежить від його величини, прийнятого процесу розробки, які використовуються інструментальних засобів, а також тих завдань, які вирішують формалізовані вимоги. Більш того, може існувати паралельно кілька формалізацій, що вирішують різні завдання. Розглянемо варіанти.
Неформальна постановка вимог в листуванні по електронній пошті. Добре працює в невеликих проектах, при залученні замовника в розробку (наприклад, команда виконує субпідряд). Добре також при такому стилі, коли є взаєморозуміння між замовником і командою, тобто зайві формальності не потрібні. Однак, електронні листи в такій ситуації часто виявляються важливими документами - важливо вміти вести ділову переписку, підводити підсумки, зберігати важливі листи і користуватися ними при розбіжностях. Важливо також вчасно зрозуміти, коли такий спосіб перестає працювати і необхідні більш формальні підходи.
Вимоги у вигляді документа - опис предметної області і її властивостей, технічне завдання як додаток до контракту, функціональна специфікація для розробників і т.д.
Вимоги у вигляді графа з залежностями в одному із засобів підтримки вимог (Enterprise Architect). Таке уявлення зручно при частій зміні вимог, при відстеженні виконання вимог, при організації "прив'язки" до вимог завдань, людей, тестів, коду. Важливо також, щоб була можливість легко створювати такі графи з текстових документів, і навпаки, створювати презентаційні документи за такими графами.
Формальна модель вимог для верифікації, модельно-орієнтованого тестування і т.д.
Кожен спосіб представлення вимог повинен відповідати на такі питання:
- хто споживач (користувач) цього подання;
- як саме (з якою метою) це подання використовується.
Перерахуємо ряд помилок, що зустрічаються при складанні технічних завдань та інших документів до вимог.
1) Опис можливих рішень замість вимог.
2) Нечіткі вимоги, які не допускають однозначну перевірку, залишають недомовленості, мають відтінок рад, обговорень, рекомендацій: "Можливо, що має сенс реалізувати також ... ..", "і т.д.".
3) Ігнорування аудиторії, для якої призначене уявлення вимог. Наприклад, якщо специфікацію становить інженер замовника, то часто зустрічається надлишок інформації про обладнання, з яким повинна працювати програмна система, відсутня глосарій термінів і визначень основних понять, використовуються численні синоніми і т.д. Або допущений занадто великий ухил в бік програмування, що робить дану специфікацію незрозумілою всім непрограмістів.
4) Пропуск важливих аспектів, пов'язаних з нефункціональними вимогами, зокрема, інформації про оточення системи, про терміни готовності інших систем, з якими повинна взаємодіяти дана. Останнє трапляється, наприклад, коли дана програмна система є частиною більшого проекту. Типові проблеми при створенні програмно-апаратних систем, коли апаратура не встигає вчасно і ПО неможливо тестувати, а в термінах і вимогах це не передбачено.