Коротко про user stories, Нефункціональні вимоги, Non-functional requirements

« Назад

На початку роботи над проектом proxy product owner на підставі зібраних функціональних вимог на стороні замовника складає документ product backlog, до складу якого входять пріоритезовані історії користувача (user story).

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

Відомі наступні практики (методи) збору користувацьких історій:

- Проведення інтерв'ю цільових користувачів (User interviews).

- Анкетування (Questionnaires).

- Спостереження (Observation).

- Семінари зі складання історій (Story-Writing workshops).

Більшість з цих методів входять до інструментарію традиційної бізнес-аналітики.

Розглянемо ці методи.

User interviews. Інтерв'ювання використовують багато команд для отримання користувальницьких історій. Одним з ключів до успіху опитування є вибір опитуваних. Краще проводити інтерв'ю з реальними користувачами, ніж з можливими. Також слід опитувати користувачів, що представляють різні групи ролей.

Дуже важливо задавати «правильні» запитання – це кращий спосіб збору історій. Не слід ставити закриті запитання, на які можливо дати відповідь «Так» або «Ні». До спеціальних питань також слід вдаватися тільки за необхідності. Краще використовувати відкриті та безконтекстні питання, що дозволить отримати більш широкий діапазон відповідей, а отже зібрати більше історій.

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

Observation. Спостереження за роботою користувачів з продуктом може дати безліч ідей, як його покращити, зібрати багато історій. Але, на жаль, не для всіх проектів можливе застосування даної техніки. Тому, якщо з'явився шанс поспостерігати за користувачем – дуже важливо його не змарнувати (наприклад, під час Sprint Review Meeting). Ця практика, що дозволяє швидко і прямо отримувати відгук від користувачів, є однією з багатьох причин раннього і частого випуску програмного забезпечення.

Story-Writing workshops. Семінари зі складання історій проводяться за участю розробників, користувачів, замовника продукту та інших учасників, які можуть внести вклад до написання історій. Протягом цього семінару учасники складають так багато історій, як тільки можуть, не роблячи акцент на пріоритезації, так як це зможе потім зробити власник продукту. Ця техніка є однією з найефективніших для збору історій.

Також дуже важливою практикою є прототипування.

Прототипування програмного забезпечення – процес створення прототипу (макету, mockup) програми, зазвичай, з метою перевірки придатності пропонованих для застосування концепцій, для представлення програми замовнику на початкових стадіях процесу розробки.

Прототип дозволяє також отримати зворотній зв'язок від майбутніх користувачів, причому, саме тоді, коли це найбільш необхідно: на початку проекту ще є можливість виправити помилки проектування практично без втрат.

Переваги застосування прототипування:

- зменшення часу, вартості, ризиків: прототипирование покращує якість специфікацій;

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

Недоліки:

- недостатній аналіз: концентрація зусиль на обмеженому прототипі може відволікати розробників від належного аналізу вимог на повну систему.

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

- створення дуже складних прототипів може привести до втрати основного властивості прототипування - швидкості створення.

Розробка специфікацій вимог для веб-додатку «СППР NooTron» проводилася за допомогою інтерв’ювання та прототипування. Був складений Product Backlog, який пріоритезував Product owner та оцінила складність кожної з історій Scrum-команда. Отриманий документ представлений у додатку Б.

Нефункціональні вимоги (Non-functional requirements)

Також на початку проекту збираються нефункціональні вимоги (Non-functional requirements) – вимоги до характеру поведінки системи:

- бізнес-правила – визначають обмеження, що виникають з предметної області та властивостей автоматизується об'єкта (підприємства);

- системні вимоги й обмеження – визначення елементарних операцій, які повинна мати система, а також різні умови, яким вона може задовольняти;

- атрибути якості;

- зовнішні системи та інтерфейси;

- обмеження.

Приклад нефункціональних вимог (для веб-додатку «СППР NooTron») представлені у додатку.

Додаток Non-functional Requirements

Name	Requirements
NF-1: Portability constraints for NooTron	Web-application must work with such browsers: IE > 8, Mozila Firefox > 6, Google Chrome > 6, Opera > 10
NF-2: Performance constraints for NooTron	All MCDA methods, except Integrated methods and ANP, must be performed up to 3 seconds. ANP - up to 15 seconds (it depends on the size of the supermatrix). Integrated methods must be performed up to 5 seconds. Meantime for response to button click must be up to 5 seconds. Page load time must be up to 5 seconds. The application must work correctly with the number of simultaneous users not less than 50 people.
NF-3: Robustness constraints for NooTron	All exceptions must be followed by error pages. For example, Page is temporarily unavailable Sorry, this page is temporarily unavailable. Please, contact your administrator. There must not be memory leaks.
NF-4: Availability constraints for NooTron	The application must be available during study hours.
NF-5: Environmental constraints for NooTron	CPU must be no less than Pentium 5, RAM must be no less than 4 GB, OS - all available, HDD 200 GB
NF-6: Open source constraints for NooTron	Only open source software and freeware must be used. For example, Apach - Apache 2.0, lgpl.
NF-7: Sequrity constraints for NooTron	Multi-system access. Registration and authorization.
NF-8: Usability constraints for NooTron	User’s experience level (confident user). Aesthetics (brightness - moderate).
NF-9: Supportability constraints for NooTron	The first Release of application must be ready up to the 7th of May. Application will be improved next year by the next group of students, so why software must be delivered with source code and artifacts describing it.
NF-10: Localizability constraints for NooTron	Application must be localized by such languages: ru, eng, ua. The default application language is Russian. The application starts with this language.
NF-11: Reliability constraints for NooTron	There must be provided the procedure for logging and tracking defects. Meantime to repair must be no more than 5 hours.

З повагою ІЦ "KURSOVIKS"!