Лабораторна робота № 2

Тема: Вимоги до програмного забезпечення

Ціль ‒ дати основні поняття про вимоги, пропоновані до програмних систем, і показати різні способи представлення цих вимог.

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

• розуміти відмінності між функціональними і нефункціональними вимогами;

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

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

Короткі теоретичні відомості:

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

Термін вимоги (до програмної системи) може трактуватися по-різному. У деяких випадках під вимогами розуміються високорівневі узагальнені твердження про функціональні можливості і обмеженнях системи. Інша крайня ситуація ‒ деталізований математичний формальний опис системних функцій. Девіс (Davis) так пояснює причини цих відмінностей.

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

Деякі проблеми, що виникають у процесі розробки вимог, породжені відсутністю чіткого розуміння відмінності між цими різними рівнями вимог. Щоб розрізнити вимоги різних рівнів, тут використовуються терміни користувацькі вимоги (user requirements) для позначення високорівневих узагальнених вимог і системні вимоги (system requirements) для деталізованого опису виконуваних системою функцій. Крім вимог цих двох рівнів, застосовується ще більш деталізований опис системи ‒ проектна системна специфікація (software design specification), яка може служити мостом між етапом розробки вимог і етапом проектування системи. Три перераховані види вимог можна визначити в такий спосіб.

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

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

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

Відмінність між користувацькими і системними вимогами показані в прикладі, представленому в табл. 3.1. Тут показано, як користувацькі вимоги можуть бути перетворені в системні.

Таблиця 3.1. Користувацькі і системні вимоги

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

Рис. 3.1. Різні типи специфікацій вимог і їх читачі

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

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

1. Функціональні вимоги. Це перелік сервісів, які повинна виконувати система, причому повинно бути зазначене, як система реагує на ті або інші вхідні дані, як вона поводиться в певних ситуаціях і т.д. У деяких випадках вказується, що система не повинна робити.

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

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

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

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

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

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

1. Користувач повинен мати можливість проводити пошук необхідних йому книг і документів або по всій безлічі доступних каталожних баз даних або за певною їх підмножиною.

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

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

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

Багато проблем, що виникають при розробці систем, пов'язані з неточністю і “розмитістю” специфікації вимог. Звичайно, розробники інтерпретують вимоги, що допускають двояке тлумачення, так, щоб систему було простіше реалізувати. Але це тлумачення може не збігатися з очікуваннями замовника. Така ситуація приводить до розробки нових вимог і внесенню змін у систему. Це, у свою чергу, веде до затримки здачі готової системи і її подорожчанню.

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

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

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

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

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

Разом з тим нефункціональні вимоги можуть відноситись не тільки до самої програмної системи: одні можуть відноситись до технологічного процесу створення ПЗ, інші ‒ містити перелік стандартів якості, що накладаються на процес розробки. Крім того, у специфікації нефункціональних вимог може бути зазначене, що проектування системи повинне виконуватися тільки певними САSЕ-засобами, і наведений опис процесу проектування, якому необхідно випливати.

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

Рис. 3.2. Типи нефункціональних вимог

Усі нефункціональні вимоги, показані на рис. 3.2, можна розбити на три великі групи.

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

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

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

Приклад (3.1) вимог до продукту, організаційних і зовнішніх вимог. Вимоги до продукту зв'язані із середовищем програмування APSE для мови ADA. Це обмежує свободу проектувальника системи у виборі символів ‒ можна використовувати тільки символи з користувацького інтерфейсу APSE. Організаційні вимоги вказують, що система повинна розроблятися згідно із внутрішнім стандартом компанії на розробку ПЗ, що має код XYZCo-SP-STAN-95. Зовнішні вимоги випливають із необхідності дотримання законодавства про збереження конфіденційності. Внаслідок цього системні оператори не будуть мати доступ до тих даних, які їм не потрібні для роботи із системою.

Приклад (3.1.) нефункціональних вимог

Вимоги до продукту

Усі взаємодії між інтерфейсом APSE і користувачем здійснюються на основі стандартної безлічі символів мови ADA.

Організаційні вимоги

Розробка системи і створення супутньої документації виконуються на основі стандарту XYZCo-SP-STAN-95.

Зовнішні вимоги

Система не повинна розкривати конфіденційної інформації про замовника системи, крім його імені, а також телефонного номера системних операторів.

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

Приклад 3.2. Системні цілі і перевірка вимог. Системна мета

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

Нефункціональна вимога, що перевіряється

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

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

На практиці виразити нефункціональні вимоги за допомогою кількісних показників досить важко. Часто замовник ПЗ не може оформити своє бачення майбутньої системи за допомогою вимог, виражених кількісними показниками. Або деякі системні вимоги, наприклад зручність супроводу, взагалі не можна виразити через кількісні показники. Крім того, витрати на об'єктивний вимір кількісних нефункціональних вимог можуть виявитися вкрай високими. Тому часто документ, що специфікує вимоги до системи, містить опис системних цілей разом із чітко сформульованими вимогами. Ці системні цілі корисні, оскільки відображають представлення (і пріоритети) замовника про майбутню систему. Разом з тим замовник повинен розуміти, що його системні цілі можуть трактуватися різними способами і їх неможливо об'єктивно проконтролювати.

Таблиця 3.2. Кількісні показники для нефункціональних вимог

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

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

Вимоги предметної області

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

Як приклад розглянемо вимоги до бібліотечної системи.

1. Стандартний користувацький інтерфейс, що надає доступ до всіх бібліотечних баз даних, повинен ґрунтуватися на стандарті Z39.50.

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

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

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

Приклад 3.3. Приклад вимог предметної області

Гальмування поїзда обчислюється по формулі

D_поїзд = D_{керування} + D_{градієнт}

де D_{градієнт} рівний 9.81 м·с² * компенсуючий градієнт/альфа. Значення 9.81 м·с²/альфа відомо для всіх типів поїздів.

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