Варіанти формалізації вимог

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

Отже, формалізація вимог в проекті може бути дуже різною – це залежить від його величини, прийнятого процесу розробки, використовуваних інструментальних засобів, а також тих завдань, які вирішують формалізовані вимоги. Більш того, може існувати паралельно декілька формалізацій, вирішальних різні завдання. Розглянемо варіанти.

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

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

3. Вимоги у вигляді графа із залежностями в одному із засобів підтримки вимог (IBM Rational RequisitePro, DOORS, Borland CALIBERRM і нек. ін.). Таке уявлення зручне при частій зміні вимог, при відстежуванні виконання вимог, при організації "прив'язки" до вимог завдань, людей, тестів, коду. Важливо також, щоб була можливість легко створювати такі графи з текстових документів, і навпаки, створювати презентаційні документи по таких графах.

4. Формальна модель вимог для верифікації, модельно-орієнтованого тестування і так далі

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

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

· Опис можливих рішень замість вимог.

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

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

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

<== попередня сторінка	\|	наступна сторінка ==>
Дисципліна зобов'язань	\|	Цикл роботи з вимогами

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.06 сек.