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

програмного забезпечення
Для

<Проект>

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

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

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

< створено>

Авторське © 2002 Карл Е. Вігерс. Дозвіл надається на використання, змінення та розповсюдження

цього документа.
Software Requirements Specification for <Project> Сторінка 0

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

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

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

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

1.1 Мета (Purpose)

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

1.2 Конвенції про документ (Document Conventions)

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

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

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

1.4 Область проекту (Project Scope)

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

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

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

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)
<Опишіть будь-які елементи або проблеми, які обмежать параметри, доступні
розробникам. Це може бути: корпоративна або регуляторна політика; апаратні
обмеження (вимоги до часу, вимоги до пам'яті); інтерфейси до інших додатків; конкретні
технології, інструменти та бази даних, які будуть використовуватися; паралельні
операції; мовні вимоги; протоколи зв'язку; міркування безпеки; дизайнерські конвенції або
стандарти програмування (наприклад, якщо організація замовника буде нести
відповідальність за обслуговування поставленого програмного забезпечення).>
Software Requirements Specification for <Project> Сторінка 3

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

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

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

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

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

Requirements)

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

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

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

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

UINT-01

UINT-02

UINT-03

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

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

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

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

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

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

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

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

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

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

2.1 Функція системи 1 (System Feature 1)

< Сформулюйте основні функції (основні модулі) кількома словами.>
3.1.1 Опис і пріоритет (Description and Priority)
<Надайте короткий опис функції та вкажіть, чи має вона високий, середній або
низький пріоритет.
Ви також можете включити конкретні рейтинги пріоритетних компонентів, такі
як вигода, штраф, вартість і ризик (кожен з яких оцінюється за відносною шкалою від
низької 1 до високої 9).>
3.1.2 Послідовності стимулів/відповідей (Stimulus/Response Sequences)
< Перелічіть послідовності дій користувача та відповіді системи, які стимулюють
поведінку, визначену для цієї функції.
Вони відповідатимуть діалоговим елементам, пов’язаним із варіантами
використання(прецедентами)>
3.1.3 Функціональні вимоги (Functional Requirements)
<Визначте докладні функціональні вимоги, пов’язані з цією функцією. Це можливості
програмного забезпечення, які повинні бути присутніми для того, щоб користувач міг
виконувати сервіси, що надаються функцією, або виконувати варіант використання.
Включіть, як продукт повинен реагувати на очікувані умови помилок або недійсні введені
дані.
Вимоги повинні бути стислими, повними, однозначними, перевіряними та
необхідними. Використовуйте «TBD» як покажчик місця заповнення, щоб вказати, що
потрібна інформація ще недоступна.>
< Кожна вимога має бути однозначно ідентифікована за допомогою порядкового
номера або якогось значущого тегу.>
[Документуйте вимоги у табличному форматі, наведеному нижче, та додайте за необхідності.
Вказівки щодо написання функціональної вимоги див. у п.3.1.3.]
Функція: [Наприклад, запис студента]

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

Тип вимоги Наприклад, валідація

Пріоритет Наприклад, М.

Опис вимоги Наприклад, система перевіряє номер студента, введений за списком

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

Перехресне посилання на Наприклад, BR01

вимоги бізнесу
Перехресне посилання на Наприклад, UC01
використання
Бізнес правило Наприклад, Повідомлення про помилку, яке повинно відображатися: «Не
вдається знайти номер студента. Будь ласка, налаштуйте дані студента,
перш ніж продовжувати реєстрацію. "

Джерело Наприклад, семінар з управлінням Управління студентами

Software Requirements Specification for <Project> Сторінка 6

2.2 Системна функція 2 (і так далі) (System Feature 2 (and so on))

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

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

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

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

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

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

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

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

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

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

PER-01
Software Requirements Specification for <Project> Сторінка 8

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

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

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

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

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

безпеки

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

SEC-02

SEC-03

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

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

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

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

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

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

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

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

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

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