МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

Національний авіаційний університет

Інститут комп’ютерних інформаційних технологій

Кафедра інженерії програмного забезпечення

Лабораторна робота 2.2

З Дисципліни:

«Аналіз вимог до програмного забезпечення»

На тему:

«Специфікація функціональних вимог до програмного забезпечення»

Виконав:

студент групи ПІ-215

Машталяр Б.В.

Перевірив:

Викл. Скалова В.А.

Київ-2015

Система управління безпекою банку

Мета – Дослідити процес створення специфікації функціональних вимог до програмного забезпечення та набути практичних навичок у виділенні та документуванні вимог.

Завдання:

1. Ознайомитися з особливостями створення специфікації вимог до програмного забезпечення.

2. Ознайомитися із базовим змістом стандарту IEEE 830.

3. Дослідити предметну галузь, задану згідно з варіантом (дод. 2) та виділити функціональні вимоги до програмного забезпечення.

4. Створити специфікацію функціональних вимог до програмного забезпечення на основі шаблон, що рекомендований стандартом IEEE 830.

1.Введення.

1.1. Призначення.

Система управління безпекою банку призначена для покращення безпеки банку, отже вона повинна забезпечувати надійність, якість та швидкодію при наданні користувачам персональної інформації по кредитам, депозитам також вона повинна підвищити ефективність інших операцій, система призначена підвищити безпеку роботи з терміналами, надаючи користувачам відповідні карти та рекомендації до них. Номер випуску продукту:1.0.

1.2. Угоди прийняті в документах.

За основу розробки документації взято стандарти групи IEEE, так розроблено специфікацію вимог за допомогою стандарту IEEE 830 в якому містяться рекомендації до структури і методам опису програмних вимог. Але особливістю виділення тексту є те, що всі заголовки повинні бути значущими та виділятися жирним шрифтом. Також для нумерації рисунків та правил оформлення додатків використовується стандарт ДСТУ3008-95.

1.3. Передбачувана аудиторія і рекомендації з читання.

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

• Підрозділ 1. Вступна частина (в якій описуються принципи використання даної специфікації, її структура, призначення, границі проекту, посилання та угоди, що прийняті в документах).

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

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

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

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

• Додатки. Додаток В містить словник термінів, необхідні для розуміння специфікації. Додаток А містить моделі аналізу (тобто графічне зображення діаграм потоків даних, IDEF0, IDEF3 і інше).

Рекомендації до послідовності читання різними групами користувачів специфікації:

Розробникам рекомендується починати переглядати специфікацію з пункту 1.1 (призначення), 1.3(рекомендації з читання) після чого перейти до пункту 1.4 (границі проекту) та далі продовжуючи перегляд всього розділу 2, крім пункту 2.6(документація для користувачів) та в випадку, якщо компанія не має досвіду з розробки подібних продуктів, то можна упустити перегляд пункту 2.1 (загального погляду на продукт). Після переглянутих пунктів необхідно прочитати повністю розділи 3, 4, 5, додаток А, та за необхідності додаток В.

Тестувальникам рекомендується починати переглядати специфікацію з пункту 1.3(рекомендації з читання), а потім перейти до пункту 2.1(загальний погляд на продукт), щоб виявити помилки, що були в попередніх версіях продукту, або в схожих версіях. Рекомендується також переглянути пункти 2.4 (операційне середовище), 2.5 (обмеження), 2.7(залежності), 4.2 - 4.4 (апаратні, програмні інтерфейси та передачі інформації). Обов’язковим є перегляд розділу 3, 5 та додатку А.

Менеджерам проекту рекомендується проглянути розділ 1 виключаючи пункт 1.2(угоди, що прийняті в документах), повністю розділ 2 та вибірково на розсуд пункти з розділів 3, 4 та 5.

Технічним описувачам рекомендується почати перегляд з пунктів 1.2 (угоди прийняті в документах), 1.3(рекомендації з читання), 1.5(посилання), 2.3 (класи користувачів), 2.6 (документація для користувачів), повністю 3,4 та 5 розділи та додаток В та А.

Персоналу по обслуговуванні та підтримці продукту необхідно починати розгляд з пунктів 1.3, 1.4 (границі проекту), після чого розглянути пункти 2.2 (особливості продукту), 2.3 (класи користувачів) та 2.7 (залежності продукту), потім для кращого розуміння функціональності переглянути розділ 3, та розділ 4 виключаючи пункт 4.1 (інтерфейси). Вибірково переглянути розділ 5 та додаток В.