Функції

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

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

Рекомендована кількість функцій, яка дає повне представлення про систему, яка розробляється, 25–99, однак бажано, щоб їх число не перевищувало 50.

Після того як всі функції перераховані, можна приступити до прийняття рішення виду «відкласти до наступної версії», «реалізувати негайно», «повністю відкинути» або «дослідити додатково». Цей процес коректування краще проводити на рівні функцій, а не на рівні вимог, інакше можна зав’язнути в деталях.

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

Атрибут	Описання/приклади значень функції
Статус	· Припущена · Затверджувана · Включена
Пріоритет/корисність	· Критична · Важлива · Корисна
Трудоємність	· Низький рівень · Середній рівень · Високий рівень
Ризик	Ймовірність того, що функція викличе небажані наслідки, такі як збільшення розходів, відставання від графіка чи навіть закриття проекту. · Високий · Середній · Низький
Стабільність	Ймовірність того, що дана функція буде мінятися чи буде мінятися її розуміння командою · Висока · Середня · Низька
Цільова версія	Вказування версії продукту, в якій вперше з’явиться реалізація даної функції
Призначення	Інформація для розробників
Обґрунтування	Посилання на джерело функції

Методи виявлення вимог:

· інтерв’ювання та анкетування;

· наради, присвячені вимогам;

· мозковий штурм та відбір ідей;

· розкадровки;

· прецеденти;

· обігравання ролей;

· створення прототипів.

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

· чому існує проблема?

· як вона розв’язується в даний момент?

· як замовник хотів би її розв’язувати?

· хто такі користувачі?

· які навики користувачів в комп’ютерній області?

Після цього інтерв’ювер перераховує основні пункти, щоб перевірити, чи все було правильно зрозуміло: «Отже, ви сказали мені …» (перечислюються описані замовником проблеми словами). «Які ще проблеми вам надокучають?»

Правила підготовки інтерв’ю:

1. Всі запитання повинні біти складені наперед.

2. Перед інтерв’ю потрібно познайомитись з інформацією про клієнта.

3. Коротко записуйте відповіді.

Наради. Добре проведена нарада по питанням вимог має багато переваг:

· допомагає створити команду, підпорядковану одній цілі – успіху даного проекту;

· всі зацікавлені особи отримують можливість висказати свою думку, ніхто не залишається в стороні;

· формує згоду між зацікавленими особами і командою розробників по поводу того, що повинен робити додаток;

· може висвітлити і розв’язати політичні питання, які впливають на успіх проекту;

· результат, попереднє визначення системи на рівні функцій, одразу ж стає відомим.

Всі матеріали до наради повинні бути представлені учасникам заздалегідь.

Мозковий штурм. Всі основні учасники збираються в одній кімнаті, їм роздаються матеріали для заміток – не менше 25 листків формату від 7×12 до 12×17.

Правила проведення мозкового штурму:

1. Не допускається критика чи дебати.

2. Дайте свободу фантазії.

3. Генеруйте як більше ідей.

4. Перероблюйте і комбінуйте ідеї.

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

Ідеї обов’язково записують на папір по наступним причинам:

1. Зберігається авторське формулювання.

2. Існує гарантія, що вони не будуть втрачені.

3. Є перспектива розвитку ідеї в подальшому.

4. Забезпечується неперервний творчий процес – не потрібно чекати, поки секретар записує думку учасника.

Розкадровка. Ціль розкадровки у ранньому виявленні реакції типу «так, але…». Існує три типа розкадровок.

1. Пасивні. Користувачу викладають деяку історію з використанням малюнків, схем, картинок з екрана.

2. Активні. Користувачу показують «ще не створений фільм» з використанням анімації чи слайдів.

3. Інтерактивні. Користувач отримує реальний досвід взаємодії з системою (майже так, як і на практиці).

Використання прецедентів. Малюються схеми з факторами; в овалі пишеться вид дії.

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

Також дуже ефективним способом є створення сценаріїв на основі CRC-карточок. Карточки описують об’єкт, його поведінку і взаємодію з іншими об’єктами системи. Учасники ділять карточки між собою і використовують їх для ролевої гри, виконуючи дії згідно передписаному. Ефективний спосіб для виявлення проблем проектування системи.

Прототипи вимог. Прототип вимог до ПЗ – це часткова реалізація системи, створена для того, щоб допомогти розробникам, користувачам і клієнтам точніше визначити вимоги до системи. Цей метод також допомагає розв’язати проблему «так, але…».

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

Дата добавления: 2014-01-04