1

Лабораторна робота №3
Розробка специфікації вимог до ПЗ

Мета роботи: Вивчення процесу аналізу, документування та затвердження

вимог до програмного забезпечення (ПЗ) та розробка специфікації вимог (Software
Requirements Specifications (SRS))

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

3.1 ТЕОРЕТИЧНА ЧАСТИНА

3.1.1 Характеристики Специфікації вимог до програмного забезпечення

Специфікації вимог до програмного забезпечення (SRS) (також називають
документом вимог). Цей звіт закладає основу для діяльності з розробки програмного
забезпечення та створюється, коли виявляються й аналізуються всі вимоги. SRS – це
офіційний звіт, який виступає як представлення програмного забезпечення
(програмної системи), яке дозволяє клієнтам перевірити, чи воно (SRS) відповідає
їхнім вимогам. Крім того, він містить вимоги користувача до системи, а також
детальні специфікації системних вимог.
SRS – це специфікація для конкретного програмного продукту, програми або
набору програм, які виконують певні функції в певному середовищі. Цей документ
переслідує кілька цілей залежно від того, хто його пише. По-перше, SRS може бути
написаний клієнтом – замовником ПЗ. Тут SRS використовується для визначення
потреб і очікувань користувачів.. По-друге, SRS може бути написаний розробником
системи. У цьому разі специфікація пишеться для різних цілей і служить договірним
документом між замовником і ІТ компанією (виконавцем).
SRS повинна мати такі властивості (рис.3.1):
1. Правильність (Correctness): Огляд користувача використовується для
забезпечення точності вимог, викладених у SRS. SRS вважається ідеальною, якщо
вона покриває всі потреби, які дійсно очікуються від системи.
2. Повнота (Completeness): SRS є повною тоді і лише тоді, коли вона включає
такі елементи:
(1). Усі основні вимоги, пов’язані з функціональністю, продуктивністю,
дизайном, обмеженнями, атрибутами чи зовнішніми інтерфейсами.
(2). Визначення відповідей програмного забезпечення на всі реалізовані класи
вхідних даних у всіх можливих ситуацій.
(3). Повні позначки та посилання на всі рисунки, таблиці та діаграми в SRS та
визначення всіх термінів та одиниць вимірювання.
 2

Рисунок 3.1 – Властивості SRS [https://www.javatpoint.com/software-requirement-

specifications]

3. Узгодженість (Consistency): SRS є узгодженим тоді і тільки тоді, коли жодна

підмножина окремих вимог не має конфліктів з іншими. Існує три типи можливих
конфліктів у SRS:
(1). Зазначені характеристики об'єктів реального світу можуть конфліктувати.
Наприклад,
(a) Формат вихідного звіту може бути описаний в одній вимозі як табличний, а
в іншій як текстовий.
(b) Одна умова може вказувати, що всі вогні мають бути зеленими, а інша
вказує, що всі вогні мають бути синіми.
(2). Між двома вказаними діями може існувати розумний або тимчасовий
конфлікт. Наприклад,
(a) Одна вимога може визначити, що програма додасть два входи, а інша може
визначити, що програма їх помножить.
(b) Одна умова може стверджувати, що "A" завжди має слідувати за "B", тоді як
інша вимагає, щоб "A і B" зустрічалися одночасно.
(3). Дві або більше вимоги можуть визначати той самий об’єкт реального світу,
але використовувати різні терміни для цього об’єкта. Використання стандартної
термінології та описів сприяє послідовності.
4. Однозначність (Unambiguousness): SRS є однозначною, коли кожна фіксована
вимога має лише одне тлумачення. Це означає, що кожен елемент унікально
інтерпретується. Якщо метод використовується з декількома визначеннями, звіт про
 3

вимоги має визначати наслідки в SRS, щоб він був зрозумілим і простим для
розуміння.
5. Ранжування за важливістю та стабільністю (Ranking for importance and
stability): SRS ранжується за важливістю та стабільністю, якщо кожна вимога має
ідентифікатор, який вказує або на значимість, або на стабільність цієї конкретної
вимоги. Як правило, не всі вимоги однаково важливі. Деякі передумови можуть бути
важливими, особливо для життєво важливих додатків, а інші можуть бути бажаними.
Кожен елемент має бути визначений, щоб зробити ці відмінності чіткими та чіткими.
Інший спосіб ранжування вимог полягає в тому, щоб розрізняти класи предметів як
основні, умовні та необов'язкові.
6. Можливість модифікації (Modifiability): SRS має бути модифікованим
документом в залежності від змін, які необхідні у ПЗ. Зміни повинні бути ідеально
проіндексовані та мати перехресні посилання.
7. Можливість перевірки (Verifiability): SRS є правильним документом, якщо
вказані вимоги можна перевірити за допомогою економічно ефективності, щоб
перевірити, чи остаточне програмне забезпечення відповідає цим вимогам. Вимоги
перевіряються за допомогою рецензій.
8. Простежуваність (Traceability): SRS простежується, якщо походження кожної
з вимог є зрозумілим і якщо це полегшує посилання на кожну умову в майбутній
розробці або вдосконаленні документації. Існує два типи відстеження:
А. Зворотне відстеження: Це залежить від кожної вимоги, яка чітко посилається
на своє джерело в попередніх документах.
Б. Попереднє відстеження: Це залежить від того, чи кожен елемент у SRS має
унікальну назву або контрольний номер.
Простежуваність SRS є особливо важливо, коли програмний продукт
переходить у фазу експлуатації та обслуговування. Оскільки код і проектний
документ змінюються, необхідно мати можливість визначити повний набір вимог,
яких можуть стосуватися ці зміни.
9. Незалежність дизайну (Design independence): має бути можливість вибору з
кількох альтернатив дизайну для кінцевого варіанту системи. Зокрема, SRS не має
містити жодних деталей щодо реалізації.
10. Тестування(Testing): SRS має бути написаний таким чином, щоб було легко
генерувати тестові приклади та тестові плани зі звіту.
11. Зрозумість замовнику(Understandability) Кінцевий користувач може бути
експертом у своїй конкретній галузі, але може не бути навченим у інформатиці. Отже,
призначення формальних позначень і символів також слід уникати настільки,
наскільки це можливо. Мова повинна бути простою і зрозумілою.
12. Правильний рівень абстракції (Abstractness): якщо SRS написаний для етапу
вимог, деталі повинні бути пояснені чітко. Тоді як для техніко-економічного
обґрунтування можна використати менше вимог. Отже, рівень абстракції змінюється
відповідно до мети SRS.
Оскільки SRS є офіційним документом, то він повинен мати такі властивості:
 4

Стислість (Concise): Звіт з SRS має бути лаконічним і водночас однозначним,

послідовним і повним. Багатослівні та нерелевантні описи зменшують читабельність,
а також збільшують ймовірність помилок.
Структурований (Structured): має бути добре структурованим. Добре
структурований документ легко зрозуміти та змінити. На практиці документ SRS
зазнає кількох переглядів, щоб відповідати вимогам користувачів. Часто вимоги
користувачів змінюються протягом певного періоду часу. Тому, щоб легко було
вносити зміни до документа SRS, важливо зробити звіт добре структурованим.
Перегляд чорного ящика (Black-box view): він має лише визначати, що має
робити система, і утримуватися від вказівок, як це робити. Це означає, що документ
SRS повинен визначати зовнішню поведінку системи, а не обговорювати питання
впровадження. Звіт SRS має розглядати систему, що розробляється, як чорний ящик і
визначати зовнішню видиму поведінку системи. З цієї причини звіт SRS також
відомий як специфікація системи чорної скриньки.
Концептуальна цілісність (Conceptual integrity): документ SRS має
демонструвати концептуальну цілісність, щоб читач міг його просто зрозуміти.
Реакція на небажані події: має характеризувати прийнятні реакції на небажані
події. Це називається реакцією системи на виняткові умови.
Піддається перевірці (Verifiable): усі вимоги системи, задокументовані в
документі SRS, мають бути правильними. Це означає, що має бути можливість
вирішити, чи були виконані вимоги під час впровадження.

3.1.2 Основні компоненти SRS

У документі SRS має бути достатньо інформації для розробників, щоб
завершити описане програмне забезпечення. У ньому не тільки викладено опис
програмного забезпечення, що розробляється, але й мета, якій воно буде служити: що
програмне забезпечення має робити і як воно має працювати.
Документ SRS зазвичай включає такі елементи (рис.3.2):
• мета програмного забезпечення, що розробляється;
• загальний опис програмного забезпечення;
• функціональність програмного забезпечення або що воно має робити;
• продуктивність програмного забезпечення у виробничій ситуації;
• нефункціональні вимоги;
• зовнішні інтерфейси або те, як програмне забезпечення взаємодіятиме з
обладнанням або іншим програмним забезпеченням, до якого воно має підключатися;
• обмеження дизайну або обмеження середовища, в якому буде працювати
програмне забезпечення.
Основні стандарти, методології та скріплення знань, що згадуються ТЗ або SRS
(Software (or System) Requirements Specification): IEEE STD830-1998, ISO/IEC/ IEEE
29148-2011, RUP, SWEBOK, BABOK і пр.
 5

Рисунок 3.2 – Представлення вимог у специфікації

[https://www.youtube.com/watch?app=desktop&v=85VOKmpWLZk&ab_channel=RichM
illennialMindset]

IEEE STD 830-1998. Recommended Practice for Software Requirements.

Описується вміст і якісні характеристики правильно створеної специфікації вимог до
програмного забезпечення і міститься кілька шаблонів SRS. Ця рекомендована
методика має своєю метою встановити вимоги до розроблюваного ПЗ, але може
застосовуватися, щоб допомогти у виборі власних і комерційних програмних виробів.
Відповідно до стандарту технічного завдання повинні бути включені наступні
розділи:
1. Введення
2. Призначення
3. Область дії
4. Визначення, акроніми та скорочення
5. Посилання
6. Короткий огляд
7. Загальний опис
 6

8. Взаємодія продукту (з іншими продуктами та компонентами)

9. Функції продукту (короткий опис)
10. Характеристики користувача
11. Обмеження
12. Допущення та залежності
13. Детальні вимоги
14. Вимоги до зовнішніх інтерфейсів
15. Інтерфейси користувача
16. Інтерфейси апаратного забезпечення
17. Інтерфейси програмного забезпечення
18. Інтерфейси взаємодії
19. Функціональні вимоги
20. Вимоги до продуктивності
21. Проектні обмеження (і посилання на стандарти)
22. Нефункціональні вимоги (надійність, доступність, безпека та ін.)
23. Інші вимоги
24. Додатки
25. Алфавітний вказівник

Стандарт IEEE 29148-2011 забезпечує єдину трактовку процесів і продуктів,

які використовуються при розробці вимог протягом усього життєвого циклу системи
та програмного забезпечення. Він приходить на зміну стандартів IEEE 830-1998, IEEE
1233-1998, IEEE 1362-1998. Цей стандарт містить два шаблони специфікацій вимог:
• Специфікація системних вимог (SyRS)
• Специфікація вимог до програмного забезпечення (SRS)
Специфікація системних вимог (SyRS) визначає технічні вимоги до вибраної
системи та забезпечує взаємодію передбачуваної системи та людини. Вона визначає
високі вимоги до системи з точки зору предметної області, а також інформацію про
загальну цілісність системи та обмеження, недопущення та нефункціональні вимоги.
Вона може включати в себе концептуальні моделі, спроектовані для ілюстрації вмісту
системи, використання сценаріїв, основних сутностей предметної області, даних,
інформації та робочих процесів.
SyRS може містити наступні розділи:
1. Введення
2. Призначення системи
3. Зміст системи (обмеження системи)
4. Огляд системи
5. Зміст системи
6. Функції системи
7. Характеристики користувачів
8. Терміни і визначення
9. Посилання
 7

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

11. Функціональні вимоги
12. Вимоги до юзабилити
13. Вимоги до продукту
14. Інтерфейс (взаємодія) системи
15. Операції системи
16. Стан системи
17. Фізичні характеристики
18. Умови середовища
19. Вимоги до безпеки
20. Управління інформацією
21. Політики і правила
22. Вимоги до обслуговування системи на протязі її життєвого циклу
23. Вимоги до упаковки, завантаження-розвантаження, поставки та
транспортування
24. Тестування та перевірка (список необхідних прийомних тестів)
25. Додатки
26. Додатки та залежності
27. Абревіатури і скорочень
SRS — це специфікація вимог до певного програмного продукту, програми або
набору програм (продуктів), які виконують певні функції в конкретному середовищі.
За структурою дуже нагадує SRS зі стандарту IEEE 830.

Структура SRS в RUP (Rational Unified Process) є документ, в якому

необхідно описати артефакти, отримані в процесі специфікації вимог. Шаблон SRS в
RUP адаптований зі стандарту IEEE STD 830 і містить два варіанти:
• Традиційний шаблон SRS структурований функціональними вимогами до
функцій Системи, максимально схожий на STD 830.
• Спрощений шаблон SRS зі структурованими функціональними вимогами у
вигляді варіантів використання:
1. Введення.
2. Цель.
3. Короткий звід можливостей.
4. Визначення, акроніми та скорочення.
5. Посилання.
6. Короткий зміст.
7. Огляд системи
8. Огляд варіантів використаних.
9. Припущення та залежності.
10. Детальні вимоги
11. Опис варіантів використання.
12. Додаткові вимоги.
 8

13. Інші функціональні вимоги.

14. Нефункціональні вимоги.
15. Допоміжна інформація.

SWEBOK, BABOK, а також безліч інших методологій розробки ПО та зводів

знань при згадуванні SRS посилаються на вищевказані зарубіжні стандарти.
Також варто сказати, що для опису вимог до ПЗ використовуються та інші види
документів, які кожен називає за різним: FRD (Functional Requirements Document), RD
(Requirements Document), ПЗ (Постановка завдання або Пояснювальна записка) і пр.
Але це всі документи від вищевказаних стандартів, які не мають відмінкової
стандартизації, хоча, в деяких випадках, уже і з існуючою термінологією (рис.3.3).

Рисунок 3.3 – Приклад спеціфікації вимог [https://asana.com/ru/resources/software-

requirement-document-template]
 9

3.1.3 Функціональні та нефункціональні вимоги

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

Рисунок 3.4 – Основні вимоги у SRS [https://relevant.software/blog/software-

requirements-specification-srs-document/]
 10

Рекомендації з написання функціональних вимог.

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

Приклад 1:
Загальний зразок: <Назва системи> породжує <поведінка>
Приклад: Банкомат відхиляє запити на зняття коштів.

Приклад 2:
Для подальшого визначення вимоги умова додається до загального зразка.

<Назва системи> має <поведінка>, якщо <умова> має значення <фактор

якості>
Приклад: Банкомат відхиляє запити на зняття коштів, якщо запитувана сума
не ділиться на 10.

Приклад 3:
Вимога також може бути записана як керований подіями синтаксис.

<Зупиняюча дія > <необов’язкова передумова> <назва системи> повинна

<поведінка>
Приклад: Коли запитується зняття коштів, а сума, яка вимагається, не
ділиться на 10, банкомат відхиляє запити на зняття коштів.

Зверніть увагу, що у всіх трьох прикладах у вимозі завжди підтримується

загальний шаблон.
3.1.3 Написання документу специфікації вимог до ПЗ
Найкраще організувати процес написання документа SRS, починаючи з
основної та загальної інформації про програмне забезпечення (програмну систему), і
закінчуючи додаванням деталей, щоб конкретизувати чернетку. Ось шість кроків,
пов'язаних із створенням документа SRS у розробці програмного забезпечення:
 11

1 Створення плану. Першим кроком є створення схеми документа SRS. Ви

можете створити його самостійно або використовувати існуючий шаблон SRS як
відправну точку. Ось базовий приклад схеми SRS:
2 Визначення мети розробки ПЗ. Визначення мети продукту пишеться
зазвичай у вступі SRS. Тут описується цільова аудиторію і те, як вони
використовуватимуть продукт. Ось як ви повинні структурувати мету:
• Визначити обсяг продукту
• Опишіть цінність, яку це принесе
• Покажіть, хто використовуватиме програмне забезпечення
• Докладно опишіть, як це допоможе у роботі передбачуваних користувачів.
3. Огляд функціоналу. Визначивши призначення системи, підсумуйте, як вона
працюватиме. Тут надати загальний опис функцій програмного забезпечення та того,
як вони відповідають потребам користувача. Надається опис припущень про
функціональність продукту та все, від чого він залежить в поточній технологічній
екосистемі.
4. Опис функціональних та нефункціональних вимог. Докладний опис вимог
системи є найважливішим компонентом документа SRS. Досить детально описують
функціональні вимоги, щоб розробники могли приступити до роботи, та
нефункціональні вимоги, такі як характеристики безпеки та продуктивність.
Тут додаються варіанти використання, щоб описати, як користувач буде
взаємодіяти з системою. Тут деталізуються цілі проекту та вимірюватиметься, як
проект просувається під час розробки.
5 Додавання додаткових відомостей. Останнім кроком у створенні проекту
документа SRS до ПЗ є додавання будь-яких деталей, які можуть допомогти
розробникам завершити роботу у вигляді додатків, глосаріїв термінів та посилань.
6 Отримати схвалення. Після того, як додано до SRS достатньо подробиць,
щоб описати, що система має робити, документ зацікавленими сторонами.
Затверджується.
Швидше за все, далі робиться презентація для людей, залучених до процесу
розробки. Вони можуть попросити додати зміни, і доведеться оновити документ SRS
на основі відгуків зацікавлених сторін перед остаточним затвердженням. Це означає,
що і розробник, і замовник роблять документ точнішим.
Для покращення документу використовують різні схеми та моделі.
Варіант використання описує, як користувач взаємодіятиме з системою. Він
описуватиме продукт з погляду кінцевого користувача у простому форматі історії.
Написання варіантів використання змушує думати, що користувачі будуть робити із
програмним забезпеченням і як воно відреагує. Це справжня візуалізація
функціональних вимог. Ось кроки, яким можна слідувати, щоб написати варіант
використання (рис.3.5):
1. Опишіть кінцевих користувачів продукту.
2. Зосередьтеся на одному з цих користувачів.
 12

3. Розбийте взаємодії користувача на варіанти використання. Кожна взаємодія

– це варіант використання.
4. Опишіть послідовність подій кожного варіанта використання.
5. Напишіть докладний опис дій користувача та того, як має реагувати система.
6. Розширте кожен варіант використання альтернативними діями користувача
та відповідями системи.
7. Повторіть 1-6 кожного типу кінцевого користувача.

Рисунок 1.5 – Процес створення діаграми варіантів використання

3.2 ПРАКТИЧНА ЧАСТИНА

Завдання до лабораторної роботи
1. Вивчити теоретичний матеріал, що надано у першій частині.
2. Сформулювати основні функціональні, нефункціональні, системні та
користувацьки вимоги до ПЗ за темою дипломної роботи (наукової роботи) студента.
3. Розробити специфікацію вимог згідно шаблону, наданому у додатку.
4. Скласти звіт з лабораторної роботи, включаючи специфікацію вимог, яка
затверджується керівником дипломної роботи
 1
Software Requirements Specification for <Project

Додаток. Шаблон SRS

Специфікація вимог до
програмного продукту
Для

<Проект>

Затверджено версію 1.0

Підготовлено <автором>

<організація>

< створено>
 2
Software Requirements Specification for <Project

Зміст
1. Введення (Introduction) ....................................................................................3
1.1Мета (Purpose) .......................................................................................................................3
1.2Конвенції про документ (Document Conventions)..............................................................3
1.3Цільова аудиторія і пропозиції з читання (Intended Audience and Reading Suggestions)3
1.4Область проекту (Project Scope) ..........................................................................................3
1.5Посилання (References) ........................................................................................................3
2. Загальний опис (Overall Description) ............................................................4
2.1Перспектива продукту (Product Perspective) ......................................................................4
2.2Особливості продукту (Product Features) ...........................................................................4
2.3Класи та характеристики користувачів (User Classes and Characteristics) .......................4
2.4Операційне середовище (Operating Environment) ..............................................................4
2.5Обмеження щодо проектування та впровадження (Design and Implementation Constraints)
4
2.6Документація користувача (User Documentation) ..............................................................5
2.7Припущення та залежності (Assumptions and Dependencies) ...........................................5
3. Системні функції (System Features) ...............................................................6
3.1Системна функція 1 (System Feature 1)...............................................................................6
3.2Системна функція 2 (і так далі) (System Feature 2 (and so on)).........................................8
4. Вимоги до зовнішнього інтерфейсу (External Interface Requirements) ..5
4.1Інтерфейси користувача (User Interfaces) ...........................................................................5
4.2Апаратні інтерфейси (Hardware Interfaces) ........................................................................5
4.3Інтерфейси програмного забезпечення (Software Interfaces) ............................................6
4.4Інтерфейси зв'язку (Communications Interfaces) .................................................................6
5. Інші нефункціональні вимоги (Other Nonfunctional Requirements) .......8
5.1Вимоги до продуктивності (Performance Requirements) ...................................................9
5.2Вимоги до безпеки (Safety Requirements) ...........................................................................9
5.3Вимоги безпеки(Security Requirements)............................................................................10
5.4Атрибути якості програмного забезпечення (Software Quality Attributes) ....................10
6. Інші вимоги (Other Requirements) ...............................................................11

Журнал версій (Revision History)

Ім'я Дата Причина для змін Версія
 3
Software Requirements Specification for <Project

1. Введення (Introduction)

1.1 Мета (Purpose)

<Визначте програмний продукт, вимоги до якого вказані в цьому документі, включно з
номером версії або випуску. Опишіть сферу дії продукту, на який поширюється ця SRS,
особливо якщо ця SRS описує лише частину системи або одну підсистему.>

1.2 Умовні позначення документів (Document Conventions)

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

1.3 Цільова аудиторія і пропозиції з читання (Intended Audience and

Reading Suggestions)
<Опишіть різні типи читачів, для які призначено документ, наприклад розробників,
керівників проектів, співробітників маркетингу, користувачів, тестувальників і авторів
документації. Опишіть, що містить інша частина цієї SRS і як вона організована.
Запропонуйте послідовність читання документа, починаючи з оглядових розділів і переходячи
до розділів, які найбільше відповідають кожному типу читача.>

1.4 Область застосування продукту (Product Scope)

Надайте короткий опис зазначеного програмного забезпечення та його призначення,
включаючи відповідні переваги, завдання та цілі. Пов’яжіть програмне забезпечення з
корпоративними цілями чи бізнес-стратегіями. Якщо доступний окремий документ щодо
бачення та обсягу, зверніться до нього, а не дублюйте його вміст тут. SRS, який визначає
наступний випуск продукту, що розвивається, повинен містити власну сферу застосування
як підмножину довгострокового стратегічного бачення продукту.>

1.5 Посилання (References)

< Перелічіть будь-які інші документи або веб-адреси, на які посилається ця SRS. Вони
можуть включати в себе посібники зі стилю інтерфейсу користувача, контракти, стандарти,
специфікації системних вимог, документи варіантів використання або документ бачення та
обсягу. Надайте достатньо інформації, щоб читач міг отримати доступ до копії кожного
посилання, включаючи назву, автора, номер версії, дату та джерело або посилання.>
 4
Software Requirements Specification for <Project

2. Загальний опис (Overall Description)

2.1 Перспектива продукту (Product Perspective)

<Опишіть контекст і походження продукту, указаного в цій SRS. Наприклад, укажіть, чи
є цей продукт елементом сімейства продуктів, заміною певних існуючих систем або новим
автономним продуктом. Якщо SRS визначає компонент більшої системи, пов'язати вимоги
більшої системи з функціональністю цього програмного забезпечення та визначити
інтерфейси між ними. Може бути корисною проста схема, яка показує основні компоненти
загальної системи, взаємозв’язки підсистем і зовнішні інтерфейси.>

2.2 Особливості продукту (Product Features)

< Узагальніть основні функції, які продукт повинен виконувати або повинен дозволяти
виконувати користувачеві. Подробиці будуть надані в Розділі 3, тому тут потрібне лише
резюме високого рівня (наприклад, маркований список). Впорядкуйте функції так, щоб вони були
зрозумілі будь-якому читачеві SRS. Часто ефективним є зображення основних груп пов'язаних
вимог та їх взаємозв'язок, таких як діаграма потоків даних верхнього рівня або діаграма
класів.>

2.3 Класи та характеристики користувачів (User Classes and

Characteristics)
<Визначте різні класи користувачів, які, як ви очікуєте, використовуватимуть цей
продукт. Класи користувачів можуть бути диференційовані в залежності від частоти
використання, підмножини використовуваних функцій продукту, технічної експертизи, рівня
безпеки або привілеїв, освітнього рівня або досвіду. Опишіть доречні характеристики кожного
класу користувача. Деякі вимоги можуть стосуватися лише певних класів користувачів.
Відокремте привілейовані класи користувачів від тих, для яких задоволення їх вимог менш
важливо >

2.4 Операційне середовище (Operating Environment)

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

2.5 Обмеження щодо проектування та впровадження (Design and

Implementation Constraints)
< Опишіть будь-які елементи або проблеми, які обмежуватимуть можливості, доступні
розробникам. Вони можуть включати: корпоративну або регуляторну політику; апаратні обмеження
(вимоги до часу, вимоги до пам'яті); інтерфейси для інших програм; конкретні технології, інструменти
та бази даних, які будуть використовуватися; паралельні операції; мовні вимоги; протоколи зв'язку;
міркування безпеки; умов проектування або стандартів програмування (наприклад, якщо організація
замовника відповідатиме за підтримку поставленого програмного забезпечення).>
 5
Software Requirements Specification for <Project

2.6 Документація користувача (User Documentation)

<Перелічіть компоненти документації користувача (такі як посібники користувача, он-
лайн довідка та навчальні посібники), які будуть надані разом із програмним забезпеченням.
Визначте будь-які відомі формати або стандарти надання документації користувача.>

2.7 Припущення та залежності (Assumptions and Dependencies)

<Перерахувати будь-які припущені фактори (на відміну від відомих фактів), які можуть
вплинути на вимоги, викладені в SRS. Це можуть бути сторонні або комерційні компоненти,
які ви плануєте використовувати, проблеми навколо розробки або операційного середовища
або обмеження. Проект може постраждати, якщо ці припущення неправильні, не будуть
передані або будуть змінені. Також визначте будь-які залежності проекту від зовнішніх
факторів, таких як програмні компоненти, які ви маєте намір використовувати з іншого
проекту, якщо вони вже задокументовані в іншому місці (наприклад, у документі бачення та
обсягу або плані проекту).>

3. Вимоги до зовнішнього інтерфейсу (External Interface

Requirements)

3.1 Інтерфейси користувача (User Interfaces) -(UINT)

<Опишіть логічні характеристики кожного інтерфейсу між програмним продуктом і
користувачами. Це може включати зразки зображень на екрані, будь-які стандарти графічного
інтерфейсу користувача або посібники з сімейства продуктів, яких слід дотримуватися, обмеження
макета екрана, стандартні кнопки та функції (наприклад, довідка), які відображатимуться на кожному
екрані, комбінації клавіш, стандарти відображення повідомлень про помилки тощо. Визначте
компоненти програмного забезпечення, для яких потрібен user interface. Деталі дизайну інтерфейсу
користувача повинні бути задокументовані в окремій специфікації інтерфейсу користувача.>

Ідентифікатор вимог Опис

до інтерфейсів

UINT-01

UINT-02

UINT-03

3.2 Апаратні інтерфейси (Hardware Interfaces) - (HINT))

<Опишіть логічні та фізичні характеристики кожного інтерфейсу між програмним
продуктом і апаратними компонентами системи. Це може включати підтримувані типи пристроїв,
характер даних і контроль взаємодії між програмним забезпеченням і обладнанням, а також протоколи
зв'язку, які будуть використовуватися.>
 6
Software Requirements Specification for <Project

3.3 Інтерфейси програмного забезпечення (Software Interfaces) - (SwINT)

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

3.4 Інтерфейси зв'язку (Communications Interfaces) -(CINT)

<Опишіть вимоги, пов’язані з будь-якими функціями зв’язку, що вимагаються цим продуктом,
включаючи електронну пошту, веб-браузер, протоколи зв’язку мережевих серверів, електронні форми
тощо.
Визначте відповідне форматування повідомлення.
Визначте будь-які стандарти зв'язку, які будуть використовуватися, такі як FTP або HTTP.
Вкажіть будь-які проблеми безпеки або шифрування зв'язку, швидкості передачі даних та
механізми синхронізації.>

4. Особливості системи (System Features)

<Цей шаблон ілюструє впорядкування функціональних вимог до продукту за характеристиками
системи, основних послуг, що надаються продуктом.
Ви можете впорядкувати цей розділ за допомогою варіантів використання, режиму роботи, класу
користувача, класу об'єкта, функціональної ієрархії або їх комбінації, залежно від того, що є найбільш
доцільним для продукту.>
Вимоги можуть будуть розміщені згідно пріоритетам, що базуються на техніці MoSCoW, котра
розділяє вимоги на наступні категорії:

Рейтинг пріоритетів Опис

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

4.1 Функція 1 (System Feature 1)

< Сформулюйте основні функції (основні модулі) кількома словами.>

3.1.1 Опис і пріоритет (Description and Priority)

 7
Software Requirements Specification for <Project

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

3.1.2 Послідовності стимулів/відповідей (Stimulus/Response Sequences)

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

3.1.3 Функціональні вимоги (Functional Requirements)

<Визначте докладні функціональні вимоги, пов’язані з цією функцією. Це можливості програмного
забезпечення, які повинні бути присутніми для того, щоб користувач міг виконувати сервіси, що
надаються функцією, або виконувати варіант використання. Включіть, як продукт повинен реагувати
на очікувані умови помилок або недійсні введені дані.
Вимоги повинні бути стислими, повними, однозначними, перевіряними та необхідними.
Використовуйте «TBD» як покажчик місця заповнення, щоб вказати, що потрібна інформація ще
недоступна.>

< Кожна вимога має бути однозначно ідентифікована за допомогою порядкового номера або
якогось значущого тегу.>

[Документуйте вимоги у табличному форматі, наведеному нижче, та додайте за необхідності.

Вказівки щодо написання функціональної вимоги див. у п.3.1.3.]

Функція: [Наприклад, запис студента]

ID функціональної вимоги FR01

Тип вимоги Наприклад, валідація
Пріоритет Наприклад, М.
Опис вимоги Наприклад, система перевіряє номер студента, введений за списком
вищих навчальних закладів. Якщо номер студента не знайдений у списку,
відображається повідомлення про помилку, і студент не приймається
випускниками.
Перехресне посилання на Наприклад, BR01
вимоги бізнесу
Перехресне посилання на Наприклад, UC01
використання
Бізнес правило Наприклад, Повідомлення про помилку, яке повинно відображатися: «Не
вдається знайти номер студента. Будь ласка, налаштуйте дані студента,
перш ніж продовжувати реєстрацію. "
Джерело Наприклад, семінар з управлінням Управління студентами
 8
Software Requirements Specification for <Project

4.2 Функція 2 (і так далі) (System Feature 2 (and so on))

ID функціональної вимоги FR02

Тип вимоги Наприклад, верифікація
Пріоритет Наприклад, М
Опис вимоги Наприклад, система повинна отримувати та перевіряти платіжну
інформацію студента з платіжної системи.
Перехресне посилання на Наприклад, BR01
вимоги бізнесу
Перехресне посилання на Наприклад, UC02
використання
Бізнес правило -
Джерело Наприклад, семінар з управлінням Управління студентами
 9
Software Requirements Specification for <Project

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

Requirements)
Нефункціональна вимога може бути представлена у табличній формі так:
[Назва функції, наприклад, запис студента]

ID нефункціональної NFR01
вимоги
Тип вимоги Наприклад, ефективність
Пріоритет Наприклад, H
Опис вимоги Наприклад, система повинна завершити процес перевірки запису за 1 хвилину.
Перехресне посилання Наприклад, BR01
на вимоги бізнесу
Перехресне посилання Наприклад, FR01, FR02
на використання
Бізнес правило Наприклад, UC01
Джерело -
Тип вимоги Наприклад, семінар з управлінням Управління студентами

5.1 Вимоги до продуктивності (Performance Requirements) - (PER)

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

Ідентифікатор вимог до Опис вимоги

продуктивності

PER-01

5.2 Вимоги щодо неушкодженості (техніки безпеки) (Safety

Requirements)- (SAF)
<Вкажіть вимоги, які стосується можливої втрати, пошкодження або шкоди, яка може призвести
до використання програмного виробу. Визначте будь-які запобіжні заходи або дії, які повинні бути вжиті,
а також дії, які повинні бути попереджені. Зверніться до будь-яких зовнішніх політик або нормативно-
 10
Software Requirements Specification for <Project

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

5.3 Вимоги безпеки (Security Requirements)- (SEC)

<Укажіть будь-які вимоги щодо питань безпеки або конфіденційності, пов'язаних із
використанням продукту або захистом даних, що використовуються або створюються продуктом.
Визначте будь-які вимоги автентифікації посвідчення користувача. Зверніться до будь-яких зовнішніх
політик або нормативно-правових актів, що містять проблеми з безпекою, які впливають на продукт.
Визначте будь-які сертифікати безпеки або конфіденційності, які повинні бути задоволені.>

Ідентифікатор вимог Опис вимоги

безпеки

SEC-01 Розмежування прав доступу користувачів.

SEC-02

SEC-03

5.4 Атрибути якості програмного забезпечення (Software Quality

Attributes)
<Вкажіть будь-які додаткові якісні характеристики продукту, які будуть важливими як для
споживачів, так і для розробників. Деякі з них слід врахувати: пристосованість, доступність,
правильність, гнучкість, сумісність, ремонтопридатність, портативність, надійність, багаторазове
використання, надійність, тестованість та зручність використання. Напишіть їх як конкретні, кількісні
та перевіряються, коли це можливо. Принаймні, поясніть відносні переваги щодо різних атрибутів,
таких як простота використання порівняно з простотою навчання.>
 11
Software Requirements Specification for <Project

6. Інші вимоги (Other Requirements)

<Визначте будь-які інші вимоги, не охоплені в іншому місці SRS. Це може включати
вимоги до бази даних, вимоги до інтернаціоналізації, юридичні вимоги, повторне використання
цілей для проекту тощо. Додайте будь-які нові розділи, які відстоюють проект.>

Додаток A: Глосарій (словник) (Glossary)

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

Додаток B: Моделі аналізу (Analysis Models)

< Необов’язково включіть будь-які відповідні моделі аналізу, такі як діаграми потоків
даних, діаграми класів, діаграми переходів стану або діаграми взаємозв’язків сутності
(сутність-зв’язок).>

Додаток C: Список проблем (Issues List)

< Це динамічний перелік питань відкритих вимог, які залишаються для відповіді,
включаючи TBD (To Be Determined (буде визначено) або To Be Decided (буде вирішено)), рішення,
що очікують на розгляд, необхідну інформацію, конфлікти, що очікують вирішення, тощо..>
 1
Software Requirements Specification for <Project

Додаток до лабораторної роботи

Нефункціональні вимоги (Non-functional requirements)
https://ua.kursoviks.com.ua/metodychki/5168-korotko-pro-user-stories-nefunktsionalni-
vimogi-non-functional-requirements
На початку проекту збираються нефункціональні вимоги (Non-functional
requirements) – вимоги до характеру поведінки системи:
- бізнес-правила – визначають обмеження, що виникають з предметної
області та властивостей автоматизується об'єкта (підприємства);
- системні вимоги й обмеження – визначення елементарних операцій, які
повинна мати система, а також різні умови, яким вона може задовольняти;
- атрибути якості;
- зовнішні системи та інтерфейси;
- обмеження.
Приклад нефункціональних вимог (для веб-додатку «СППР NooTron»)
представлені у табл.

Name Requirements
NF-1: Portability Web-application must work with such browsers: IE > 8, Mozila Firefox >
constraints for NooTron 6, Google Chrome > 6, Opera > 10
NF-2: Performance All MCDA methods, except Integrated methods and ANP, must be
constraints for NooTron performed up to 3 seconds. ANP - up to 15 seconds (it depends on the size
of the supermatrix).
Integrated methods must be performed up to 5 seconds. Meantime for
response to button click must be up to 5 seconds. Page load time must be
up to 5 seconds. The application must work correctly with the number of
simultaneous users not less than 50 people.
NF-3: Robustness All exceptions must be followed by error pages.
constraints for NooTron For example, Page is temporarily unavailable
Sorry, this page is temporarily unavailable.
Please, contact your administrator. There must not be memory leaks.
NF-4: Availability The application must be available during study hours.
constraints for NooTron
NF-5: Environmental CPU must be no less than Pentium 5, RAM must be no less than 4
constraints for NooTron GB, OS - all available, HDD 200 GB
NF-6: Open source Only open source software and freeware must be used.
constraints for NooTron For example, Apach - Apache 2.0, lgpl.
NF-7: Sequrity Multi-system access. Registration and authorization.
constraints for NooTron
NF-8: Usability User’s experience level (confident user). Aesthetics (brightness -
constraints for NooTron moderate).
 2
Software Requirements Specification for <Project

NF-9: Supportability The first Release of application must be ready up to the 7th of May.
constraints for NooTron Application will be improved next year by the next group of students, so
why software must be delivered with source code and artifacts describing
it.
NF-10: Localizability Application must be localized by such languages: ru, eng, ua. The default
constraints for NooTron application language is Russian. The application starts with this language.
NF-11: Reliability There must be provided the procedure for logging and tracking defects.
constraints for NooTron Meantime to repair must be no more than 5 hours.

Приклади Software Requirements Specification

Software Requirements Specification document with example //

https://krazytech.com/projects/sample-software-requirements-specificationsrs-report-airline-
database
Your 2022 Guide to Writing a Software Requirements Specification (SRS) Document
//https://relevant.software/blog/software-requirements-specification-srs-document/
Software Requirement Specification: How to make SRS for your project [with examples]
https://ddi-dev.com/blog/programming/how-to-write-software-requirement-specification-for-your-
project/
Linda Westfall, Software Requirements Engineering: What, Why, Who, When, and How
//https://comp.anu.edu.au/courses/comp3530/readings/The_Why_What_Who_When_and_How_Of
_Software_Requirements.pdf