ОснАлгор_Посібн_Яровенко

2.4. СПЕЦИФІКАЦІЇ ВИМОГ.

Для детального опису і документування вимог використовуються

специфікації.

Означення. Специфікація – це формалізований опис властивостей, характеристик і функцій об'єктів.

Означення. Специфікація вимог до програмного забезпечення (Software Requirements Specification, SRS) – це закінчений опис поведінки ПП, який потрібно розробити.

Специфікація вимог до програмного забезпечення включає ряд сценаріїв використання (use cases), які описують всі варіанти взаємодії між користувачами і ПП. Методика сценаріїв використання застосовується для виявлення вимог до поведінки системи, відомих також як функціональні вимоги. На додачу до сценаріїв використання SRS також включає

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

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

Стандарт IEEE Std 830-1998 містить рекомендації щодо структури і методів опису програмних вимог, зокрема, рекомендує наступну структуру

SRS.

1. ВСТУП 1.1.Мета (цілі).

1.2.Погодження термінів (означення та абревіатури). 1.3.Цільова аудиторія і послідовність сприйняття. 1.4.Масштаб проекту.

1.5.Посилання на джерела.

2.ЗАГАЛЬНИЙ ОПИС. 2.1.Перспективи продукту. 2.2.Функціональність продукту. 2.3.Класи і характеристики користувачів.

2.4.Середовище функціонування продукту (операційне середовище). 2.5.Межі, обмеження, правила та стандарти.

2.6.Документація для користувачів. 2.7.Припущення й залежності.

3.ФУНКЦІОНАЛЬНІСТЬ СИСТЕМИ.

3.1.Функціональний блок X (таких блоків може бути декілька)

3.1.1.Опис і пріоритет.

3.1.2.Причинно-наслідкові зв’язки, алгоритми (рух процесів, workflows, «вплив-реакція»).

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

4.ВИМОГИ ДО ІНТЕРФЕЙСІВ.

4.1.Інтерфейси користувача (UX). 4.2.Програмні інтерфейси. 4.3.Інтерфейси обладнання.

31

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

4.4.Інтерфейси зв’язку та комунікації.

5.НЕФУНКЦІОНАЛЬНІ ВИМОГИ. 5.1.Вимоги до продуктивності. 5.2.Вимоги до надійності. 5.3.Вимоги до доступності. 5.4.Вимоги до супроводу. 5.5.Вимоги до переносимості. 5.6.Вимоги до зберігання даних. 5.7.Вимоги к безпеки системи. 5.8.Критерії якості ПЗ.

6.ІНШІ ВИМОГИ.

7.ДОДАТОК А: Глосарій.

8.ДОДАТОК Б: Моделі процесів та предметної області, інші діаграми.

9.ДОДАТОК В: Список ключових задач.

Керуючись цими рекомендаціями, можна визначити повний набір вимог до як завгодно складних ПС чи ПП. Набір специфікацій вимог до ПЗ (SRS) також має бути якісним.

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

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

Використовуючи такий підхід, А.Девіс (А.Davis, 1999) прийшов до висновку, що для визначення повного набору вимог до ПП необхідно описати п’ять основних категорій елементів:

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

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

3.Функції системи. Опис відображень вводів у виводи та їх різні комбінації.

4.Атрибути системи. Типові неповедінкові вимоги, такі як надійність, зручність супроводу тощо, які повинні враховувати розробники.

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

Схема такої системи зображена на рис.18.

32

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Вводи	Виводи

Атрибути системного середовища

Функції

Атрибути системи

Рис. 18. Елементи системи «чорний ящик».

2.5. МЕТОДИ ВИЗНАЧЕННЯ ВИМОГ.

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

Методи визначення вимог користувача.

Інтерв’ювання та анкетування.

Наради та семінари.

«Мозковий штурм» та відбір ідей.

Аналізу та моделювання.

Створення сценаріїв використання (моделювання прецедентів).

Створення розкадровок.

Обігравання ролей.

Створення прототипів.

Очевидно, що більшість з перелічених вище методів визначення вимог при проектуванні програм в рамках лабораторного практикуму не знайде свого застосування. І справді було б дивним, якби студент (замовник і виконавець в одній особі) інтерв’ював би самого себе чи організовував «мозковий штурм».

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

Методи створення специфікацій системних вимог.

Метод псевдокоду.

Метод скінчених автоматів.

Метод дерев рішень.

Метод діаграм діяльності.

Метод моделей «сутність-зв'язок».

Метод об’єктно-орієнтованих моделей.

Метод схем потоків даних.

33

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

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

Визначення вимог до ПП є далеко нетривіальною задачею, що

підтверджується наступною схемою (рис. 19):
Визначення				Повторна оцінка
		Аналіз		Специфікація			Перевірка
					Переробка
	Прояснення

Виправлення та усунення недоліків

Рис. 19. Ітеративний процес визначення вимог.

2.6. ВЛАСТИВОСТІ ВИМОГ.

Документи, регламентуючі вимоги до ПЗ, і практичний досвід розробки ПЗ визначили властивості, якими мають володіти вимоги («вимоги до вимог»):

одиничність – одна вимога описує одну річ (функціональність, характеристику, параметр тощо);

атомарність – вимога не може бути розділена на ряд більш детальних вимог без втрати повноти;

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

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

однозначність інтерпретації – кожна вимога однаково розуміється (інтерпретується) всіма учасниками проекту (читачами вимог);

несуперечність (коректність і узгодженість) – вимоги не можуть суперечити одна одній. В ієрархії вимог можна виділити вертикальну і горизонтальну узгодженість;

пріоритетність – місце в ієрархічній системі вимог, наприклад за критерієм важливості, для визначення послідовності їх реалізації;

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

34

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

корисність при експлуатації – властивість вимог, які підвищують ергономічні якості програмного продукту і, зазвичай, формулюються розробниками;

здійсненність – вимога має бути технічно здійсненна (при відомих умовах та обмеженнях системи й операційного середовища) в задані терміни та в межах виділеного бюджету. Ця властивість на практиці визначається розумним балансом між цінністю (ступенем необхідності і корисності) та необхідними ресурсами. Далеко не всі вимоги, які в принципі можна виконати, з точки зору науки управління вимогами є здійсненними. Ілюстрацією балансування між цінністю та здійсненністю вимог є трикутник компромісів або «залізний» трикутник обмежень проекту (рис. 20). «Залізність» означає, що ні один з кутів трикутника не може бути змінене ний без впливу на інші.

Можливості

Краще

Дешевше Швидше

Вартість Термін (час)

Рис. 20. Трикутник компромісів (обмежень).

наявність кількісної метрики – властивість в першу чергу нефункціональних вимог (наприклад – запит має опрацьовуватись не більше N секунд). Кількісні метрики відіграють важливу роль у верифікації та атестації програмних систем;

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

модифікованність – можливість зміни (модифікації) вимоги;

трасувальність – можливість трасування вимоги, тобто, слідкування за розвитком вимоги від першоджерела до реалізації і навпаки;

законність – вимога не має протирічити чинному законодавству.

35

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

2.7. РЕКОМЕНДОВАНА СТРУКТУРА СПЕЦИФІКАЦІЙ ВИМОГ ДО ПРОГРАМ, СТВОРЮВАНИХ В РАМКАХ ПРАКТИКУМУ.

(для розв’язання навчальних задач).

Модифікована класифікація Девіса вимог до ПП з урахуванням рекомендацій Стандарту IEEE Std 830-1998 щодо специфікацій вимог до ПЗ

(Software Requirements Specification, SRS) та навчальних цілей лабораторного практикуму і навчального характеру програм, які розробляються в його рамках, має наступний вид.

1.ФОРМУЛЮВАННЯ МЕТИ (ЦІЛЕЙ).

1.1.Необхідно точно сформулювати призначення програми як відповідь на запитання «Що потрібно зробити (знайти, обчислити)?». Наприклад: створити програму впорядкування за зростанням заданої множини цілих чисел; створити програму для знаходження коренів квадратного рівняння. Зазвичай процес точного формулювання цілей проектування програми може зводитись до постановки ряду правильних запитань (можливо тому цей процес часто називають «постановкою задачі»).

1.2.Необхідність (причини) створення програми.

2.АТРИБУТИ ПРОГРАМИ.

2.1.Користувачі – класи (групи) користувачів програми.

2.2.Виконавці.

2.3.Сумісність з операційною системою – які операційні системи мають підтримуватись.

2.4.Система (середовище) чи мова програмування.

2.5.Вимоги до оперативної пам’яті, необхідної для програми.

2.6.Вимоги до інтерфейсу користувача – тип (віконний, графічний, «командний рядок»), структура, основні елементи.

3.ВИМОГИ ДО ВХІДНИХ ДАНИХ (Специфікація вхідних даних).

Для кожного вхідного даного визначається:

3.1.Семантика – змістове найменування (пояснення змісту даного).

3.2.Вид даного – постійне, умовно-постійне та змінне.

Постійні дані – це дані, які зберігають свої значення в процесі

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

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

Змінні дані – це дані, які змінюють свої значення в процесі розв’язування задачі.

3.3.Тип даного – просте чи структуроване.

Прості дані – це дані, які в будь-який момент часу приймають

(визначають) одне єдине значення. Для простих даних характерне відношення: одне ім’я – одне значення. Розрізняють прості дані – числові (цілі, дійсні),

символьні, логічні.

36

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

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

3.4.Розмірність (метрика) – кількісна міра даного. В 1999 році NASA втратила супутник вартістю в сотні мільйонів доларів через те, що дані, які були сприйняті в метричній системі, насправді були записані в іншій.

3.5.Діапазон допустимих значень – інтервал чи перелік допустимих значень.

3.6.Джерело даного – клавіатура, файл даних (з якого носія), вимірювальний (реєструючий) пристрій.

4.ФУНКЦІЇ ПРОГРАМИ.

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

5. ВИМОГИ ДО ВИХІДНИХ ДАНИХ (Специфікація вихідних даних).

Специфікація вихідних даних аналогічна специфікації вхідних даних – для кожного даного на виході визначається:

5.1.Семантика – змістове найменування (пояснення змісту даного).

5.2.Тип даного.

5.3.Розмірність (метрика).

5.4.Діапазон допустимих значень.

5.5.Пристрій виведення – монітор, принтер, файл (на який носій).

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

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

Примітка. Специфікацію вимог до програми зручно подавати у вигляді таблиць.

37

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

2.8. ПРИКЛАДИ ВИЗНАЧЕННЯ ТА СПЕЦИФІКАЦІЇ ВИМОГ.

ЗАДАЧА 1. Обчислити площу трикутника за довжинами його сторін. Специфікації вимог до програми.

1.Формулювання мети: спроектувати і відлагодити програму обчислення площі трикутника за заданими довжинами його сторін.

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

2.Атрибути програми:

2.1.Користувачі: без обмежень.

2.2.Виконавець: Іваненко Іван, група 1АМ-13.

2.3.Сумісність з операційною системою: ОС Windows XP і вище.

2.4.Система програмування: Turbo Pascal 7.0 (7.1)

2.5.Вимоги до оперативної пам’яті: визначаються вимогами ОС.

2.6.Вимоги до інтерфейсу користувача: інтерфейс користувача типу

«командний рядок» має містити призначення програми, інформацію про виконавця, інструкції щодо введення даних.

Примітка. Має місце суперечність вимог: система програмування Turbo Pascal 7.0 (7.1) підтримується ОС DOS 6.3-7.0 або її емулятором в середовищі ОС сімейства Windows. В цьому випадку має місце обмеження для сегменту даних (неперервної області оперативної пам’яті, в якій розміщується код програми і глобальні змінні) – 64 Кбайт. При використанні системи програмування

PascalABC чи PascalABCNET, які підтримуються ОС сімейства Windows,

обмеження для сегменту даних – 10 Мбайт.

3.

Специфікація вхідних даних.

Семантика

Вид

Тип

Розмірність

Діапазон

Джерело

даного

даного

даного

даного

значень

даного

Довжини

Постійні

Прості,

см

0,01 ..

Клавіатура

сторін

дійсні

1000

4.

Функції програми.

4.1. Введення значень довжин 3-х відрізків з клавіатури з перевіркою

належності значень визначеному діапазону.

4.2. Перевірка утворення трикутника заданими відрізками.

4.3. Обчислення площі трикутника і виведення результату в заданому форматі

на заданий пристрій.

5.

Специфікація вихідних даних.

Семантика

Вид

Тип

Розмірність

Діапазон

Пристрій

Формат

даного

даного

даного

даного

значень

виведення

виведення

Площа

Постійне

Просте,

кв. см

0 .. 45000

Монітор

ХХХ.ХХХ

дійсне

38

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

ЗАДАЧА 2. Автоматизувати облік особових справ студентів факультету. Специфікації вимог до програми.

1.Формулювання мети: спроектувати і відлагодити програму обліку особових справ студентів інституту.

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

2.Атрибути програми:

2.1.Користувачі: дирекція інституту, навчальний відділ, ректорат.

2.2.Виконавець: Петренко Петро, група 1БМ-13.

2.3.Сумісність з операційною системою: ОС Windows XP і вище.

2.4.Система програмування: PascalABCNET.

2.5.Вимоги до оперативної пам’яті: визначаються вимогами ОС.

2.6.Вимоги до інтерфейсу користувача: типу «командний рядок», має містити призначення програми, інформацію про виконавця, інструкції щодо введення даних, режими роботи – додання, пошук за ключем, видалення студента.

3.Специфікація вхідних даних.

Семантика	Вид	Тип	Розмірність	Діапазон	Джерело
даного	даного	даного	даного	значень	даного
Прізвище	Постійне	Просте,		20 симв.	Клавіатура
		символьне
Ім’я	//	//		12 симв.	//
По-батькові	//	//		15 симв.	//
Дата
народж.
Число	//	Просте,		1 .. 31	//
		ціле
Місяць	//	//		1 .. 12	//
Рік	//	//		1970 ..	//
				2000
Дом. адреса
Область	Умовно-	Просте,		20 симв.	//
	постійне	символьне
Район	//	//		30 симв.	//
Населений	//	//		20 симв.	//
пункт
Вулиця	//	//		20 симв.	//
Будинок №	//	Просте,		1 .. 300	//
		ціле
Квартира №	//	//		1 .. 2000	//
			39

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Індекс	//	//		10000 ..	//
				99999
Телефон	//	//		20000 ..	//
				99999
Гуртожиток №	//	//		1 .. 10	//
Кімната №	//	//		5 .. 200	//

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

4.Функції програми.

4.1.Додання даних про нового студента шляхом введення його даних з клавіатури з перевіркою належності значень визначеному діапазону.

4.2.Перегляд і редагування даних про студента.

4.3.Пошук даних про студента/студентів за ключем.

4.4.Вилучення даних про студента.

5.Специфікація вихідних даних.

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

40

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)