Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТППС / Магистры / ТППС-лаб. магистры-2014-укр.docx
Скачиваний:
215
Добавлен:
05.06.2015
Размер:
3.64 Mб
Скачать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Користувацькі вимоги

  1. ПЗ повинне надати засіб доступу до зовнішніх файлів, створених в інших програмах.

Специфікація системних вимог

    1.   Користувач повинен мати можливість визначати тип зовнішніх файлів.

1.2   Для кожного типу зовнішнього файлу повинен бути відповідний засіб, застосовнийе до цього типу файлів.

1.3   Зовнішній файл кожного типу повинен бути представлений відповідною піктограмою на дисплеї користувача.

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

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

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

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