Встановлення пріоритетів та інтеграція вимог до пз

Вхідні дані:

• Опис інформації стосовно ризиків

• Попередні (первинні) вимоги до ПЗ

• Вимоги до інтерфейсу ПЗ

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

• Вимоги до ПЗ

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

• Початок проекту

• Управління і моніторинг проекту

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

• Реалізація

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

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

Загальний зміст документу «Специфікація вимог до пз»

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

В стандарті IEEE 830 містяться рекомендації до структури і методів опису вимог до ПЗ.

Специфікація вимог до пз

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

SRS можуть бути складені одним або декількома представниками постачальника, одним або декількома представниками клієнта, або обома.

Специфікація вимог до ПЗ – документ, що представляє собою рекомендовану методику складання специфікації вимог до ПЗ. (Она сама не поняла что сказала)

Специфікація вимог до пз (srs)

Основні питання, що розглядаються SRS

• Функціональні можливості системи

• Користувальницькі, програмні інтерфейси: алгоритми взаємодії системи користувачам різних груп, з апаратним забезпечення, з іншими апаратними та програмними засобами.

• Робочі характеристики системи: швидкодія, доступність та інше

• Атрибути системи: зручність для користувачів різних груп, захищеність системи%

• Можливі проектні обмеження, що накладаються на систему: вимоги до ОС, до форматів даних, до СУБД.

Переваги використання SRS:

• Для замовника – точний опис того, що він хоче отримати;

• Для розробника – однозначне тлумачення і розуміння того, що хоче отримати замовник.

Характеристика правильно складеної SRS :

• Коректність

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

• Повнота

• Несуперечливість

• Упорядкованість за значністю

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

• Модифікуємість

• Відслідковуваність

14.02.2012 Лекція 5 Методи збору та виявлення вимог Методи встановлення та виявлення вимог

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

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

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

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

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

2. Анкетування

3. Спостереження

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

5. Нарада

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

7. Прототипування

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

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

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

Існують два основних типи інтерв’ю: структуроване (формальне) і неструктуроване (неформальне).

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

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

Наперед сформульовані питання можна розділити на дві категорії:

• Питання з відкритою множиною відповідей (відповіді на цю категорію питань заздалегідь не готуються);

• Питання з замкнутою множиною відповідей (відповіді на цю категорію питань можна вибрати зі списку підготовлених відповідей)

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

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

1. Небезпристрасні питання, в яких інтерв’єер виражає свою думку з питання.

2. Упередежені питання

3. ….

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

Частина 1: Визначення профілю замовника. Визначаємо ім’я, галузь в якій він працює, що він виробляє, для кого він виробляє, як вимірюється успіх діяльності компанії, які проблеми впливають на успішність діяльності компанії.

Частина 2: Оцінка проблеми. Чому існує така проблема, як вона вирішується в даний час і як замовник хотів би її вирішити.

Частина 3: Розуміння середовища користувача. Хто такі користувачі, яка в них освіта, які в них навики в комп’ютерній області, чи мають вони досвід роботи з даним типом застосувань (додатків), яка платформа використовується, які замовник хоче використовувати платформи в майбутньому.

Частина 4: Резюме. Повторити за замовником те, що він говорив, щоб він зрозумів, чи правильно була зрозуміла інформація дана ним.

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

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

Частина 7: Оцінка можливості розповсюдження. Хто в організації потребує дане застосування, скільки користувачів буде використовувати дане застосування.

Частина 8: Оцінка необхідного рівня надійності і продуктивності. Очікування відносно надійності, продуктивності, хто буде займатись підтримкою продукту і чи треба це, чи є вимоги по ліцензуванню, які вимоги на маркування і упаковку та інше.

Частина 9: Інші вимоги. Вимоги законодавства, інформаційного середовища, інструкція та стандарти які мають бути підтримані.

Частина 10: Закінчення. Запитують чи існують питання, на які не дали відповіді (які не були задані).

Частина 11: Висновок аналітика.