Міністерство освіти і науки України Черкаський державний технологічний університет Кафедра програмного забезпечення автоматизованих систем
ЗВІТ з курсу «Аналіз вимог до програмного забезпечення» з лабораторної роботи № 5 «Сумісна робота з документом»
Черкаси 2013
|
Зміст
1 Поняття вимог до ПЗ. Рівні вимог до ПЗ. 4
1.1 Вимоги до програмного забезпечення 4
2 Функціональні вимоги. 4
3 Розробка та управління вимогами до ПЗ 6
4 Характеристики якісних вимог до ПЗ. Характеристики специфікацій вимог до ПЗ 6
5 Вимоги з точки зору замовників ПЗ 6
6 Процес створення вимог до ПЗ 6
7 Роль аналітика вимог до ПЗ,. Задачі аналітика, знання та навички 6
8 Бізнес вимоги і варіанти використання. 7
9 Джерела отримання інформації про потреби користувачів ПЗ 9
9.1 Способи і джерела отримання інформації 9
9.2 Опитування потенційних користувачів і дискусії з ними 9
9.2.1. Документи, де описаний вже працюючий або конкуруючий продукт 9
9.2.2. Звіти про помилки і претензії до можливостей працюючої системи 9
9.2.3. Маркетингові дослідження та опитування користувачів 9
9.2.4. Спостереження за користувачами на робочих місцях 9
9.2.5. Сценарій аналізу задач користувачів 10
10 Варіанти використання і сценарії використання 11
10.1 Варіант використання 11
10.2 Сценарій використання 11
11 Бізнес-правила і вимоги. Документування бізнес-правил 12
11.1 Бізнес-правила і вимоги 12
11.2 Документування бізнес-правил 12
12 Користувацькі інтерфейси і специфікація вимог до 12
13 Моделювання вимог до ПЗ 15
13.1 Моделі візуального представлення 15
14 Атрибути якості ПЗ. Атрибути, важливі для користувачів. Атрибути, важливі для розробників 17
15 Прототипування як засіб зменшення ризику розробки ПЗ. Види прототипів 17
16 Пріоритети вимог до ПЗ. Шкала пріоритетів. Оцінка прототипу 17
17 Перегляд вимог до ПЗ. Проведення експертизи вимог. Тестування вимог 17
18 Вплив вимог на планування проекту, дизайн, написання коду та тестування ПЗ. Розподіл витрат на вимоги для різних моделей ЖЦ ПЗ. 17
19 Основні складові управління вимогами до ПЗ. Атрибути вимог 18
19.1 Основні складові управління вимогами до ПЗ 18
20 Стан вимог. Основні принципи контролю змін в ПЗ. Шаблон опису контролю змін 18
20.1 Стан вимог 18
20.2 Основні принципи контролю змін в ПЗ. 19
20.3 Шаблон опису контролю змін. 19
21 Елементи запиту на зміни в ПЗ 21
Всі перераховані далі вихідні критерії повинні бути задоволені, щоб належним чином завершити процес управлінь змінами: 21
22 Ролі і відповідальності учасників проекту ПЗ. Склад ради по управлінню змінами в ПЗ 23
23 Трасування вимог. Переваги реалізації трасування вимог. Джерела інформації про зв’язки трасування 23
24 Інструментальні засоби управління вимогами. Огляд та переваги їх використання 24
24.1 Інструментільні засоби управління вимогами. 24
24.2 Огляд та переваги їх використання 24
1Поняття вимог до пз. Рівні вимог до пз.
1.1 Вимоги до програмного забезпечення
Вимоги до програмного забезпечення1 – це набір вимог щодо властивостей, якості та функцій, що буде розроблено, або знаходиться у розробці. Вимоги визначаються в процесі та фіксуються в специфікації вимог, та інших процесу аналізу та розробки вимог. Специфікація вимог до ПЗ використовується при розробці, тестуванні, гарантії якості продукту, управлінні проектом і пов'язаних з проектом функціях. |
Рисунок 1.1 – Взаємозв’язки типів вимог |
2Функціональні вимоги.2
Функціональні вимоги до ПЗ складаються з трьох рівнів:
бізнес-вимоги;
вимоги користувачів;
функціональні вимог.
Бізнес-вимоги містять високо рівневі цілі організації або замовників системи.
Вимоги користувачів описують цілі і завдання, які користувачам дозволить вирішити система. До відмінних способів представлення цього виду вимог відносяться варіанти використання, сценаріїв і таблиці «подія-відгук». Таким образом, в цьому документі зазначено, що клієнти зможуть робити за допомогою системи.
Функціональні вимоги визначають функціональність ПЗ, яку розробники повинні побудувати, щоб користувачі змогли виконати свої завдання в рамках бізнес-вимог. Іноді іменовані вимоги поведінки містять положення з традиційним «повинен»: «Система повинна по електронній пошті відправляти користувачеві підтвердження про замовлення». Функціональні вимоги документуються в специфікації вимог до ПЗ, де описується так повно, як необхідно очікувану поведінку системи.
Системні вимоги позначають високо рівневі вимоги до продукту, які містять багато підсистем, тобто система (IEEE, 1998с). Говорячи про систему, мають на увазі хто розумів програмне забезпечення або підсистеми ПЗ і обладнання. Люди – це частина системи, тому певні функції системи можуть поширюватися і на людей.
Не функціональні вимоги3
Інші не функціональні вимоги описують зовнішні взаємодії між системою і зовнішнім світом, а також обмеження дизайну і реалізації. Обмеження стосуються вибору можливості розробки зовнішнього вигляду і структури продукту.До не функціональних вимог відносяться такі як:
бізнес правила;
атрибути;
зовнішній інтерфейс;
обмеження.
Бізнес-правила включають корпоративні політики, урядові постанови, промислові стандарти і розрахункові алгоритми. Однак вони часто накладають обмеження, визначаючи, хто може виконувати конкретні варіанти використання.
Люди часто розмірковують про характеристики продукту. Характеристика – це набір логічно зв'язаних функціональних вимог, які забезпечують можливості користувача і задовольняють бізнес-цілі. В області комерційного ПЗ характеристика являє собою впізнану усіма зацікавленими особами групу вимог, які важливі при ухваленні рішення про покупку - елемент маркірованого списку в описі продукту. Характеристики продукту, які перераховує клієнт, не еквівалентні тим, що входять в список необхідних для вирішення завдань користувачів.
Специфікація вимог не містить деталей дизайну або реалізації (крім відомих обмежень), даних про планування проекту чи відомостей про тестування. Видаліть зазначені елементи з вимог, щоб з цього документа було абсолютно ясно, що належить побудувати команді розробників. Для проекту, як правило, створюються вимоги інших типів: документ, де описана середу розробки, обмеження бюджету, керівництво користувача або вимоги для випуску продукту і просування його в підтримувану середу. Все це ставиться до вимог до проекту.
3Розробка та управління вимогами до ПЗ
4Характеристики якісних вимог до ПЗ. Характеристики специфікацій вимог до ПЗ
5Вимоги з точки зору замовників ПЗ
6Процес створення вимог до ПЗ
7Роль аналітика вимог до ПЗ,. Задачі аналітика, знання та навички
8Бізнес вимоги і варіанти використання.
Бізнес-вимоги визначають і набір бізнес-завдань (варіантів використання), які дозволяє виконувати додаток (ширина додатка), і глибину рівня, до якого реалізується кожен варіант використання. Якщо бізнес-вимоги допомагають вам визначити, що якийсь варіант використання виходить за межі проекту,означає, що ви приймаєте рішення про ширину проекту.
Глибина простирається від простої реалізації до повної автоматизації з великою кількістю допоміжних засобів. Бізнес-вимоги дозволяють зрозуміти, для яких варіантів використання необхідна надійна і повна функціональність, а для яких достатньо поверхневої реалізації, принаймні на перший час. Бізнес-вимоги впливають на пріоритети реалізації варіантів використання та пов'язані з ними функціональні вимоги. Наприклад, така бізнес-мета, як отримання максимального доходу, передбачає реалізацію на ранній стадії функцій, відповідальних за продаж більшої кількості продуктів або тих що надають послуги покупцям.
Екзотичні, ефектні функції,залучають лише небагатьох, жадібних до технологічних новинок клієнтів і не сприяють виконанню основної бізнес-завдання, неповинні отримувати високий пріоритет. Бізнес-вимоги також істотно впливають на спосіб реалізації вимог. Наприклад, одна з причин створення хімічного спостереження Система зменшити закупівлю нових бутлів з хімікатами, використовуються ті хімікати, які вже є на складі або в інший лабораторії. Опитування та спостереження повинні допомогти з'ясувати, чому в даний момент це не робиться.
У свою чергу, на основі цієї інформації створюються функціональні вимоги та елементи дизайну, які полегшують відстеження хімікатів в кожній лабораторії і допомагають співробітникові, запитувачу хімікат, відшукувати що можливе.
Варіант використання (use case) - це окреме, незалежна дія, де дійова особа може виконати для отримання певного значущого результату. Один з варіантів використання може охоплювати кілька схожих завдань з однаковими цілями,де він являє собою набір пов'язаних між собою сценаріїв використання, де сценарій - це окремий приклад варіанта використання. Ви можете почати розробку вимог з абстрактні варіантів використання, а потім на їх основі створити конкретні сценарії використання або, навпаки, перейти від якогось сценарію до більш широкого варіанту використання. Далі в цій розділі показаний детальний шаблон для документування варіантів використання.
До важливих елементів опису варіанта вживання відносяться:
унікальний ідентифікатор;
ім'я, коротко описує завдання користувачі у форматі «дієслово + об'єкт», наприклад« розмістити замовлення »;
короткий текстовий опис на природній мові;
список попередніх умов, які повинні бути задоволені до початку розробки варіанту використання;
вихідні умови, що описують стан системи після успішного завершення розробки варіанту використання.
Один сценарій вважається нормальним напрямком розвитку (normal course) варіанту використання, його також називають основним напрямком, базовим напрямком, нормальним потоком, основним сценарієм, головним успішним сценарієм. Нормальне напрямок для варіанту використання «Запит хімікату» - запит хімікату, який є на складі.
UML-діаграма, що ілюструє діалоговий потік при нормальному та альтернативному розвитку варіанту використання
Інші допустимі сценарії варіанту використання,називаються альтернативними напрямками (alternative courses) або Вторинними сценаріями (secondary scenarios) (Schneider і Winters, 1998). Вони також можуть призвести до успішного виконання завдання з вихідним умовам варіанту використання. Однак вони представляють варіації рішення задачі або діалогової послідовності, необхідної для виконання завдання. Певною точкою сприйняття рішень в діалогової послідовності нормальне напрямок може перейти в альтернативне, а потім повернутися обратно в нормальне.
4