5 Вимоги до ПЗ

5. Вимоги до програмного забезпечення

Функціональні і не функціональні вимоги.
Користувацькі вимоги.
Системні вимоги.
Документування системних вимог.

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






5.1. Функціональні і нефункціональні вимоги
Вимоги до програмної системи часто класифікуються як функціональні, нефункціональні і вимоги предметної області.
Функціональні вимоги. Це перелік сервісів, які повинна виконувати система, причому повинно бути вказано, як система реагує на ті або інші вхідні дані, як вона поводиться в певних ситуаціях і т.д. В деяких випадках указується, що система не повинна робити.
Нефункціональні вимоги. Описують характеристики системи і її оточення, а не поведінка системи. Тут також може бути приведений перелік обмежень, що накладаються на дії і функції, виконувані системою. Вони включають тимчасові обмеження, обмеження на процес розробки системи, стандарти і т.д.
Вимоги предметної області. Характеризують ту предметну область, де експлуатуватиметься система. Ці вимоги можуть бути функціональними і нефункціональними.
Насправді чіткої межі між цими типами вимог не існує. Наприклад, призначені для користувача вимоги, що стосуються безпеки системи, можна віднести до нефункціональних. Проте при більш детальному розгляді таку вимогу можна віднести до функціональних, оскільки вона породжує необхідність включення в систему засобу авторизації користувача. Тому, розглядаючи далі ці види вимог, ми повинні завжди пам'ятати, що дана класифікація в значній мірі штучна.
5.1.1. Функціональні вимоги
Ці вимоги описують поведінку системи і сервіси (функції), які вона виконує, і залежать від типу системи, що розробляється, і від потреб користувачів. Якщо функціональні вимоги оформлені як призначені для користувача, вони, як правило, описують системи в узагальненому вигляді. В протилежність цьому функціональні вимоги, оформлені як системні, описують систему максимально детально, включаючи її вхідні і вихідні дані, виключення і т.д.
Функціональні вимоги для програмних систем можуть бути описані різними способами. Розглянемо для прикладу функціональні вимоги до бібліотечної системи університету, призначеної для замовлення книг і документів з інших бібліотек.
Користувач повинен мати нагоду проводити пошук необхідних йому книг н документів або по всій безлічі доступних каталожних баз даних або по певній їх підмножині.
Система повинна надавати користувачу відповідний засіб перегляду бліотечних документів.
Кожне замовлення повинне бути забезпечене унікальним ідентифікатором (ORDERІD), який копіюється у формуляр користувача для постійного зберігання.
Ці функціональні призначені для користувача вимоги визначають властивості, якими винна володіти система. Вони узяті з документа, що містить призначені для користувача вимоги, і показують, що функціональні вимоги можуть бути описані з різним рівнем деталізації (порівняйте першу і третю вимоги).
Багато проблем, що виникають при розробці систем, пов'язано з неточністю і "розмитістю" специфікації вимог. Природно, розробники інтерпретують вимоги, що допускають двояке тлумачення, так, щоб систему було простіше реалізувати. Але це тлумачення може не співпадати з очікуванням замовника. Така ситуація приводить до розробки нових вимог і внесення змін в систему. Це, у свою чергу, веде до затримки здачі готової системи і її дорожчання.
Розглянемо другу вимогу до бібліотечної системи з приведеного вище списку і звернемо увагу на вираз "відповідний засіб перегляду документів". Бібліотечна система може надавати документи в широкому спектрі форматів. У вимозі мається на увазі, що система повинна надати засоби для перегляду документів в будь-якому форматі. Але оскільки ця умова чітко не виписана, розробники у разі дефіциту часу можуть використовувати простий засіб для перегляду текстових документів і наполягати на тому, що саме таке рішення виходить з даної вимоги.
У принципі специфікація функціональних вимог повинна бути комплексною і несуперечливою. Комплексність має на увазі опис (визначення) всіх системних сервісів. Несуперечність означає відсутність несумісних і взаємовиключаючих визначень сервісів. На практиці для великих і складних систем украй важко розробити комплексну і несуперечливу специфікацію функціональних вимог. Причина криється частково в складності системи, що розробляється, а частково – в неузгодженості в опорних точках зору (див. розділ 6) на те, що повинна робити система. Ця неузгодженість може не виявитися на етапі первинного формулювання вимог - для її виявлення необхідний більш глибокий аналіз специфікації. Коли неузгодженість системних функцій виявиться на якому-небудь етапі життєвого циклу програми, в системну специфікацію доведеться внести відповідні зміни.
5.1.2. Нефункціональні вимоги
Як випливає з назви, нефункціональні вимоги не пов'язані безпосередньо з функціями, виконуваними системою. Вони пов'язані з такими інтеграційними властивостями системи, як надійність, час відповіді або розмір системи. Крім того, нефункціональні вимоги можуть визначати обмеження на систему, наприклад на пропускну спроможність пристроїв уведення-виведення, або формати даних, що використовуються в системному інтерфейсі.
Багато нефункціональних вимог відносяться до системи в цілому, а не до окремих її засобів. Це означає, що вони більш значущі і критичні, ніж окремі функціональні вимоги. Помилка, допущена у функціональній вимозі, може понизити якість системи, помилка в нефункціональних вимогах може зробити систему непрацездатною.
Разом з тим нефункціональні вимоги можуть відноситися не тільки до самої програмної системи: одні можуть відноситися до технологічного процесу створення ПЗ, інші - містити перелік стандартів якості, що накладаються на процес розробки. Крім того, в специфікації нефункціональних вимог може бути вказано, що проектування системи повинне виконуватися тільки певними CASE-засобами, і приведено опис процесу проектування, якому необхідно слідувати.
Нефункціональні вимоги відображають призначені для користувача потреби; при цьому вони грунтуються на бюджетних обмеженнях, враховують організаційні можливості компанії-розробника і можливість взаємодії системи, що розробляється, з іншими програмними і обчислювальними системами, а також такі зовнішні чинники, як правила техніки безпеки, законодавство про захист інтелектуальної власності і т.п. На мал. 5.2 показана класифікація нефункціональних вимог.
Всі нефункціональні вимоги, показані на мал. 5.2, розбиті на три великі групи.
Вимоги до продукту. Описують експлуатаційні властивості програмного продукту. Сюди відносяться вимоги до продуктивності системи, об'єму необхідної пам'яті, надійності (визначає частоту можливих збоїв в системі), переносимості системи на різні комп'ютерні платформи і зручності експлуатації.
Організаційні вимоги. Відображають політику і організаційні процедури замовника і розробника ПЗ. Вони включають стандарти розробки програмного продукту, вимоги до реалізації ПЗ (тобто до мови програмування і методів проектування), вихідні вимоги, які визначають терміни виготовлення програмного продукту, і супутню документацію.
Зовнішні вимоги. Враховують чинники, зовнішні по відношенню до системи і процесу її розробки. Вони включають вимоги, що визначають взаємодію даної системи з іншими системами, юридичні вимоги, які гарантують, що система розроблятиметься і функціонуватиме в рамках існуючого законодавства, а також етичні вимоги. Останні повинні гарантувати, що система буде прийнятною для користувачів або замовника.
У врізці 5.1 приведений приклад вимог до продукту, організаційних і зовнішніх вимог. Вимоги до продукту пов'язані з середовищем програмування APSE для мови Ada. Це обмежує свободу проектувальника системи у виборі символів - можна використовувати тільки символи з призначеного для користувача інтерфейсу APSE. Організаційні вимоги указують, що система повинна розроблятися згідно внутрішньому стандарту компанії на розробку ПЗ, що має код XYZCo-SP-STAN-95. Зовнішні вимоги витікають з необхідності дотримання законодавства про збереження конфіденційності. Внаслідок цього системні оператори не матимуть доступу до тих даних, які їм не потрібні для роботи з системою.
Основна проблема нефункціональних вимог полягає в тому, що їх виконання важко перевірити. Часто вони пишуться для того, щоб відобразити загальні цілі замовника системи, такі, як простота експлуатації, можливість відновлення після збоїв або швидка відповідь на запити користувача. Реалізація подібних вимог може виявитися складною для системних розробників, оскільки вони нечітко сформульовані і відкривають простір для різних тлумачень. Подібну ситуацію ілюструє приклад, приведений у врізці 5.2. Тут одним з основних показників (цілей) системи вказана простота експлуатації, що у вигляді нефункціональних вимог можна виразити різними способами. В даному випадку вимога сформульована так, що її можна перевірити.
В ідеалі нефункціональні вимоги повинні виражатися через кількісні показники, які можна об'єктивно зміряти. В табл. 5.2 приведені показники, за допомогою яких можна специфікувати нефункціональні системні властивості.
На практиці виразити нефункціональні вимоги за допомогою кількісних показників важко. Часто замовник ПЗ не може оформити своє бачення майбутньої системи за допомогою вимог, виражених кількісними показниками. Або деякі системні вимоги, наприклад зручність супроводу, взагалі не можна виразити через кількісні показники. Крім того, витрати на об'єктивне вимірювання кількісних нефункціональних вимог можуть виявитися украй високими. Тому часто документ, що специфікує вимоги до системи, містить опис системних цілей спільно з чітко сформульованими вимогами. Ці системні цілі корисні, оскільки відображають уявлення (і пріоритети) замовника про майбутню систему. Разом з тим замовник повинен розуміти, що його системні цілі можуть потрактувати різними способами і їх неможливо об'єктивно проконтролювати.
Таблиця 5.2. Кількісні показники для нефункціональних вимог
Показник
Одиниці вимірювання

Швидкість
Кількість виконаних транзакцій в секунду; час реакції на дії користувача; час оновлення екрану

Розмір
Кілобайти; кількість модулів пам'яті

Простота експлуатації
Час навчання персоналу; кількість статі в довідковій системі

Надійність
Середня тривалість часу між двома послідовними проявами помилок в системі; вірогідність виходу системи з ладу; коефіцієнт готовності системи

Стійкість до збоїв
Час відновлення системи після збою; відсоток подій, що приводять до збоїв; вірогідність псування даних при збоях

Переносимість
Відсоток машинно-залежних операторів; кількість машинно-залежних підсистем


Нефункціональні вимоги часто вступають в конфлікт з іншими вимогами, що пред'являються системі. Наприклад, відповідно до однієї з системних вимог розмір системи не повинен перевищувати 4 Мбайт, оскільки вона повинна повністю поміститися в постійний запам'ятовуючий пристрій обмеженої місткості. Інша вимога зобов'язала використовувати для написання системи мову програмування Ada, яка часто застосовується для створення критичних систем реального часу. Але, припустимо, системна програма, написана на мові Ada, що відкомпілювалася, займає більше 4 Мбайт. Отже, одночасне виконання цих вимог неможливе. В цій ситуації слід відмовитися від одної з вимог. Можна або застосувати іншу мову програмування, або збільшити об'єм пам'яті, що виділяється для системи.
У принципі функціональні і нефункціональні вимоги в документі, що описує вимоги до системи, повинні бути рознесені по різних розділах. Але на практиці цю умову виконати непросто. Якщо нефункціональні вимоги помістити окремо від функціональних, буде важко прослідити взаємозв'язки між ними. Якщо всі вимоги зібрані в одному списку, складно провести аналіз функціональних і нефункціональних вимог окремо і визначити вимоги, що відносяться до системи в цілому. Вид представлення вимог в одному документі також істотно залежить від типу системи, що специфікується. Але у будь-якому випадку повинні бути виділені вимоги, що описують інтеграційні властивості системи. Для цього їх можна помістити в окремий розділ або яким-небудь іншим способом відділити від решти вимог.
5.1.3. Вимоги предметної області
Ці вимоги відображають умови, в яких експлуатуватиметься програмна система. Вони можуть бути подані у вигляді нових функціональних вимог, у вигляді обмежень на вже сформульовані функціональні вимоги або у вигляді вказівок, як система повинна виконувати обчислення. Ці вимоги дуже важливі, оскільки відображають ту предметну область, де використовуватиметься дана система. Невиконання вимог предметної області може привести до виходу системи з ладу.
Як приклад розглянемо вимоги до бібліотечної системи (див. розділ 5.1.1).
Стандартний призначений для користувача інтерфейс, що надає доступ до всіх бібліотечних баз даних, повинен грунтуватися на стандарті Z39.50.
Для забезпечення авторських прав деякі документи повинні бути видалені з системи відразу після отримання. Для цього, залежно від бажання користувача, ці документи можуть бути роздруковані або на локальному системному сервері, або на мережному принтері.
Перша вимога є обмеженням на системну функціональну вимогу. Вона указує, що призначений для користувача інтерфейс до баз даних повинен бути реалізований згідно відповідному бібліотечному стандарту. Друга вимога є зовнішньою і направлена на виконання закону про авторські права, вживаного до бібліотечних матеріалів. З цієї вимоги витікає, що система повинна мати засіб "видалити_на_друк", вживаний автоматично для деяких типів бібліотечних документів.
У врізці 5.3 приведений приклад вимоги предметної області, вказуючої, як повинні виконуватися обчислення. Вона узята із специфікації системи автоматичного гальмування потягу. Ця система повинна автоматично зупиняти потяг на червоний сигнал семафора. Дана вимога указує спосіб обчислення швидкості потягу при гальмуванні. Тут використана термінологія, вживана при розрахунках швидкостей потягу. Щоб розібратися в ній, необхідні відповідні знання про системи управління поїздами і їх характеристиках.
Приведений приклад показує основну проблему, пов'язану з вимогами предметної області. Вимоги цього типу використовують мову і позначення, властиві даній предметній області, що утрудняє їх розуміння розробниками ПЗ. Унаслідок цієї вимоги предметної області не завжди виконуються так, як мається на увазі замовниками програмної системи.
5.2. Призначені для користувача вимоги
Призначені для користувача вимоги до системи повинні описувати функціональні і нефункціональні системні вимоги так, щоб вони були зрозумілі навіть користувачу, що не має спеціальних технічних знань. Ці вимоги повинні визначати тільки зовнішню поведінку системи, уникаючи по можливості визначення структурних характеристик системи. Призначені для користувача вимоги повинні бути написані природною мовою з використанням простих таблиць, а також наочних і зрозумілих діаграм.
Разом з тим при описі вимог на природній мові можуть виникнути різні проблеми.
Відсутність чіткості викладу. Іноді нелегко висловити яку-небудь думку природною мовою чітко і недвозначно, не зробивши при цьому текст багатослівним і важкочитаємим.
Змішення вимог. В призначених для користувача вимогах відсутнє чітке розділення на функціональні і нефункціональні вимоги, на системні цілі і проектну інформацію.
Об'єднання вимог. Декілька різних вимог до системи можуть описуватися як єдина призначена для користувача вимога.
Як ілюстрація до описаних проблем розглянемо вимогу до середовища програмування на мові Ada, представлену у врізці 5.4. Ця вимога містить опис як загального плану, так і деталізованого. З інформації, що міститься в описі загального плану, витікає, що засоби управління конфігурацією є складовою частиною інтерфейсу APSE, тоді як з деталізованого опису витікає, що засоби управління конфігурацією повинні надавати доступ до об'єктів, що входять до складу груп, без вказівки їх повних імен. Цю інформацію краще помістити в специфікацію системних вимог.
В документі, що містить вимоги до системи, бажано відділяти призначені для користувача вимоги від більш деталізованих системних вимог. Інакше непідготовлений читач може "потонути" в технічних подробицях, розуміння яких вимагає певних професійних знань. Приклад змішення різних вимог демонструє врізка 5.5. Вона представляє вимогу до CASE-засобу для редагування схем структур програмних систем. В цій вимозі йдеться про можливість відображення або приховування сітки, що допомагає користувачу точно позиціонувати структурні елементи схеми.

В цій вимозі переплітається не менше трьох різних вимог.
Концептуальна функціональна вимога: система редагування повинна мати в розпорядженні можливість відображення сітки. Це основна причина появи даної вимоги.
Нефункціональна вимога, що дає докладну інформацію про те, в яких одиницях вимірюватиметься крок сітки (сантиметри або дюйми).
Нефункціональна призначена для користувача вимога, що відноситься до інтерфейсу: як користувач може відобразити або приховати сітку.
Описана вимога містить і іншу інформацію, зокрема необхідну для ініціалізації системи. У вимозі сказано, що за умовчанням сітка відключена. Разом з тим нічого не сказано про те, які одиниці вимірювання вибрані за умовчанням. Далі сказано, що користувач може перемикатися між сантиметрами і дюймами, але не сказано, що він може міняти крок сітки.
Коли призначена для користувача вимога містить так багато інформації, це утрудняє його розуміння і обмежує свободу розробника в пошуку рішення задачі, поставленої у вимозі. Призначені для користувача вимоги повинні просто описувати основні можливості системи. У врізці 5.6 показана призначена для користувача вимога, сфокусована увага тільки на самому засобі відображення сітки без деталізації його властивостей.
Зверніть увагу на обгрунтування вимоги. Воно допомагає розробникам зрозуміти, чому ця вимога включена в специфікацію і в якому ступені вона може змінитися в майбутньому. Наприклад, в обгрунтуванні вимоги на засіб відображення сітки сказано, що також може бути корисною активна сітка, де елементи схеми автоматично "прив'язуються" до вузлів сітки. Проте тут перевага свідомо віддана пасивній сітці. Якщо надалі виникне необхідність внести зміни в дану вимогу, то з цього обгрунтування буде видно, що варіант пасивної сітки вибраний навмисно, а не з'явився на етапі реалізації системи.
Наступний приклад вимоги, що також відноситься до системи редагування схеми структури ПЗ, показаний у врізці 5.7. Це специфікація системної функції, що деталізується. В даному випадку вимога включає список дій, які повинен виконати користувач для реалізації даної функції; іноді необхідно записати подібну послідовність дій, оскільки деякі функції повинні виконуватися тільки строго певним способом. Інформація про те, як реалізується дана функція, в цій вимозі відсутня.
Щоб звести до мінімуму неясності при написанні призначених для користувача вимог, рекомендується дотриму-ватися приведених нижче правил.
Розробіть стандартну форму для запису призначених для корис-тувача вимог і неухильно її дотримуйтеся. Стандартна форма запису зменшує неясності у формулюванні вимог і дозволяє легко їх перевірити.
Рекомендується включати у форму запису вимоги не тільки її формулювання, але й її обгрунтовування і посилання на більш деталізовану специфікацію вимог.
Розрізняйте обов'язкові і описові вимоги, як показано у врізці 5.7. Тут обов'язковою вимогою є наявність засобу додавання нових структурних елементів, описовим - опис послідовності дій користувача. Описова вимога не є абсолютно необхідною для реалізації даної призначеної для користувача вимоги і при необхідності може бути змінена.
Використовуйте різні зображення шрифту (напівжирне і курсив) для виділення ключових частин вимоги.
Уникайте по можливості комп'ютерного жаргону. Це не виключає використовування технічних термінів тієї предметної області, для якої розробляється програмне забезпечення.

5.3. Системні вимоги
Системні вимоги – це більш деталізований опис призначених для користувача вимог. Вони звичайно служать основою для укладення контракту на розробку програмної системи і тому повинні надавати максимально повну специфікацію системи в цілому. Системні вимоги також використовуються як відправна крапка на етапі проектування системи.
Специфікація системних вимог може будуватися на основі різних системних моделей, таких, як об'єктна модель або модель потоків даних. Різні моделі, що використовуються при розробці специфікації системних вимог, описані в главі 7.
У принципі системні вимоги визначають, що повинна робити система, не показуючи при цьому механізму її реалізації. Але, з другого боку, для повного опису системи потрібна інформація про неї, яка по можливості повинна включати всю деталізовану інформацію про системну архітектуру. На те існує ряд причин.
Первинна архітектура системи допомагає структурувати специфікацію вимог. Системні вимоги повинні описувати підсистеми, з яких складається система, що розробляється.
Система в більшості випадків повинна взаємодіяти з вже існуючими системами. Це накладає певні обмеження на архітектуру нової системи.
Зовнішньою системною вимогою може виступати умова використання для системи спеціальної архітектури (див. розділ 18).
Специфікації системних вимог часто пишуться природною мовою. Але, як указувалося в розділі 5.2, використовування природної мови може породити певні проблеми при написанні специфікації, оскільки ті, хто пише специфікацію, і ті, хто її читає, одні і ті ж слова і вирази повинні розуміти однаково. Проте насправді це не так, оскільки природній мові властива певна розмитість понять. Внаслідок цього одна і та ж вимога може потрактувати різними людьми по-різному.
Щоб уникнути подібних проблем, розроблені методи опису вимог, які структурують специфікацію і зменшують розмитість визначень. Ці методи представлені в табл. 5.3. Окрім цього, розроблені інші підходи, наприклад спеціальні мови опису вимог, які використовуються відносно рідко. В цьому розділі розглядаються перші два підходи з описаних в табл. 5.3.
Таблиця 5.3. Способи запису специфікацій вимог
Система запису
Опис

Структурована природна мова
Використовування стандартних форм і шаблонів для написання специфікації

Мови опису програм
Використовування спеціальних структурованих мов, подібних мовам програмування, де специфікація вимог будується на основі вибраної операційної моделі системи

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

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


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

Стандартні форми, що використовуються для специфікації функціональних вимог, повинні містити наступну інформацію.
Опис функції або об'єкту.
Опис вхідних даних і їх джерела.
Опис вихідних даних з вказівкою пункту їх призначення.
Вказівка, що необхідно для виконання функції.
Якщо це специфікація функції, необхідний опис попередніх умов (передумов), які повинні виконуватися перед викликом функції, і опис заключної умови (постумови), яка повинна бути виконана після завершення виконання функції.
Опис побічних ефектів (якщо вони є).
Використовування структурованої мови знімає деякі проблеми, властиві специфікаціям, написаною природною мовою, оскільки знижує "варіабельність" специфікації і більш ефективно її структурує. Разом з тим деяка "розмитість" визначень і описів в специфікації залишається. Альтернативою використовуванню структурованої природної мови може служити спеціальна мова опису специфікацій (розглянута в наступному розділі), яка повністю знімає проблему нечіткості опису вимог. Але з другого боку, неспеціаліст знайде таку специфікацію важкою для читання і розуміння.
5.3.2. Створення специфікацій за допомогою PDL
Для зменшення властивої природній мові нечіткості понять при описі системних вимог використовується спеціальна мова опису програм (program description language - PDL). Ця мова подібна таким мовам програмування, як Java і Ada, але більш абстрактна. Перевагою вживання PDL для створення специфікації є те, що в такій специфікації можна перевірити синтаксис і семантику існуючими програмними засобами. Ці перевірки дозволяють видалити помилки і неузгодженість в описі вимог.
Вживання PDL приводить до дуже докладних і деталізуються специфікацій, які іноді просто неможливо ввести в заключний документ з описом системних вимог. Рекомендують використовувати PDL в наступних ситуаціях.
Якщо описувана операція складається з послідовності простих дій і важливий порядок їх виконання. Описати такі послідовності дій на природній мові деколи скрутно, оскільки їх виконання може супроводжуватися вкладеними умовами або вони можуть повторюватися циклічно.
Якщо необхідно специфікувати апаратні або програмні інтерфейси, оскільки практично у всіх специфікаціях системних вимог доводиться описувати інтерфейси.
Якщо читач системної специфікації знайомий з PDL, читання такої специфікації не викличе у нього утруднень. Крім того, якщо PDL побудований на основі якої-небудь мови програмування, легко перетворити специфікацію в системну архітектуру, при цьому можливість невірної інтерпретації вимог зведена до мінімуму.
Разом з тим підхід до побудови специфікацій, заснований на PDL, має свої недоліки.
PDL, що використовується для написання специфікації, може не мати достатніх засобів для опису всіх системних функцій.
Специфікації, створені за допомогою PDL, зрозумілі тільки людям, що мають певні знання мов програмування.
Системна архітектура, одержана на основі такої специфікації, не є системною моделлю, яка допомогла б користувачу розібратися в структурі системи.
Найефективнішим способом розробки специфікацій є поєднання підходу, заснованого на PDL, з використанням структурованої природної мови. В цьому випадку формалізовані записи на природній мові використовуються для опису системи в цілому, а PDL - для опису послідовностей управляючих дій або для опису інтерфейсів, що деталізується.
5.3.3. Специфікація інтерфейсів
Більшість програмних систем, що розробляються, повинні взаємодіяти з іншими, вже існуючими системами. Для того, щоб нова система могла працювати спільно з іншими системами, необхідно специфікувати інтерфейси цих систем.
Такі специфікації створюються на ранньому етапі розробки систем і включаються у вигляді додатку в специфікацію системних вимог.
Розрізняють три типи інтерфейсів, що специфікуються.
Процедурні інтерфейси, коли існуючі підсистеми пропонують набір сервісів, доступних за допомогою інтерфейсної процедури, що викликається.
Структури (інтерфейсні формати) даних, які пересилаються від однієї підсистеми до іншої. В цьому випадку може використовуватися PDL, заснований на мові програмування Java, яка дозволяє описати класи даних з відповідними полями, що формують структуру даних. Проте для опису цього типу інтерфейсу найбільш підходять діаграми "сутність-зв'язок", описані в главі 7.
Спеціальні представлення даних, наприклад у вигляді впорядкованої послідовності двійкових розрядів. Мова Java не підтримує такі детальні описи даних, тому не рекомендують в цьому випадку використовувати PDL, заснований на мові Java.
Формальні нотації, приведені в главі 9, дозволяють описати інтерфейси чітко і недвозначно. Проте такі специфікації зрозумілі тільки фахівцям, що володіють певними знаннями. Формальні нотації рідко використовуються на практиці, хоча, вони ідеально підходять для створення специфікацій інтерфейсів. Менш формальні специфікації інтерфейсів, одержані за допомогою PDL, є компромісом між зрозумілістю і точністю опису інтерфейсів.

5.4. Документування системних вимог
Документ, що містить вимоги, також званий специфікацією системних вимог, - це офіційне розпорядження для розробників програмної системи. Він містить призначені для користувача вимоги і деталізований опис системних вимог. В деяких випадках призначені для користувача і системні вимоги можуть не розрізнятися, виступаючи спільно у вигляді однорідного опису системи. В інших випадках призначені для користувача вимоги приводяться у введенні документа-специфікації. Якщо загальна кількість вимог велика, деталізовані системні вимоги можуть бути представлені у вигляді окремого документа.
Системну специфікацію читає безліч різних людей, починаючи від вищого керівництва компанії - замовника системи і закінчуючи рядовим розробником системи. На мал. 5.3 показані категорії читачів специфікації.
Хенінгер сформулював шість умов, яким повинна відповідати специфікація програмної системи.
Описувати тільки зовнішню поведінку системи.
Указувати обмеження, що накладаються на процес реалізації системи.
Передбачати можливість внесення змін в специфікацію.
Служити довідковим засобом в процесі супроводу системи.
Відображати весь життєвий цикл системи.
Передбачати реакцію системи і групи супроводу на непередбачені (нештатні) ситуації.
Хоча з часу написання цих умов пройшло більше 20 років, вони не втратили своєї актуальності і є хорошою підмогою при розробці специфікацій. Разом з тим часом складно або навіть неможливо описати систему тільки в термінах зовнішньої поведінки, тобто тільки за допомогою функцій, які вона повинна виконувати, оскільки в специфікації також повинні бути відображені обмеження, що накладаються оточенням вже існуючих систем.
Інша умова - обхват всього життєвого циклу системи - приймається всіма розробниками, але рідко виконується на практиці.
Багато організацій, такі, як Міністерство оборони США і Інститут інженерів по електротехніці і радіоелектроніці IEEE, розробили власні стандарти документування специфікацій. Найвідоміший стандарт розроблений IEEE і називається IEEE/ANSI 830-1993. Даний стандарт припускає наступну структуру специфікації.
1. Введення
Цілі документа
Призначення програмного продукту
Визначення і абревіатури
Список літератури і інших джерел
Огляд специфікації
2. Загальний опис
Опис програмного продукту
Функції програмного продукту
Призначені для користувача характеристики
Загальні обмеження
Обгрунтовування, припущення і допущення
3. Специфікація вимог охоплює функціональні, нефункціональні і інтерфейсні вимоги. Це найзначуща частина документа, але унаслідок украй широкого діапазону можливих вимог, що пред'являються програмним системам, в стандарті не визначена структура цього розділу. Тут можуть бути документовані зовнішні інтерфейси, описані функціональні можливості системи, приведені вимоги, що визначають логічну структуру баз даних, обмеження, що накладаються на структуру системи, описані інтеграційні властивості системи або її якісні характеристики.
Додатки
Покажчики
Хоча стандарт IEEE не ідеальний, він може служити відправною крапкою при написанні специфікації. Звичайно, при її написанні необхідно також враховувати стандарти, прийняті в організації - розробнику ПЗ. В табл. 5.4 описані можливі розділи специфікації, побудованої на підставі стандарту IEEE.
Таблиця 5.4. Структура специфікації вимог
Розділ
Опис

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

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

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

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

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

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

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

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

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

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


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

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










13PAGE 15


13PAGE 141015



Врізка 5.1. Приклад нефункціональних вимог
Вимоги до продукту
Всі взаємодії між інтерфейсом APSE і користувачем здійснюються на основі стандартної множини символів мови Ada.
Організаційні вимоги
Розробка системи і створення супутньої документації виконуються на основі стандарту XYZCo-SP-STAN-95.
Зовнішні вимоги
Система не повинна розкривати конфиденціальну інформацію про замовника, крім його імені, а також телефонного номера системних операторів

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

Врізка 5.4. Вимога до бази даних для середовища програмування Ada
База даних повинна підтримувати генерацію і управління конфігурацією об'єктів; в базі даних згруповані об'єкти можуть виступати у вигляді окремих об'єктів. Засіб управління конфігурацією повинен надати можливість доступу до об'єктів, що входять до складу груп, за допомогою їх неповних імен.

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

Врізка 5.6. Опис засобу відображення сітки
2.6. Засіб відображення сітки
2.6.1. Редактор, повинен мати засіб виводу на екран сітки, яка складається з паралельних горизонтальних і вертикальних ліній і повинна відображатися у вигляді фону на екрані редактора. Сітка - пасивний елемент, що полегшує вирівнювання користувачем структурних елементів схем.
Обгрунтування. Сітка повинна допомогти користувачеві створити акуратну схему з правильно розміщеними елементами. Хоча активна сітка (така, в якій елементи «прив’язуються» до вузлів сітки) також може бути корисною, вона не забезпечує точного позиціонування елементів. Користувач визначить положення елементів схеми краще, ніж це зробить автоматизований засіб.

Врізка 5.7. Користувацька вимога по створенню структурних елементів схеми
3.5 1. Додавання структурних елементів в схему
3.5.1.1. Редактор повинен мати засіб надання користувачеві можливості додавати в схему нові структурні елементи вибраного типу.
3.5.1.2. Послідовність дій користувача для додавання в схему нового структурного елемента
1. Користувач вибирає тип елемента, що додається.
2. Користувач поміщує курсор в потрібну позицію на схемі і вказує символ, яким буде відображатися новий елемент.
3. Користувач переміщає символ елемента в кінцеву позицію.
Обгрунтовування. Такий підхід до реалізації додавання нових структурних елементів надає користувачеві безпосередній контроль над вибором типу елемента і його позиціонуванням на схемі.

Врізка 5.8. Специфікація системної вимоги, що використовує стандартну форму
Функція. Додавання структурних елементів в схему
Опис. Додавання структурних елементів в існуючу схему системної архітектури. Користувач вибирає тип структурного елемента і його місцеположення. Після вставки в схему структурний елемент стає виділеним (поточним структурним елементом). Користувач визначає місцеположення елемента шляхом переміщення курсора по області схеми.
Вхідні дані. Тип елемента, позиція елемента, ідентифікатор схеми.
Джерела вхідних даних. Тип елемента і позиція елемента задаються користувачем, ідентифікатор схеми отримано з бази даних проекту.
Вихідні дані. Ідентифікатор схеми.
Пункт призначення. База даних проекту. Ідентифікатор схеми поміщається в базу даних проекту після завершення виконання даної функції.
Для виконання функції потрібна схема, визначена вхідним ідентифікатором схеми.
Передумова. Схема відкрита і відображається на екрані користувача.
Постумова. Схема, за винятком вставки нового структурного елемента, не змінюється.
Побічні ефекти. Ні.



15

Приложенные файлы

  • doc 25367924
    Размер файла: 248 kB Загрузок: 0

Добавить комментарий