5.4. Документування системних вимог

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

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

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

• Описувати тільки зовнішню поведінку системи.

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

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

• Служити довідковим засобом в процесі супроводу системи.

• Відображати весь життєвий цикл системи.

• Передбачати реакцію системи і групи супроводу на непередбачені (нештатні) ситуації.

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

Інша умова - обхват всього життєвого циклу системи - приймається всіма розробниками, але рідко виконується на практиці.

Багато організацій, такі, як Міністерство оборони США і Інститут інженерів по електротехніці і радіоелектроніці IEEE, розробили власні стандарти документування специфікацій. Найвідоміший стандарт розроблений IEEE і називається IEEE/ANSI 830-1993. Даний стандарт припускає наступну структуру специфікації.

1. Введення

1. Цілі документа

2. Призначення програмного продукту

3. Визначення і абревіатури

4. Список літератури і інших джерел

5. Огляд специфікації

2. Загальний опис

1. Опис програмного продукту

2. Функції програмного продукту

3. Призначені для користувача характеристики

4. Загальні обмеження

5. Обгрунтовування, припущення і допущення

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

4. Додатки

5. Покажчики

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

Таблиця 5.4. Структура специфікації вимог

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

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

Вправи

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

2. Досліджуйте точність формулювань наступної вимоги, що описує автоматизовану систему продажу квитків.

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

3. Перепишіть вимогу попереднього пункту, використовуючи структурний підхід, описаний в цьому розділі.

4. Запишіть системні вимоги для системи продажу квитків за допомогою мови, заснованої на мові програмування Java. Зверніть увагу на обробку помилок користувача.

5. Опишіть три типи нефункціональних вимог, які можуть мати місце в програмних системах. Приведіть приклади кожного типу вимог.

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

7. Якими властивостями винен володіти мова програмування, щоб його можна було застосувати для написання специфікацій інтерфейсів? В цьому аспекті розглянете можливості мов С, Java і Ada.

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

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

10