Життєві цикли програмного забезпечення.

Вимоги.

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

Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.

Специфікація ПЗ - формальний опис вимог.

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

Аналіз вимог є першим етапом розробки ПЗ, на якому вимоги замовника уточнюються, формалізуються і документуються. Фактично від цього етапу залежить успіх і на ньому треба відповісти на запитання: "Що повинен робити майбутній програмний продукт?".

Першочерговими вимогами до розроблюваного ПЗ визначаються такі:

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

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

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

Хороший опис вимог повинен:

• бути повним і послідовним;

• описувати, як поводиться система, як вона побудована;

• розглядати будь-які обмеження системи;

• бути легким у розвитку;

• брати до уваги можливі майбутні зміни;

• описувати виключення.

Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і зневага виключеннями. І користувачі, і аналітики мають таку схильність.

Вимоги до ПЗ можуть бути розділені на два типи:

• Функціональні вимоги. Вони описують функції (операції, дії) виконувані системою;

• Нефункціональні вимоги. Вони описують обмеження функціональності.

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

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

Неспеціалізована мова часто використовується для опису вимог, але при цьому є деякі незручності:

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

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

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

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

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

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

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

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

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

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

• вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша";

• вимоги процесу, наприклад "система повинна виконувати за стандартом XXA/2002" ;

• зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001, і ніякі зміни в базі даних недопустимі".

Атрофовані вимоги повинні бути кількісними, тобто повинен існувати метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню.

Труднощі з формулюванням вимог виникають по наступних причинах:

• клієнт не знає, як цілі можуть бути досягнуті. З іншого боку є багато способів досягнення цілей;

• великі системи використовуються багатьма користувачами. Можуть бути протиріччя в причинах їх використання. Різні користувачі можуть знати різну термінологію;

• люди, що розміщують замовлення і користувачі - різні люди. Думка замовників може бути критичною на цьому етапі, але вони, можливо, не враховують деяких потреб користувачів.

Можна описати вимоги клієнта на різних абстрактних рівнях:

• визначення вимог. Загальний опис, який проводиться після інтерв'ю з представниками клієнта;

• специфікація вимог. Опис, який використовує структуровану і природну мову і вводить деяку просту формальну примітку;

• специфікація ПЗ - повністю формальний опис вимог.

Вимоги повинні міститися в документі з описом вимог, який повинен охоплювати:

• введення - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу;

• опис розвитку системи - опис можливих змін;

• опис функціональних вимог;

• опис атрофованих вимог;

• модель системи;

• словник.

Цей документ може містити додаткову інформацію:

• специфікація функціональних вимог;

• специфікація нефункціональних вимог;

• вимоги до устаткування;

• вимоги до баз даних;

• індекс;

• плани тестування.

Доступність системи.

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

Чинниками успіху для функціонального формулювання вимог є:

• робота з відповідними представниками клієнта;

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

• перевірка завершеності і послідовності вимог;

• невеликий опис нефункціональних вимог.

Якісний опис вимог повинен задовольняти наступні вимоги:

• бути повним і послідовним;

• описувати зовнішній режим роботи;

• описувати обмеження системи;

• бути легким для модифікування;

• брати до уваги можливі майбутні зміни;

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

Типова помилка на цьому етапі це фокусування на типових ситуаціях і зневага виключеннями та неочікуваними ситуаціями. І користувачі, і аналітики роблять цю помилку.

Рекомендації до правильних визначень.

Вимоги повинні бути сформульовані критично у порівнянні до існуючого ПЗ і прототипів.

Вимоги користувача повинні бути:

• зрозумілими;

• унікальними;

• такими, щоб їх можна було перевірити;

• точними;

• реалістичними;

• досяжними.

Найбільш важливі методи ідентифікації вимог:

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

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

• вивчення досяжності. (Повинні бути визначені реалістичні цілі і методи);

• прототипування. Побудова прототипів систем з меншим об'ємом і спрощеним інтерфейсом.

Системні вимоги можуть бути документовані декількома способами. Можливі методи документування:

• звичайна мова. Найчастіше використовується. (Незручності - в її невизначеності і гнучкості, що дає можливість описувати одне і те ж декількома шляхами. Зв'язки між різними вимогами не можуть бути визначені, і виникають суперечності);

• математичний формалізм. (Вживається давно);

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

• таблиці, форми. (Вимоги задані в таблицях (зазвичай дворівневі), асоційовані різними зв'язками (наприклад, таблиця з зв'язками типів користувачів з сервісами));

• блоки і діаграми. (Графічні форми, що зображують процеси);

• контекстні діаграми. (Показують системи, оточення, входи і виходи);

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

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

Основні вимоги розділені на дві групи:

• функціональні вимоги;

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

Функціональний опис вимог здійснює:

• ідентифікація всіх типів користувачів системи;

• ідентифікація всіх типів користувачів підтримки (адміністратори, клерки);

• визначення кожного типу користувачів всіх системних функцій і шляхів використання системи;

• опис зовнішніх систем (бази даних, Інтернету, різних мереж), що будуть використовуватися системою;

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

Функціональні вимоги можуть бути сформульовані використовуючи шаблони вимог.

Шаблон гарантує стандартне формулювання і полегшує завершення формулювання.

Таблиця 1. Функціональні вимоги.

Назва функції	Майстер обробки прибутку
Опис	Функція дозволяє редагувати прибуток платника податків заданого року
Вхідні дані	Дані про доходи, отримані з різних джерел, витрати на отриманий прибуток, податки на різні внески. Інформація про квитанції. Інформація та документи платника податків.
Джерело вхідних даних	Інформація податкової служби
Результат
Початкова умова	Прибуток = весь прибуток - витрати на отриманий прибуток. Весь прибуток, прибуток і витрати на отримання прибутку - всі джерела прибутку.
Кінцева умова	Така ж, як зазначено вище
Побічні ефекти	Змінення бази оподаткування
Причина	Функція дозволяє робити розрахунки швидше і без помилок

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

Опис вимог включає об’єкти, над яким будуть виконуватись функції:

• вимога продуктів, наприклад, повинна бути доступна клавіатура;

• вимога процесів, наприклад, процес планувальника винен виконаються за стандартом XXXA/06;

• зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.

Якісна форма представлення нефункціональних вимог - це таблиця, наприклад:

Таблиця 2. Нефункціональні вимоги.

№	Дата	Автор	Вимога	Причина	Примітки
1	99/04/14	A.Nowak, J.Pietrjak	Програма повинна видавати результат не більше, ніж через 5 секунд при роботі 100 користувачів одночасно	Програма не буде конкурентоспроможною	Може працювати нестабільно
2	00/02/05	K.Lubicz	Кожен клієнт повинен мати дуже коротку IP-адресу	Інші ідентифікатори (SIN, Pesel) нестабільні, довгі, можуть повторюватися у різних користувачів
3	...	...	...	...	...

Складові нефункціональних вимог:

• Системні функції (ієрархія функцій, що виконуються системою);

• Об’єм (скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки інформації буде збережено?);

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

• Точність (вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними);

• Обмеження (обмеження інтерфейсу, якості, часових інтервалів, устаткування, засобів програмування і т.п.);

• Інтерфейс зв'язку (тип мережі, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.);

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

• Програмний інтерфейс (сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД));

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

• Адаптивність (специфікація відповіді системи на зміни - нові команди, нове вікно і т.п.);

• Безпека (конфіденційність, специфікація надійності і т.п.);

• Гнучкість (невдач, наслідки помилок ПЗ, помилка живлення, частота і т.п.);

• Стандарти (специфікація стандартів документів, форматів файлів, розміри шрифтів, стандарти процесів і продуктів і т.п.);

• Ресурси (бюджет, людський ресурс і обмеження матеріальних ресурсів);

• Час (час, необхідний для побудови системи, тренування і установки).

Перевірка вимог.

Типова помилка формування нефункціональних вимог - брак критеріїв, необхідних для перевірки вимог. Кожна нефункціональна вимога повинна бути перевірена. Це вимагає вибір критеріїв.

Таблиця 3. Критерії перевірки вимог.

Характеристика	Міра
Продуктивність	Кількість транзакцій за секунду Час відгуку
Розмір	Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача	Час, потрібний для навчання Розмір документації
Надійність	Вірогідність помилки трансакції Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість	Розмір платформозалежного коду Кількість платформ Вартість перенесення

Документ з вимогами.

Системні вимоги повинні бути описані в документі, який є базою для контракту користувача з розробниками. Документ повинен бути прийнятий клієнтом та розробником і зрозумілий обом. Документ повинен бути підготовлений так, щоб підтримувалася перевірка задоволення вимог.

Таблиця 4. Приклад документа з вимогами.

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення	Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
	1.  Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2.  Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3.  Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги 4. Доповнення

Послідовність дій, необхідних для оформлення документа, повинна бути наступною:

• якщо немає інформації, записати "не додається";

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

• будь-який матеріал, що не увійшов до секції, повинен бути доданий в "Додаток".

Часто до документа додаються:

• вимоги апаратного і програмного забезпечення;

• модель системи (архітектура);

• словник (термінологія, синоніми, абревіатури);

• зміст.

Найбільш важливі чинники формулювання якісних вимог:

• Стиль :

  • ясність - однозначне формулювання, зрозуміле для користувача і розробника;

  • структура документа;

  • відповідність - ніяких конфліктів у формуванні вимог;

  • змінність - формулювання по ключових моментах.

• Гнучкість :

  • легке додавання нових вимог.

• Специфікація ролей :

  • можливість пов'язати персону з вимогою, описувати дію вимоги.

• Помірність :

  • паперовий або електронний варіант;

  • контроль версії документа.

Словник.

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

Таблиця 5. Приклад словника.

Термін	Визначення	Синоніми
Банківський рахунок	Послідовність номерів, записаних через дефіс, що визначають ресурси та операції клієнта	рахунок
Клієнт	Одиниця апаратури, котра використовується клієнтом в офісі	робоча станція
Користувач	Особа, котра використовує програму для його/її власних цілей, що не мають відношення до адміністрації та обслуговуючого персоналу	Клієнт
…	…	…

Ключові чинники успіху етапу формулювання вимог є :

• приведення прикладів клієнтові для роз'яснення неоднозначностей;

• повна ідентифікація вимог, виявлення специфічних і виняткових вимог.

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

Модель

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

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

Розробники інформаційних систем під час проектування використовують наступні моделі:

• модель вимог - описує способи використання;

• аналітична модель - статика і динаміка системи, описуються мовою UML (деталями реалізації нехтують);

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

Аналітична модель.

Аналітична модель найдетальнішим чином описує те, для чого призначена система. Модель не має відношення до самої реалізації.

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

Аналітична модель - модель, яка будується на етапі аналізу. Мета етапу - розпізнавання всіх чинників або умов в даній області, в проектному оточенні, в існуючих і запланованих комп'ютерних системах, які можуть вплинути на ухвалення рішень, якості системи і реалізацію вимог. Результат - логічна модель системи, яка описує метод реалізації вимог але не зачіпає нічого, що стосується реалізації.

Наступний етап - етап дизайну. Він відповідає на питання, як система повинна реалізовуватися і описує цю реалізацію.

Причини побудови більшої моделі:

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

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

• бюджет може не дозволити повної розробки системи "з нуля", і визначення способів побудови буде проведено під час аналізу.

Якісна аналітична модель повинна мати наступні характеристики:

• вона повинна бути спрощеним описом системи;

• функції повинні бути представлені ієрархічно;

• логічна модель повинна відповідати певним правилам;

• повинна будуватися за допомогою добре відомих методів і інструментів;

• модель використовується для ухвалення рішень в подальшому дизайні.

Модель ПЗ повинна бути спрощеним описом, який представляє найважливіші особливості ПЗ на високому абстрактному рівні.

Логічна модель :

• показує, що повинна робити система;

• показує ієрархію системи;

• уникає термінології реалізації;

• дозволяє ухвалювати рішення "від причини до наслідків" і назад.

При побудові аналітичної моделі найчастіше роблять такі записи:

• звичайна мова;

• графічні записи;

• специфікація - структурований текстовий і числовий опис.

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

Функції запису:

• інструмент аналітика і дизайнера;

• зв'язок з користувачем;

• зв'язок з іншими членами команди;

• основа для реалізації ПЗ;

• опис технічної документації.

Запис повинен бути простий, зрозумілий, конкретний, легкий для розуміння, дозволяючи моделювати складні зв'язки.

Дії на етапі аналізу.

Основними діями на етапі аналізу є:

• визначення, пояснення, моделювання, специфікація і документування частин і проблем проекту;

• визначення контексту проекту;

• визначення вимог користувача;

• визначення організаційних вимог;

• інші рішення, наприклад, апаратні настройки, настройки ПЗ, фінансові обмеження, обмеження часу і т.п.

Сам аналіз не повинен робити якісь зміни, наприклад, введення таких нових елементів, як комп'ютерні системи. Мета аналізу - ідентифікувати всі аспекти, які можуть вплинути на форму, організацію і результати проекту.

Основними діями в ході аналізу є:

• побудова статичних моделей класів;

• аналіз функцій і випадків застосування;

• перевірка класів і об'єктів;

• розпізнавання і визначення методів і повідомлень;

• моделі станів і діаграми їх змін;

• моделі процесів і діаграми потоків даних;

• управління потоком.

Ключовими чинниками успіху на фазі аналізу є:

• участь представників клієнта;

• повний і загальний підхід, без загострення уваги на деталях;

• розгляд складних аспектів (безпека, масштабованість, оцінка об'єму і т.п.);

• відповідність стандартам;

• перевірка коректності і послідовності;

• прозорість, логічність і послідовність документа.

На фазі аналізу будується логічна модель. Модель відповідатиме детальному і конкретному опису того, як повинна бути побудована система, щоб задовольняти сформульовані вимоги.

Результати цієї фази наступні:

• покращені вимоги, описані в документі;

• словник даних;

• документація моделі, що містить :

  • діаграми класів;

  • діаграми випадків використання;

  • діаграми послідовності повідомлень;

  • діаграми станів;

• визначення класів, атрибутів, відносин, методів і т.д.

• графік етапу дизайну;

  • переднє визначення персоналу і строків.

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

• функції повинні мати унікальні визначені цілі;

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

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

• повинне дотримуватися правило виклику не більше семи функцій;

• описи функцій не повинні відноситися до подробиць реалізації (наприклад, файл, завдання, запис, модуль, робоча станція);

• характеристики якості роботи повинні бути описані, де це можливо (наприклад, швидкість, частота і т.п.);

• слід визначити найважливіші функції;

• імена функцій повинні описувати, що вони роблять, а не як вони це роблять;

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

При створенні аналітичної моделі використовують наступні методології:

1. Структурні методи. Структурні методи комбінують статичний опис процесів і статичні моделі даних.

До цього класу моделей належать наступні підходи:

• методи Yourdon (DeMarco і Ward/Mellon);

• методологія структурного системного аналізу і дизайну (Structured System Analysis and Design Methodology, SSADM);

• техніка структурного аналізу і дизайну (Structured Analysis and Design Technique, SADT).

Згідно з DeMarco, структурний аналіз використовує наступні методи:

• словник баз даних;

• схеми потоків даних;

• структурована англійська мова;

• таблиці вирішень;

• дерева вирішень.

2.Інші методи:

• схема перетворення;

• діаграма зміни станів;

• список подій;

• схема даних;

• перед і пост умови;

• діаграми відносин "сутність-зв'язок";

• історія життя об'єкту.

Недолік використання структурного підходу - труднощі в об'єднанні моделей.

Моделі об'єктів.

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

Для будь-якої мови її синтаксис, семантика і прагматика повинні бути проаналізовані.

Синтаксис - визначає способи ведення запису.

Семантика - визначає значення запису.

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

Документація вимог.

Аналітичну модель слід представляти у формі єдиного повного документа.

Таблиця 6. Форма представлення аналітичної моделі.

План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення

Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії

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 Функціональні вимоги 3.2 Вимоги продуктивності 3.3 Вимоги відношень з зовнішніми програмами 3.4 Вимоги по ресурсам 3.5 Вимоги перевірки 3.6 Вимоги тестування 3.7 Вимоги до документації 3.8 Вимоги до безпечності 3.9 Вимоги переносимості 3.10 Вимоги якості 3.11 Вимоги надійності 3.12 Вимоги підтримки 2.13 Вимоги захисту 4. Доповнення