Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Загальні вимоги до ПЗ. Керування вимогами
Інформація про навчальний заклад
ВУЗ:
Національний авіаційний університет
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2002
Тип роботи:
Лекція
Предмет:
Інженерія програмного забеспечення
Частина тексту файла (без зображень, графіків і формул):
Дисципліна: Інженерія програмного забезпечення
Модуль №1 " Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем "
Лекція 2
Тема: Загальні вимоги до ПЗ. Керування вимогами
Зміст
1. Вступ. Загальна уява про вимоги. Типи вимог
2. Системні вимоги. Документування системних вимог
3. Аналіз реалізує мості. Формування й аналіз вимог. Атестація і огляд вимог.
4. Керування вимогами.
5. Контрольні питання
Література
1. Соммервил И. Инженерия программного обеспечения. – М.: И.Д. «Вильямс», 2002. – 624 с.
Бабенко Л.П. Основи програмної інженерії. – К.: Т-во «Знання», КОО, 2001. – 269 с.
Вступ
Проблеми, які доводиться вирішувати фахівцям у процесі створення програмного забезпечення, звичайно дуже складні. Природа цих проблем не завжди ясна, особливо якщо розроблювальна програмна система інноваційна. Зокрема, важко чітко описати ті дії, які повинна виконувати система. Опис функціональних можливостей і обмежень, що накладаються на програмну систему, називається вимогами до цієї системи, а сам процес формування, аналізу, документування й перевірки цих функціональних можливостей і обмежень — розробкою вимог (requirement engineering). Увага концентрується на самих вимогах і способах їхнього опису. Процес розробки вимог загалом описаний у главі 3, а більш докладно освітлений у наступній главі.
Термін вимоги (до програмної системи) може трактуватися по-різному. У деяких випадках під вимогами розуміються високорівневі узагальнені твердження про функціональні можливості й обмеження системи. Інша крайня ситуація - деталізований математичний формальний опис системних функцій. Девіс (Davis) [89] так пояснює причини цих розходжень.
Якщо компанія хоче виграти контракт на розробку великого програмного проекту, вона змушена, поки рішення не прийняте, представляти вимоги в самому узагальненому виді, щоб, з одного боку, задовольнити вимоги замовника, а з іншого боку - мати можливість для маневру при конкуренції з іншими компаніями-розроблювачами. Після того як контракт виграний, компанія повинна представити замовникові більше докладний опис системи із вказівкою всіх виконуваних нею функцій. В обох ситуаціях надаються документи, які називаються документованими вимогами до системи.
Деякі проблеми, що виникають у процесі розробки вимог, породжені відсутністю чіткого розуміння розходження між цими різними рівнями вимог. Щоб розрізнити вимоги різних рівнів, тут використовуються терміни користувальницькі вимоги (user requirement) для позначення високорівневих узагальнених вимог і системні вимоги (system requirement) для деталізованого опису виконуваних системою функцій. Крім вимог цих двох рівнів, застосовується ще більш деталізований опис системи — проектна системна специфікація (software design specification), що може служити мостом між етапом розробки вимог і етапом проектування системи. Три перерахованих види вимог можна визначити в такий спосіб.
Користувальницькі вимоги — опис природною мовою функцій (плюс пояснювальні діаграми), виконуваних системою, і обмежень, що накладаються на неї.
Системні вимоги — деталізований опис системних функцій і обмежень, що іноді називають функціональною специфікацією. Вона є основою для висновку контракту між покупцем системи й розроблювачами ПО.
Проектна системна специфікація — узагальнений опис структури програмної системи, що буде основою для більше деталізованого проектування системи й наступної реалізації. Ця специфікація доповнює й деталізує специфікацію системних вимог.
Розходження між користувальницькими й системними вимогами показані в прикладі, представленому в табл. 5.1. Тут показано, як користувальницькі вимоги можуть бути перетворені в системні.
Таблиця 5.1. Користувальницькі й системні вимоги
Користувальницькі вимоги
1. ПЗ повинне надати засіб доступу до зовнішніх файлів, створеним в інших програмах.
Специфікація системних вимог
1.1. Користувач повинен мати можливість визначати тип зовнішніх файлів.
1.2. Для кожного типу зовнішнього файлу повинне бути відповідний засіб, застосовний до цього типу файлів.
1.3. Зовнішній файл кожного типу повинен бути представлений відповідною піктограмою на дисплеї користувача.
1.4. Користувачеві повинна бути надана, можливість самому визначати піктограму для кожного типу зовнішніх файлів.
1.5. При виборі користувачем піктограми, що являє зовнішній файл, до цього файлу повинне бути застосоване засіб, асоційований із зовнішніми файлами даного типу.
Користувальницькі вимоги пишуться для замовника ПЗ й для особи, що містить контракт на розробку програмної системи, причому вони можуть не мати детальних технічних знань по розроблювальній системі (мал. 5.1). Специфікація системних вимог призначена для керівного технічного состава компанії-розроблювача й для менеджерів проекту. Вона також необхідна замовникові ПЗ й субпідрядниках по розробці. Ці обидва документи також призначені для кінцевих користувачів програмної системи. Нарешті, проектна системна специфікація є документом, що орієнтований на розроблювачів ПЗ.
Рис. 5.1. Різні типи специфікацій вимог і їхніх читачів
2. Функціональні й нефункціональні вимоги
Вимоги до програмної системи часто класифікуються як функціональної, нефункціональні й вимоги предметної області.
Функціональні вимоги. Це перелік сервісів, які повинна виконувати система, причому повинне бути зазначене, як система реагує на ті або інші вхідні дані, як вона поводиться в певних ситуаціях і т.д. У деяких випадках вказується, що система не повинна робити.
Нефункціональні вимоги. Описують характеристики системи і її оточення, а не поводження системи. Тут також може бути наведений перелік обмежень, що накладаються на дії й функції, виконувані системою. Вони включають тимчасові обмеження, обмеження на процес розробки системи, стандарти й т.д.
Вимоги предметної області. Характеризують ту предметну область, де буде експлуатуватися система. Ці вимоги можуть бути функціональними й нефункціональними.
У дійсності чіткої границі між цими типами вимог не існує. Наприклад, користувальницькі вимоги, що стосуються безпеки системи, можна віднести до нефункціонального. Однак при більше детальному розгляді така вимога можна віднести до функціональних, оскільки воно породжує необхідність включення в систему засобу авторизації користувача. Тому, розглядаючи далі ці види вимог, ми повинні завжди пам'ятати, що дана класифікація в значній мірі штучна.
2.1.1. Функціональні вимоги
Ці вимоги описують поводження системи й сервіси (функції), які вона виконує, і залежать від типу розроблювальної системи й від потреб користувачів. Якщо функціональні вимоги оформлені як користувальницькі, вони, як правило, описують системи в узагальненому виді. На противагу цьому функціональні вимоги, оформлені як системні, описують систему максимально докладно, включаючи її вхідного й вихідного дані, виключення й т.д.
Функціональні вимоги для програмних систем можуть бути описані різними способами. Розглянемо для приклада функціональні вимоги до бібліотечної системи університету, призначеної для замовлення книг і документів з інших бібліотек [204].
Користувач повинен мати можливість проводити пошук необхідних йому книг та документів або по всій безлічі доступних каталожних баз даних або по певній їхній підмножині.
Система повинна надавати користувачеві підходящий засіб перегляду бібліотечних документів.
Кожне замовлення повинно бути супроводжуватися унікальним ідентифікатором (ORDER_ID), що копіюється у формуляр користувача для постійного зберігання.
Ці функціональні користувальницькі вимоги визначають властивості, який повинна володіти система. Вони взяті з документа, що містить користувальницькі вимоги, і показують, що функціональні вимоги можуть бути описані з різним рівнем деталізації (зрівняєте перше й третє вимоги).
Багато проблем, що виникають при розробці систем, пов'язані з неточністю й "розмитістю" специфікації вимог. Природно, розроблювачі інтерпретують вимоги, що допускають двояке тлумачення, так, щоб систему було простіше реалізувати. Але це тлумачення може не збігатися з очікуваннями замовника. Така ситуація приводить до розробки нових вимог і внесенню змін у систему. Це, у свою чергу, веде до затримки здачі готової системи і її подорожчанню.
Розглянемо другу вимогу до бібліотечної системи з наведеного вище списку й оборотна увага на вираження "підходящий засіб перегляду документів". Бібліотечна система може надавати документи в широкому спектрі форматів. У вимозі мається на увазі, що система повинна надати засоби для перегляду документів у будь-якому форматі. Але оскільки ця умова чітко не виписана, розроблювачі у випадку дефіциту часу можуть використовувати простий засіб для перегляду текстових документів і наполягати на тому, що саме таке рішення треба з даної вимоги.
У принципі специфікація функціональних вимог повинна бути комплексної й несуперечливої. Комплексність має на увазі опис (визначення) всіх системних сервісів. Несуперечність означає відсутність несумісних і взаємовиключних визначень сервісів. На практиці для більших і складних систем украй важко розробити комплексну й несуперечливу специфікацію функціональних вимог. Причина криється частково в складності самої розроблювальної системи, а частково - у неузгоджених опорних точках зору (див. главу6) на те, що повинна робити система. Ця непогодженість може не виявитися на етапі первісного формулювання вимог - для її виявлення необхідний більше глибокий аналіз специфікації. Коли непогодженість системних функцій виявиться на якому-небудь етапі життєвого циклу програми, у системну специфікацію прийде внести відповідні зміни.
2.1.2 Нефункціональні вимоги
Як виходить з назви, нефункціональні вимоги не зв'язані безпосередньо з функціями, виконуваними системою. Вони пов'язані з такими інтеграційними властивостями системи, як надійність, час відповіді або розмір системи. Крім того, нефункціональні вимоги можуть визначати обмеження на систему, наприклад на пропускну здатність пристроїв уведення-виводу, або формати даних, використовуваних у системному інтерфейсі.
Багато нефункціональних вимог ставляться до системи в цілому, а не до окремих її засобів. Це означає, що вони більше значимі й критичні, чим окремі функціональні вимоги. Помилка, допущена у функціональній вимозі, може знизити якість системи, помилка в нефункціональних вимогах може зробити систему непрацездатної.
Разом з тим нефункціональні вимоги можуть ставитися не тільки до самої програмної системи: одні можуть ставитися до технологічного процесу створення ПО, інші - містити перелік стандартів якості, що накладаються на процес розробки. Крім того, у специфікації нефункціональних вимог може бути зазначено, що проектування системи повинне виконуватися тільки певними САSЕ - засобами, і наведений опис процесу проектування, якому необхідно випливати.
Нефункціональні вимоги відображають користувальницькі потреби; при цьому вони ґрунтуються на бюджетних обмеженнях, ураховують організаційні можливості компанії-розроблювача й можливість взаємодії розроблювальної системи з іншими програмними й обчислювальними системами, а також такі зовнішні фактори, як правила техніки безпеки, законодавство про захист інтелектуальної власності й т.п. На рис. 2.2 показана класифікація нефункціональних вимог.
Всі нефункціональні вимоги, показані на мал. 5.2, я розбив на три більші групи.
Вимоги до продукту. Описують експлуатаційні властивості програмного продукту. Сюди ставляться вимоги до продуктивності системи, обсягу необхідної пам'яті, надійності (визначає частоту можливих збоїв у системі), переносимости системи на різні комп'ютерні платформи й зручності експлуатації.
Організаційні вимоги. Відображають політику й організаційні процедури замовника й розроблювача ПО. Вони включають стандарти розробки програмного продукту, вимоги до реалізації ПО (тобто до мови програмування й методам проектування), вихідні вимоги, які визначають строки виготовлення програмного продукту, і супутню документацію.
Рис.5.2. Типи нефункціональних вимозі
Зовнішні вимоги. Ураховують фактори, зовнішні стосовно розроблювальної системи й процесу її розробки. Вони включають вимоги, що визначають взаємодію даної системи з іншими системами, юридичні вимоги, проходження яким гарантує, що система буде розроблятися й функціонувати в рамках існуючого законодавства, а також етичні вимоги. Останні повинні гарантувати, що система буде прийнятної для користувачів або замовника.
У вставки 1 наведений приклад вимог до продукту, організаційних і зовнішніх вимог. Вимоги до продукту зв'язані із середовищем програмування АРSЕ для мови Аdа. Це обмежує волю проектувальника системи у виборі символів - можна використовувати тільки символи з користувальницького інтерфейсу АРSЕ. Організаційні вимоги вказують, що система повинна розроблятися відповідно до внутрішнього стандарту компанії на розробку ПО, що має код Sр-Sта-95. Зовнішні вимоги випливають із необхідності дотримання законодавства про збереження конфіденційності. Внаслідок цього системні оператори не будуть мати доступ до тих даним, які їм не потрібні для роботи із системою.
Вимоги до продукту
4.С.8. Всі взаємодії між інтерфейсом APSE і користувачем здійснюються на основі стандартної множині символів мови Ada.
Організаційні вимоги.
Розробка системи й створення супутньої документації виконуються на основі стандартів в галузі.
Зовнішні вимоги
7.6.5. Система не повинна розкривати конфіденційної інформації про замовника системи, крім його імені, а також телефонного номера системного оператора.
Основна проблема нефункціональних вимог полягає в тому, що їхнє виконання важко перевірити. Часто вони пишуться для того, щоб відобразити загальні цілі замовника системи, такі, як простота експлуатації, можливість відновлення після збоїв або швидка відповідь на запити користувача. Реалізація подібних вимог може виявитися складної для системних розроблювачів, оскільки вони нечітко сформульовані й відкривають простір для різних тлумачень. Подібну ситуацію ілюструє приклад, наведений в урізанні 5.2. Тут одним з основних показників (цілей) системи зазначена простота експлуатації, що у вигляді нефункціональних вимог можна виразити різними способами. У цьому випадку вимога сформульована так, що його можна перевірити.
Системна мета
Система повинна бути простою в експлуатації для досвідченого оператора й кількість його помилок зводити до мінімуму.
Нефункціональна вимога, що перевіряється
Досвідченому операторові повинні бути доступні всі системні функції після двох годин навчання роботі з даною системою. Після такого навчання середнє число помилок оператора не повинне перевищувати двох за робочий день.
В ідеалі нефункціональні вимоги повинні виражатися через кількісні показники, які можна об'єктивно виміряти. У табл. 5.2 наведені показники, за допомогою яких можна специфікувати нефункціональні системні властивості.
На практиці виразити нефункціональні вимоги за допомогою кількісних показників досить важко. Часто замовник ПО не може оформити своє бачення майбутньої системи за допомогою вимог, виражених кількісними показниками. Або деякі системні вимоги, наприклад зручність супроводу, взагалі не можна виразити через кількісні показники. Крім того, витрати на об'єктивний вимір кількісних нефункціональних вимог можуть виявитися вкрай високими. Тому часто документ, що специфікує вимоги до системи, містить опис системних цілей разом із чітко сформульованими вимогами. Ці системні цілі корисні, оскільки відбивають подання (і пріоритети) замовника про майбутню систему. Разом з тим замовник повинен розуміти, що його системні цілі можуть трактуватися різними способами і їх неможливо об'єктивно проконтролювати.
Таблиця 5.2. Кількісні показники для нефункціональних вимог
Показник
Одиниці виміру
Швидкість
Кількість виконаних транзакцій у секунду;
час реакції на дії користувача;
час відновлення екрана
Розмір
Кілобайти;
кількість модулів пам'яті
Простота експлуатації
Час навчання персоналу;
кількість статей у довідковій системі
Надійність
Середня тривалість часу між двома послідовними проявами помилок у системі;
імовірність виходу системи з ладу;
коефіцієнт готовності системи
Стійкість до збоїв
Час відновлення системи після збою;
відсоток подій, що приводять до збоїв;
імовірність псування даних при збоях
Сумісність
Відсоток машинно-залежних операторів;
кількість машинно-залежних підсистем
Нефункціональні вимоги часто вступають у конфлікт із іншими вимогами, пропонованими системі.
У принципі функціональні й нефункціональні вимоги в документі, що описує вимоги до системи, повинні бути рознесені по різних розділах. Але на практиці ця умова виконати непросто. Якщо нефункціональні вимоги помістити окремо від функціональних, буде важко простежити взаємозв'язки між ними. Якщо всі вимоги зібрані в одному списку, складно провести аналіз функціональних і нефункціональних вимог окремо й визначити вимоги, що ставляться до системи в цілому. Вид подання вимог в одному документі також істотно залежить від типу специфікуємої системи. Але в кожному разі повинні бути виділені вимоги, що описують інтеграційні властивості системи. Для цього їх можна помістити в окремий розділ або який-небудь інший спосіб відокремити від інших вимог.
5.1.3. Вимоги предметної області
Ці вимоги відображають умови, у яких буде експлуатуватися програмна система. Вони можуть бути представлені у вигляді нових функціональних вимог, у вигляді обмежень на вже сформульовані функціональні вимоги або у вигляді вказівок, як система повинна виконувати обчислення. Ці вимоги дуже важливі, оскільки відображають ту предметну область, де буде використовуватися дана система. Невиконання вимог предметної області може привести до виходу системи з ладу.
Як приклад розглянемо вимоги до бібліотечної системи (див. розділ 5.1.1).
Стандартний користувальницький інтерфейс, що надає доступ до всіх бібліотечних баз даних, повинен ґрунтуватися на стандарті 239.50.
Для забезпечення авторських прав деякі документи повинні бути вилучені із системи відразу після одержання. Для цього, залежно від бажання користувача, ці документи можуть бути роздруковані або на локальному системному сервері, або на мережному принтері.
Перша вимога є обмеженням на системну функціональну вимогу. Воно вказує, що користувальницький інтерфейс до баз даних повинен бути реалізований відповідно до відповідного бібліотечного стандарту. Друга вимога є зовнішнім і спрямовано на виконання закону про авторські права, застосовуваного до бібліотечних матеріалів. Із цієї вимоги випливає, що система повинна мати засіб "видати_на_печатку” застосовуване автоматично для деяких типів бібліотечних документів.
Основна проблема, пов'язана з вимогами предметної області. Вимоги цього типу використовують мову й позначення, властиві даної предметної області, що утрудняє їхнє розуміння розроблювачами ПО. Внаслідок цієї вимоги предметної області не завжди виконуються так, як мається на увазі замовниками програмної системи.
5.2. Користувальницькі вимоги
Користувальницькі вимоги до системи повинні описувати функціональні й нефункціональні системні вимоги так, щоб вони були зрозумілі навіть користувачеві, що не має спеціальних технічних знань. Ці вимоги повинні визначати тільки зовнішнє поводження системи, уникаючи по можливості визначення структурних характеристик системи. Користувальницькі вимоги повинні бути написані природною мовою з використанням простих таблиць, а також наочних і зрозумілих діаграм.
Разом з тим при описі вимог природною мовою можуть виникнути різні проблеми.
Відсутність - чіткості викладу. Іноді нелегко викласти яку-небудь думку природною мовою чітко й недвозначно, не зробивши при цьому текст багатослівним і трудночитаемым.
Змішання вимог. У користувальницьких вимогах відсутнє чіткий поділ на функціональні й нефункціональні вимоги, на системні цілі н проектну інформацію.
Об'єднання вимог. Кілька різних вимог до системи можуть описуватися як єдина користувальницька вимога.
Як ілюстрація до описаних проблем розглянемо вимогу до середовища програмування мовою Аdа, представлене в урізанні 5.4. Ця вимога містить опис як загального плану, так і деталізоване. З інформації, що втримується в описі загального плану, треба, що засобу керування конфігурацією є складовою частиною інтерфейсу АРSЕ, у той час як з більше деталізованого опису випливає, що засобу керування конфігурацією повинні надавати доступ до об'єктів, що входять до складу груп, без вказівки їхніх повних імен. Цю інформацію краще помістити в специфікацію системних вимог.
Вставка 5.4. Вимога до бази даних для середовища програмування
4.А.5. База даних повинна підтримувати генерацію й керування конфігурацією об'єктів; у базі даних згруповані об'єкти можуть виступати у вигляді окремих об'єктів. Засіб керування конфігурацією повинне надати можливість доступу до об'єктів, що входять до складу груп, за допомогою їхніх неповних імен.
У документі, що містить вимоги до системи, бажано відокремлювати користувальницькі вимоги від більше деталізованих системних вимог. Інакше непідготовлений читач користувальницьких вимог може "потонути" у технічних подробицях, розуміння яких вимагає певних професійних знань. Приклад змішання різних вимог демонструє вставка 5.5. Він представляє вимогу до САSЕ-засобу для редагування схем структур програмних систем. У цій вимозі мова йде про можливість відображення або - приховання сітки, що допомагає користувачеві точно позиціонувати структурні елементи схеми.
Вставка 5.5. Приклад користувальницької вимоги.
2.6. Створення елементів позиціонування. Для точного позиціонування структурних елементів схеми користувач може відобразити на екрані сітку, параметри якої можуть задаватися (у сантиметрах або дюймах) за допомогою спеціальної опції на панелі керування. За замовчуванням сітка не відображається. Сітка може бути виведена на екран або схована в будь-який момент сесії редагування, також у будь-який момент є можливість переходу із сантиметрів на дюйми й назад. Крок сітки повинен підганятися під розмір схеми.
У цій вимозі переплітається не менш трьох різних вимог.
Концептуальна функціональна вимога: система редагування повинна мати у своєму розпорядженні можливість відображення сітки. Це основна причина появи даної вимоги.
Нефункціональна вимога, що дає докладну інформацію про те, у яких одиницях буде вимірятися крок сітки (сантиметри або дюйми).
Нефункціональна користувальницька вимога, що ставиться до інтерфейсу: як користувач може відобразити або сховати сітку.
Описана вимога містить і іншу інформацію, зокрема необхідну для ініціалізації системи. У вимозі сказано, що за замовчуванням сітка відключена. Разом з тим нічого не сказано про те, які одиниці виміру обрані за замовчуванням. Далі сказано, що користувач може перемикатися між сантиметрами й дюймами, але не сказано, що він може міняти крок сітки.
Коли користувальницька вимога містить так багато інформації, це утрудняє його розуміння й обмежує волю розроблювача в пошуку рішення завдання, поставленої у користувальницьких вимогах повинні просто описувати основні можливості системи. В вставці 5.6 показане переписане мною користувальницька вимога, де я сфокусував увагу тільки на самому засобі відображення сітки без деталізації його властивостей.
Вставка 5.6. Опис засобу відображення сітки ;
2.6. Засіб відображення сіткою
2.6.1. Редактор повинен мати засіб виводу на екран сітки, що складається з паралельних горизонтальних і вертикальних ліній і повинна відображатися у вигляді тла на екрані редактора. Сітка - паcивний елемент, що полегшує вирівнювання користувачем структур елементів схем.
Обґрунтування. Сітка повинна допомогти користувачеві створити акуратну схему із правильно розміщеними елементами. Хоча активна сітка (така, у якій елементи "прив’язуються" до вузлів сітки) також може бути корисної, вона не забезпечує точного позиціонування елементів. Користувач, визначить положення елементів схеми краще, ніж це робить автоматизований засіб.
Зверніть увагу на обґрунтування вимоги. Воно допомагає розроблювачам зрозуміти, чому ця вимога включена в специфікацію й у якому ступені воно може змінитися в майбутньому. Наприклад, в обґрунтуванні вимоги на засіб відображення сітки сказано, що також може бути корисної активна сітка, де елементи схеми автоматично "прив’язуються" до вузлів сітки. Однак тут перевага свідомо віддана пасивній сітці. Якщо надалі виникне необхідність внести зміни в дану вимогу, то із цього обґрунтування буде видно, що варіант пасивної сітки обраний навмисно, а не з'явився на етапі реалізації системи.
Наступний приклад вимоги, що також ставиться до системи редагування схеми структури ПО, показаний в урізанні 5.7. Це деталізована специфікація системної функції. У цьому випадку вимога включає список дій, які повинен виконати користувач для реалізації даної функції; іноді необхідно записати подібну послідовність дій, оскільки деякі функції повинні виконуватися тільки строго певним способом. Інформація про те, як реалізується дана функція, у цій вимозі відсутній.
Щоб звести до мінімуму неясності при написанні користувальницьких вимог, я рекомендую дотримуватися наведених нижче правил.
Розробіть стандартну форму для запису користувальницьких вимог і неухильно її дотримуйтеся. Стандартна форма запису зменшує неясності у формулюванні вимог і дозволяє легко їх перевірити. Я рекомендую включати у форму запису вимоги не тільки саме його формулювання, але його обґрунтування й посилання на більше деталізовану специфікацію вимог.
Робіть розходження між обов'язковими й описовими вимогами, як показано в урізанні 5.7. Тут обов'язковою вимогою є наявність засобу додавання нових структурних елементів, описовим - опис послідовності дій користувача. Описова вимога не є абсолютно необхідним для реалізації даної користувальницької вимоги й при необхідності може бути змінено.
Використовуйте різні накреслення шрифту (напівжирне й курсив) для виділення ключових частин вимоги.
Уникайте по можливості комп'ютерного жаргону. Це не виключає використання технічних термінів тої предметної області, для якої розробляється програмне забезпечення.
5.3. Системні вимоги
Системні вимоги - це більше деталізований опис користувальницьких вимог. Вони звичайно є основою для висновку контракту на розробку програмної системи й тому повинні представляти максимально повну специфікацію системи в цілому. Системні вимоги також використовуються як відправна крапка на етапі проектування системи.
Специфікація системних вимог може будуватися на основі різних системних моделей, таких, як об'єктна модель або модель потоків даних. Різні моделі, використовувані при розробці специфікації системних вимог, описані в главі 7.
У принципі системні вимоги визначають, що повинна робити система, не показуючи при цьому механізму її реалізації. Але, з іншого боку, для повного опису системи потрібна деталізована інформація про неї, що по можливості повинна включати всю інформацію про системну архітектуру. На те існує ряд причин.
Первісна архітектура системи допомагає структурувати специфікацію вимог. Системні вимоги повинні описувати підсистеми, з яких складається розроблювальна система.
У більшості випадків розроблювальна система повинна взаємодіяти із уже існуючими системами. Це накладає певні обмеження на архітектуру нової системи.
У якості зовнішньої системної вимоги може виступати умова використання для розроблювальної системи спеціальної архітектури.
Специфікації системних вимог часто пишуться природною мовою. Але, як вказувалося в розділі 5.2, використання природної мови може породити певні проблеми при написанні деталізованої специфікації. Застосування природної мови має на увазі, що ті, хто пише специфікацію, і ті, хто неї читає, ті самі слова й вираження розуміють однаково. Однак насправді це не так, оскільки природній мові властиве певна розмитість понять. Внаслідок цього те саме вимога може трактуватися різними людьми по-різному.
Щоб уникнути подібних проблем, розроблені методи опису вимог, які структурують специфікацію й зменшують розмитість визначень. Ці методи представлені в табл. 5.3. Крім цього, розроблені інші підходи, наприклад спеціальні мови опису вимог [333, 9, 35, 10, 18*, 19*], які використовуються відносно рідко. У цій главі розглядаються перші два підходи з описаних у табл. 5.3,
Таблиця 5.3. Способи запису специфікацій вимог
Система запису
Опис
Структурований природна мова
Використання стандартних форм і шаблонів для написання
специфікації
Мови опису програм
Використання спеціальних структурованих мов, подібним мовам програмування, де специфікація вимог будується на основі обраної операційної моделі системи
Графічні нотації
Графічна мова, що використовує для опису функціональних вимог діаграми й блок-схеми, доповнені текстовими поясненнями. Найбільш відомий приклад такої графічної мови-діаграми структурного аналізу й проектування ПЗ (SАDТ), метод опису варіантів використання
Математичні специфікації
Це системи нотацій, засновані на математичних концепціях, таких, як теорія кінцевих автоматів або теорія множин.
Це формалізована однозначна й позбавлена двозначності запис системних вимог. Однак багато замовників ПЗ не розуміють формальних специфікацій, внаслідок чого виникають певні проблеми при висновку контрактів на розробку програмних продуктів.
5.3.1. Структурована мова специфікацій
Це скорочена форма природної мови, призначена для написання специфікації вимог. Достоїнством такого підходу до написання специфікацій є те, що він зберігає виразність і зрозумілість природної мови й разом з тим формалізує опис вимог. Структурованість мови проявляється у використанні спеціальної термінології, а також шаблонів для опису системних вимог. Структурована мова може включати язикові конструкції, узяті з мов програмування.
Приклад використання структурованої мови для опису системних вимог наведений у роботі [160]. Тут для написання специфікації вимог для програмної системи керування польотами розроблені спеціальні форми, що допомагають описати вхідні й вихідні дані й функції системи.
Для опису системних вимог часто розробляються спеціальні форми й шаблони. Вони повинні враховувати, на основі чого будується специфікація: на основі об'єктів, керованих системою, на основі функцій, виконуваних системою, або на основі подій, оброблюваних системою. Приклад форми для специфікації показаний в урізанні 5.8. Це більше деталізований опис функції створення структурних елементів для системи редагування програмних архитектур, описаної в урізанні 5.7.
Вставка 5.8. Специфікація системної вимоги, що використовує стандартну форму
Функція. Додавання структурних елементів у схему,
Опис. Додавання структурних елементів в існуючу схему системної архітектури. Користувач вибирає тип структурного елемента і його місце розташування. Після вставки в схему структурний елемент стає виділеним (поточним структурним елементом). Користувач визначає місце розташування елемента шляхом переміщення курсору по області схеми.
Вхідні дані. Тип елемента, позиція елемента, ідентифікатор схеми.
Джерела вхідних даних. Тип елемента й позиція елемента задаються користувачем ідентифікатор схеми отриманий з бази даних проекту.
Вихідні дані. Ідентифікатор схеми.
Пункт призначення. База даних проекту. Ідентифікатор схеми міститься в базу даних проекту по завершенні виконання даної функції.
Для виконання функції потрібна схема, певна вхідним ідентифікатором схеми.
Передумова. Схема відкрита й відображається на екрані користувача.
Пост-умова. Схема, за винятком вставки нового структурного елемента, не змінюється.
Побічні Ефекти. Немає.
Стандартні форми, використовувані для специфікування функціональних вимог, повинні містити наступну інформацію.
Опис функції або об'єкта.
Опис вхідних даних і їхні джерела.
Опис вихідних даних із вказівкою пункту їхнього призначення.
Вказівка, що необхідно для виконання функції.
Якщо це специфікація функції, необхідний опис попередніх умов (передумов), які повинні виконуватися перед викликом функції, і опис заключної умови (пост-умов), що повинне бути виконане після завершення виконання функції.
Опис побічних ефектів (якщо вони є).
Використання структурованої мови знімає деякі проблеми, властивим специфікаціям, написаним природною мовою, оскільки знижує "варіабельність" специфікації й більш ефективно її структурує. Разом з тим деяка "розмитість" визначень і описів у специфікації залишається. Альтернативою використанню структурованої природної мови може служити спеціальна мова опису специфікацій (розглянутий у наступному розділі), що повністю знімає проблему нечіткості опису вимог. Але з іншого боку, неспеціаліст знайде таку специфікацію важкої для читання й розуміння.
5.4. Документування системних вимог
Документ, що містить вимоги, також називаний специфікацією системних вимог, - це офіційне приписання для розроблювачів програмної системи. Він містить користувальницькі вимоги й деталізований опис системних вимог. У деяких випадках користувальницькі й системні вимоги можуть не розрізнятися, виступаючи спільно у вигляді однорідного опису системи. В інших випадках користувальницькі вимоги приводяться у введенні документа-специфікації. Якщо загальна кількість вимог велика, деталізовані системні вимоги можуть бути представлені у вигляді окремого документа.
Системну специфікацію читає безліч різних людей, починаючи від вищого керівництва компанії - замовника системи й закінчуючи рядовим розроблювачем системи. На мал. 5Д узятому зі статті [204], показані категорії читачів специфікації.
Хенингер (Неninger [160]) сформулював шість умов, яким повинна відповідати специфікація програмної системи.
Описувати тільки зовнішнє поводження системи.
Указувати обмеження, що накладаються на процес реалізації системи.
Передбачати можливість внесення змін у специфікацію.
Служити довідковим засобом у процесі супроводу системи.
Відображати весь життєвий цикл системи.
Передбачати реакцію системи й групи супроводу на непередбачені (позаштатні) ситуації.
Рис 5.3. Читачі системної специфікації
Хоча із часу написання цих умов пройшло більше 20 років, вони не втратили своєї актуальності і є гарною підмогою при розробці специфікацій. Разом з тим часом складно або навіть неможливо описати систему тільки в термінах зовнішнього поводження, тобто тільки за допомогою функцій, які вона повинна виконувати, оскільки в специфікації також повинні бути відбиті обмеження, що накладаються оточенням уже існуючих систем. Інша умова- охват усього життєвого циклу системи - приймається всіма розроблювачами, але рідко виконується на практиці.
Багато організацій, такі, як Міністерство оборони США й Інститут інженерів по електротехніці й радіоелектроніці IЕЕЕ, розробили власні стандарти документування специфікацій. У монографії [89] описані деякі із цих стандартів, а також проведено їхнє порівняння. Найбільш відомий стандарт розроблений IEEE і називається IEEE/АNSI 830-1993 [IEEE, 1993]. У книзі [334], що містить чудовий огляд робіт з технології розробки вимог, наведений повний опис цього стандарту. Даний стандарт припускає наступну структуру специфікації.
1. Вступ
Мета документа
Призначення програмного продукту
Визначення, акроніми й абревіатури
Список літератури й інших джерел
Огляд специфікації
2. Загальний опис
Опис програмного продукту
Функції програмного продукту
Користувальницькі характеристики
Загальні обмеження
Обґрунтування, припущення й допущення
3. Специфікація вимог охоплює функціональні, нефункціональні й інтерфейсні вимоги. Це найбільш значима частина документа, але внаслідок украй широкого діапазону можливих вимог, пропонованих програмним системам, у стандарті не визначена структура цього розділу. Тут можуть бути документовані зовнішні інтерфейси, описані функціональні можливості системи, наведені вимоги, що визначають логічну структуру баз даних, обмеження, що накладаються на структуру системи, описані інтеграційні властивості системи або її якісні характеристики.
Додатка
Покажчики
Хоча стандарт ІЕЕЕ не ідеальний, він може служити відправною крапкою при написанні специфікації. Звичайно, при її написанні необхідно також ураховувати стандарти, прийняті в організації - розроблювачі ПО. У табл. 5.4 описані можливі розділи специфікації, побудованої на підставі стандарту IEEE..
Таблиця 5.4. Структура специфікації вимог
Розділ
Опис
Передмова
Тут визначається коло осіб, на яких розрахований даний документ. Описуються попередні версії розроблювального програмного продукту, а також зміни, внесені в кожну версію. Дається обґрунтування для створення нової версії продукту
Вступ
Тут більш розгорнуто обґрунтовується необхідність створення системи. Коротко перераховуються системні функції й пояснюється, як система буде працювати разом з іншими системами. Повинне бути показане, як розробка системи "уписується" у загальну бізнес-стратегію компанії, що замовляє програмний продукт
Глосарій
Дається опис технічних термінів, використовуваних у документі. Тут не робиться яких-небудь припущень про рівень знань або практичному досвіді читача документа
Користувальницькі вимоги
Описуються сервіси, надавані користувачам, і нефункціональні системні вимоги. Цей опис може бути зроблено природною мовою з використанням діаграм, блок-схем і інших форм запису, зрозумілих замовникові програмної системи. Тут також повинні бути наведені стандарти на програмний продукт і процес його розробки
Системна архітектура
Тут приводиться високорівневе подання можливої системної архітектури із вказівкою, як розподілені системні функції по компонентах системи. Обов'язково повинні бути виділені повторно використовувані (тобто вже існуючі) компоненти
Системні вимоги
Докладно описуються функціональні й нефункціональні вимоги. Якщо необхідно, нефункціональні вимоги доповнюються описом інтерфейсів інших систем
Системні моделі
Тут представлено кілька системних моделей, що показують
взаємини між системними компонентами й між системою і її оточенням. Це можуть бути об'єктні моделі, моделі потоків даних або моделі даних
Еволюція системи
Наводяться основні припущення й допущення, на яких базується система, а також очікувані (прогнозовані) зміни
в апаратних засобах, у потребах користувачів і т.п.
Закінчення табл. 5.4
Розділ
Опис
Додатки
Тут наводиться спеціалізована інформація, що ставиться до розроблювальної системи, наприклад опис апаратних засобів або бази даних, з якими повинна працювати система. При описі апаратних засобів необхідно показати мінімальну й оптимальну конфігурації, при яких може працювати програмна система. Опис бази даних повинне відображати логічну структуру даних, з якими буде працювати система, і відносини між ними
Покажчики
У документі можливе використання різних покажчиків. Це може бути звичайний алфавітний покажчик, покажчик діаграм або покажчик системних функцій
Звичайно, інформація, що включається в специфікацію, залежить від типу розроблювального програмного забезпечення й від обраної технології розробки. Наприклад, якщо при розробці буде використовуватися еволюційний підхід, багато розділів специфікації, перераховані в табл. 5.4, будуть зайві. Якщо ж розроблювальне ПО є тільки частиною великої системи, що складає із взаємодіючих апаратних і програмних систем, тоді по необхідності вимоги будуть дуже докладними й деталізованими. У цьому випадку специфікація може мати значний обсяг і буде містити більше розділів, чим перераховане в табл. 5.4. Для більших документів необхідно робити зміст і докладні покажчики для пошуку необхідної інформації.
Розробка вимог
Аналіз осуществимости
Формування н аналіз вимог
Атестація вимог
Керування вимогами
Розробка вимог - це процес, що включає заходи, необхідні для створення й затвердження документа, що містить специфікацію системних вимог. Розрізняють чотири основних етапи процесу розробки вимог: аналіз технічної реалізуємості створення системи, формування й аналіз вимог, специфікування вимог і створення відповідної документації, а також атестація цих вимог. У цій главі розглянуті всі перераховані етапи, за винятком специфікування й документування, які описані в главі 5. На мал. 6.1 показані взаємозв'язки між цими етапами й документи, що супроводжують кожний етап процесу розробки системних вимог.
На мал. 6.1 ...
05.12.2012 19:12-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора