Міністерство освіти і науки України Черкаський державний технологічний університет Кафедра програмного забезпечення автоматизованих систем
ЗВІТ з курсу «Аналіз вимог до програмного забезпечення» з лабораторної роботи № 5 «Сумісна робота з документом»
Черкаси 2013
|
Зміст
1. Поняття вимог до ПЗ. Рівні вимог до ПЗ. 3
1.1. Вимоги до програмного забезпечення 3
2. Функціональні вимоги. 3
3. Розробка та управління вимогами до ПЗ 5
4. Характеристики якісних вимог до ПЗ. Характеристики специфікацій вимог до ПЗ 5
5. Вимоги з точки зору замовників ПЗ 5
6. Процес створення вимог до ПЗ 5
7. Роль аналітика вимог до ПЗ,. Задачі аналітика, знання та навички 5
8. Бізнес вимоги і варіанти використання 5
9. Джерела отримання інформації про потреби користувачів ПЗ 6
9.1. Способи і джерела отримання інформації 6
9.2. Опитування потенційних користувачів і дискусії з ними 6
9.2.1. Документи, де описаний вже працюючий або конкуруючий продукт 6
9.2.2. Звіти про помилки і претензії до можливостей працюючої системи 6
9.2.3. Маркетингові дослідження та опитування користувачів 6
9.2.4. Спостереження за користувачами на робочих місцях 6
9.2.5. Сценарій аналізу задач користувачів 7
10. Варіанти використання і сценарії використання 8
11. Бізнес-правила і вимоги. Документування бізнес-правил 9
12. Користувацькі інтерфейси і специфікація вимог до ПЗ 9
13. Моделювання вимог до ПЗ 9
14. Атрибути якості ПЗ. Атрибути, важливі для користувачів. Атрибути, важливі для розробників 9
15. Прототипування як засіб зменшення ризику розробки ПЗ. Види прототипів 9
16. Пріоритети вимог до ПЗ. Шкала пріоритетів. Оцінка прототипу 9
17. Перегляд вимог до ПЗ. Проведення експертизи вимог. Тестування вимог 9
18. Вплив вимог на планування проекту, дизайн, написання коду та тестування ПЗ. Розподіл витрат на вимоги для різних моделей ЖЦ ПЗ. 9
19. Основні складові управління вимогами до ПЗ. Атрибути вимог 9
20. Стан вимог. Основні принципи контролю змін в ПЗ. Шаблон опису контролю змін 9
21. Елементи запиту на зміни в ПЗ 9
22. Ролі і відповідальності учасників проекту ПЗ. Склад ради по управлінню змінами в ПЗ 9
23. Трасування вимог. Переваги реалізації трасування вимог. Джерела інформації про зв’язки трасування 9
24. Інструментальні засоби управління вимогами. Огляд та переваги їх використання 9
25. Взаємовідносини вимог та інших процесів проекту ПЗ. Взаємодія між розробниками та іншими зацікавленими особами проекту 9
1.Поняття вимог до пз. Рівні вимог до пз.
1.1.Вимоги до програмного забезпечення
Вимоги до програмного забезпечення1i – це набір вимог щодо властивостей, якості та функцій, що буде розроблено, або знаходиться у розробці. Вимоги визначаються в процесі та фіксуються в специфікації вимог, та інших процесу аналізу та розробки вимог. Специфікація вимог до ПЗ використовується при розробці, тестуванні, гарантії якості продукту, управлінні проектом і пов'язаних з проектом функціях. |
Рисунок 1.1 – Взаємозв’язки типів вимог |
2.Функціональні вимоги.2ii
Функціональні вимоги до ПЗ складаються з трьох рівнів:
бізнес-вимоги;
вимоги користувачів;
функціональні вимог.
Бізнес-вимоги містять високо рівневі цілі організації або замовників системи.
Вимоги користувачів описують цілі і завдання, які користувачам дозволить вирішити система. До відмінних способів представлення цього виду вимог відносяться варіанти використання, сценаріїв і таблиці «подія-відгук». Таким образом, в цьому документі зазначено, що клієнти зможуть робити за допомогою системи.
Функціональні вимоги визначають функціональність ПЗ, яку розробники повинні побудувати, щоб користувачі змогли виконати свої завдання в рамках бізнес-вимог. Іноді іменовані вимоги поведінки містять положення з традиційним «повинен»: «Система повинна по електронній пошті відправляти користувачеві підтвердження про замовлення». Функціональні вимоги документуються в специфікації вимог до ПЗ, де описується так повно, як необхідно очікувану поведінку системи.
Системні вимоги позначають високо рівневі вимоги до продукту, які містять багато підсистем, тобто система (IEEE, 1998с). Говорячи про систему, мають на увазі хто розумів програмне забезпечення або підсистеми ПЗ і обладнання. Люди – це частина системи, тому певні функції системи можуть поширюватися і на людей.
Не функціональні вимоги3iii
Інші не функціональні вимоги описують зовнішні взаємодії між системою і зовнішнім світом, а також обмеження дизайну і реалізації. Обмеження стосуються вибору можливості розробки зовнішнього вигляду і структури продукту.До не функціональних вимог відносяться такі як:
бізнес правила;
атрибути;
зовнішній інтерфейс;
обмеження.
Бізнес-правила включають корпоративні політики, урядові постанови, промислові стандарти і розрахункові алгоритми. Однак вони часто накладають обмеження, визначаючи, хто може виконувати конкретні варіанти використання.
Люди часто розмірковують про характеристики продукту. Характеристика – це набір логічно зв'язаних функціональних вимог, які забезпечують можливості користувача і задовольняють бізнес-цілі. В області комерційного ПЗ характеристика являє собою впізнану усіма зацікавленими особами групу вимог, які важливі при ухваленні рішення про покупку - елемент маркірованого списку в описі продукту. Характеристики продукту, які перераховує клієнт, не еквівалентні тим, що входять в список необхідних для вирішення завдань користувачів.
Специфікація вимог не містить деталей дизайну або реалізації (крім відомих обмежень), даних про планування проекту чи відомостей про тестування. Видаліть зазначені елементи з вимог, щоб з цього документа було абсолютно ясно, що належить побудувати команді розробників. Для проекту, як правило, створюються вимоги інших типів: документ, де описана середу розробки, обмеження бюджету, керівництво користувача або вимоги для випуску продукту і просування його в підтримувану середу. Все це ставиться до вимог до проекту.
3.Розробка та управління вимогами до ПЗ
4.Характеристики якісних вимог до ПЗ. Характеристики специфікацій вимог до ПЗ
5.Вимоги з точки зору замовників ПЗ
6.Процес створення вимог до ПЗ
7.Роль аналітика вимог до ПЗ,. Задачі аналітика, знання та навички
8.Бізнес вимоги і варіанти використання
9.Джерела отримання інформації про потреби користувачів ПЗ
9.1.Способи і джерела отримання інформації
Необхідно вислуховувати різні точки зору і вибирати різні джерела інформації, а це зайвий раз підтверджує, що робота по збору вимог тісно пов'язана зі спілкуванням.
Ось кілька типових джерел отримання інформації при зборі вимог до ПЗ:
Опитування потенційних користувачів і дискусії з ними.
Документи, де описаний вже працюючий або конкуруючий продукт.
Звіти про помилки і претензії до можливостей працюючої системи.
Маркетингові дослідження та опитування користувачів.
Спостереження за користувачами на робочих місцях.
Сценарій аналізу задач користувачів.