Литература:

1. Леффингуэлл

2. Вигерс

3. Энди Кармайкл

4. Квартрани

5. Крег Ларман

6. IEEE Std 830-1998

7. 1074-1997

Лекція 1. Інженерія вимог

1. Інженерія вимог

2. Визначення поняття вимоги

3. Види вимог

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

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

6. Управління вимогами

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

Причини провалів проектів

• Неповнота вимог

• Недостатнє залучення користувачі

• Брак ресурсів

• Нереалістичні очікування

• Брак підтримки керівництва

• Зміна вимог/специфікацій

• Недостатнє планування

• Втрата необхідності

Перераховані проблеми можна розділити на три основні категорії

• Вимоги погано організовані, погано написані: слабо пов’язані з запитами та потребами зацікавлених осіб, дуже швидко змінюються, або змінюються без необхідності, нереалістичні очікування

• Проблеми,Є пов’язані з браком ресурсів – брак коштів, часу, недостатня підтримка

• Мистецтво управління – виявляється у впливі на перші у впливі на перші дві категорії

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

IEEE Standard Clossary of Software Engineering Terminology визначає вимоги як

1. Умови або можливості, необхідності користувачу для вирішення проблем або досягнення цілей

2. Умови або можливості, якими повинна володіти система або системні компоненті, щоб виконати контракт або задовольняти стандартам, специфікаціям або іншим формальним документам

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

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

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

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

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

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

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

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

Види вимог

1. Бізнес-вимоги

2. Вимоги користувачів

3. Функціональні вимоги

4. Системні вимоги

5. Нефункціональні вимоги

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

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

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

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

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

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

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

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

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

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

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

Джерела вимог

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

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

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

• Представлення і очікування споживачів і користувачі системи

• Журнали використання існуючих програмно-апаратних систем

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

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

• Інтерв’ю, опитування, анкетування

• Мозковий штурм

• Спостереження за виробничою діяльністю, фотографування робочого дня

• Аналіз нормативної документації

• Аналіз конкурентних продуктів

• Аналіз статистики використання попередніх версій системи

До зацікавлених осіб в проекті відносяться:

• Замовники, що фінансують або набувають продукт

• Користувачі, які взаємодіють у напряму або не напраму з додатком

• Аналітики вимог, які пишуть вимоги і передають їх розробникам

• Розробники, які створюють, розгортають і підтримують продукт

• Тестери, які визначають відповідність поведінки ПЗ бажаній

• Технічні описувачі, які відповідають за створення керівництва користувачів

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

Управління вимогами - комплекс заходів, націлених на підтримку життєздатності специфікації вимог

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

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

• Повнота. Кожна вимога потрібно повно описувати функціональних, яку слід реалізовувати в продукті.

• Коректність. Кожна вимога повинна описувати бажану функціональність

• Здійснимість. Необхідно можливість реалізувати кожну вимогу при відомих умовах.

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

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

• Недвозначність.

• Перевіряємість.

25.01.2012 Лекція 2: Процеси вимог

• Огляд стандартних процесів ЖЦ ПЗ

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

• Загальний зміст декларації ідей та потреб замовника

Основні групи процесів вимог

• Вивчення концепції

• Призначення системи

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

• Вимоги

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

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

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

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

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

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

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

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

Вхідні дані:

• Зовнішні

  • Вимоги замовника

  • Ідеї від розробника

  • Маркетингові джерела інформації

  • Вимоги користувача

  • Змінені вимоги ПЗ

• Підтримка

  • Проблем вдосконалення представленої інформації

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

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

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

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

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

• Інші процеси вивчення концепції

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

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

Вхідна інформація

Зовнішня:

• Бюджет та ресурси розробки

• Наявні ринкові дані

• Відомості про ресурси

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

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

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

• Обмеження та переваги

• Потенційні підходи

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

• Інші процеси вивчення концепції

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

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

Вихідні дані

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

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

• Обмеження та переваги

• Потенційні підходи

Вихідні дані

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

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

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

• Інші процеси вивчення концепції

• Призначення системи

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

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

Вхідні дані:

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

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

• Обмеження та переваги

• Потенційні підходи

• рекомендації

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

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

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

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

• Створення

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

• Призначення системи

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