Анкетування. Спостереження

Методи збору та виявлення вимог

13. Інтерв’ю замовника та експертів прикладного домену.

Анкетування. Спостереження

15. Вивчення документів та аналогічних систем.

16. Нарада. «Мозковий штурм».

17. Прототипування. Класифікація прототипів

18. Створення прототипів з використанням програмних засобів.

19. Розкадровка. Основні види.

20. Поняття аналізу. Загальні методи та засоби аналізу.

21. Засоби уніфікованої мови моделювання UML для аналізу вимог

22. Діаграми варіантів використання

23. Метод системного аналізу

24. Діаграми бізнес-процесів та потоків даних

25. Методологія SADT.

1. Поняття вимог до автоматизованої системи та програмного забезпечення

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

Вимоги до ПЗ – сукупність тверджень відносно атрибутів, властивостей або якостей програмної системи, що підлягають реалізаціях. Створюються в процесі розробки вимог до програмного забезпечення, в результаті аналізу вимог.

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

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

Фази розробки вимог

1) Виявлення вимог(збір, розуміння, розгляд і з’ясування потреб зацікавлених осіб)

2) Аналіз(встановлення пріоритетності, перевірка закінченості

3) Специфікація(документування вимог)

4) Перевірка вимог

Параметри якості вимог:

ü Повнота(кожна вимога має повністю описувати та має бути зрозуміла розробнику.)

ü Конкретність (опис функціональності, зв’язок з джерелами вимог)

ü Здійснюваність (можливість реалізувати всі функції)

ü Необхідність (можливість, що необхідна користувачу)

ü Призначення пріоритетів.

ü Однозначність

ü Перевіреність(може бути перевірена)

2. Основні види вимог

Бізнес-вимоги – містять високо рівневі цілі організація або хамовників системи. Як правило їх висловлюють ті, хто фінансує проект, покупці системи, відділ маркетингу.

В цьому документі пояснюється, навіщо організації потрібна така система, тобто описані цілі, які організація збирається досягти з її допомогою

Вимоги користувачі – визначають набір задач користувачі, які повинна вирішувати програма, а також способи їх рішення в системі

Вимоги користувачів описують цілі і задачі, які користувача дозволить виршити система.

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

До способів представлення цього виду вимог відносяться варіанти використання, сценарії.

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

Системні вимоги – це опис приблизних характеристик, яким повинен відповідати комп’ютер для того, що на ньому могло використовуватись будь-яке визначене програмне забезпечення.

Ці характеристики можуть описувати вимоги як до апаратного забезпечення, та і до програмного оточення. Зазвичай такі вимоги складаються виробником або автором ПЗ.

Нефункціональні вимоги, в них описані цілі і атрибути якості

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

3. Роль вимог у забезпеченні успішності проектів програмного забезпечення

Причини провалів проектів: 13, 1% неповнота вимог; 12, 4 % недостатнє залучення користувачів; 10, 6% недостатність ресурсів; 9, 9% не реалістичність очікувань, 9, 3% недостатня підтримка керівництва; 8, 7% недостатні вимоги/специфікації; 8, 1% недостає планування; 7, 5% втрата необхідності.

Перераховані проблеми можна поділити на: 1) вимоги, що погано організовані та написані, слабко пов’язані з потребами зацікавлених сторін. Можуть швидко змінюватись або змінюватись без необхідності. 2) Проблеми, пов’язані з недостатністю ресурсів, грошей, підтримки або повний провал проекту. 3) Мистецтво планування. Впливає 2 категорії.

Проблеми з зацікавленою стороною

Стів МакКоннел, в своїй книжці Швидка розробка, деталізує способи, якими користувачі можуть перешкоджати збору вимог:

· Користувачі не розуміють чого їм треба, чи не мають чіткого уявлення про свої вимоги

· Користувачі не вкладуть нічого в набір письмових вимог

· Користувачі наполягають на нових вимогах після фіксації ціни та графіку розробки

· Спілкування з користувачами відбувається повільно

· Користувачі вчасно не беруть участі у оглядах чи не мають змоги брати участь

· Користувачі неграмотні технічно

· Користувачі не розуміють процес розробки

· Користувачі не знають про сучасні технології

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

Проблеми з інженерами/розробниками

Можливі проблеми які можуть спричинити розробники та інженери протягом аналізу вимог:

· Технічний персонал та кінцеві користувачі можуть говорити різними мовами. Вони можуть помилково вірити в те, що вони перебувають в ідеальній згоді, поки не буде наданий закінчений продукт.

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

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

Можливі рішення

Технології представлені як прототипування, UML, прецеденти, та Гнучка розробка програмного забезпечення також вважаються рішеннями проблем пов'язаних з попередніми методами. Також, на ринок вийшов новий клас інструментів симуляції застосунків чи інструментів опису застосунків. Ці інструменти створені як міст через комунікаційний розрив між користувачами та IT - фірмами, і дозволяють застосункам бути " випробуваними ринком" перед тим як з'явиться перший код. Найкращі з цих інструментів надають:

· електронні дошки для малювання ескізів процесів застосунку та тестових альтернатив

· здатність фіксувати бізнес логіку та потреби даних

· здатність додавати контекстуальні вимоги та інші коментарі

· здатність для віддалених та розподілених користувачів запускати та взаємодіяти з симуляцією

4. Джерела та користувачі вимог

· Законодавство, стандарти(конституція, закони розпорядження.)

· Нормативне забезпечення організації (регламент, положення, накази)

· Текуча організація діяльності об’єкта автоматизації.

· Моделі діяльності (діаграми бізнес-процесів).

· Представлення очікуваних потреб і користувачів системи.

· Журнали користування суттєвих апаратно - програмних систем.

· Конкуруючі програмні продукти.

5. Процеси вивчення концепції – ідентифікація ідей та потреб замовника, оформлення ідей та потреб

Концепція (концепт – розуміння, система) – визначений спосіб розуміння будь-якого предмету, явища або процесу; основна точка зору на предмет.

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

Процеси вивчення концепції:

· вивчення ідей та потреб;

· формулювання потенційних підходів;

· проведення вивчення здійсненності;

· уточнення та оформлення ідей та потреб.

Визначення ідей та потреб:

Вхідні дані:

· зовнішні:

o вимоги замовника;

o ідеї від розробника;

o маркетингові джерела ін-ії;

o вимоги користувача;

o змінені вимоги ПЗ.

Пітримка:

· проблем вдосконалення представлення ін-ії;

· рекомендації по використанню.

Вихідні дані:

· первинне формулювання потреб.

Призначення:

· планування проекту;

· інші процеси вивч. концепції.

Ідеї і потреби для нових та модифікованих сист. формуються із 1-го або декількох джерел. Вхідна ін-ії повинна бути задокументована з викладенням функц. потреб та продуктивності. Зміни вимог ПЗ можуть поступати із законодавства, нормативних актів, нац. та міжнародних стандартів, керівництв і т.д.

Уточнення та оформлення ідей та потреб:

Вхідні дані:

· вивчення концепції:

o первинне формулювання потреб;

o обмеження та переваги;

o потенційні підходи;

o рекомендації.

Вихідні дані:

· формулювання (затвердження) потреб.

Призначення:

· планування проекту;

· створення;

· моніторинг та контроль проекту;

· призначення системи.

Визначає цілі ПЗ, потреби, бажання замовника; рекомендовані підходи для їх реалізації і будь-які дані, що є доречними (використовуються) для прийняття управлінських рішень, що стосуються ініціювання описаних робіт.

6. Процеси вивчення концепції – формулювання потенційних підходів, вивчення здійсненності

Концепція (концепт – розуміння, система) – визначений спосіб розуміння будь-якого предмету, явища або процесу; основна точка зору на предмет.

Формулювання потенційних підходів:

Вхідні дані:

· зовнішні:

o бюджет та ресурси розробки;

o наявні ринкові дані;

o відомості про ресурси.

· вивчення концепції:

o первинне формулювання потреб.

Вихідні дані: - обмеження та переваги; - потенційні підходи.

Призначення: - інші процеси вивч. концепції.

Використовуючи інф. джерела, бюджетні дані, існуючі повторно використовувані продукти ПЗ, потенційні підходи мають бути розроблені базуючись на первинному формулювання потреб і на будь-яких даних, які є доречними при прийнятті рішень про розробку при придбання системи.

Проведення вивчення здійсненності:

Вхідні дані:

· вивч.концепції:

o первинне формулювання потреб;

o обмеження та переваги;

o потенційні підходи.

Вихідні дані:

· рекомендації.

Призначення: - планування проекту; - інші проц. вивч. концепції; - призначення системи.

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

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

Група

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

Процеси призначення системи:

· Аналіз функцій

· Розробка системної архітектури

· Декомпозиція системних вимог

Аналіз функцій

Вхідні дані: від процесу «Визначення концепції»:

· Рекомендації

· Формулювання (затвердження) потреб

Вихідні дані: Функціональний опис системи

Призначення:

· Інші процеси призначення системи (розробка системної архітектури, декомпозиція системних вимог)

· Вимоги

Розробка системної архітектури

Системна архітектура – фундаментальна організація системи, реалізована в її компонентах, зв’язках цих компонентів один з одним і зовнішнім середовищем і принципах, що визначають структуру і розвиток системи.

Вхідні дані: - Сформульовані (затверджені) вимоги (визначення концепції) -Функціональний опис системи (аналіз функцій)

Вихідні дані: Системна архітектура

Призначення:

· Інші процеси призначення системи

· Проекти

Декомпозиція системних вимог

Вхідні дані:

· Функціональний опис системи (призначення системи)

· Системна архітектура (призначення системи)

Вихідні дані: Функціональні вимоги до ПЗ

Призначення:

· Створення проекту (початок проектування)

· Вимоги

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

Оцінка джерел імпорту ПЗ

Визначення методу імпорту ПЗ

Імпорт ПЗ

Визначення вимог до ПЗ, що імпортується

Вхідні дані:

Вимоги до ПЗ

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

Додаткова інформація з цим процесом в стандарті IEE Std 1062, 1998.

Вихідні дані:

Вимоги до ПЗ, що імпортується

Призначення:

Планування проекту

Моніторінг та контроль проекту

Імпортування ПЗ

Оцінка джерел імпорту ПЗ

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

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

Вихідні дані: Виділені джерела імпорту ПЗ

Призначення: - Етап імпортування ПЗ - Моніторінг та контроль проекту

Визначення методі імпорту ПЗ

Вхідні дані: Виділені джерела ПЗ, що імпортується

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

(Інтеграція імпортованого ПЗ з загальним графіком проекту, вимоги тестування імпортованого ПЗ, вимоги бюджету і персоналу).

Вихідні дані: Виділені методи імпорту ПЗ

Імпорт ПЗ

Вхідні дані: - Виділені джерела імпорту ПЗ - Виділені методи імпорту ПЗ

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

9. Процеси встановлення вимог – визначення та розробка вимог до програмного забезпечення, визначення вимог до інтерфейсу