1. Методи визначення вимог в програмній інженерії

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

У загальному випадку під вимогами до ПС розуміють властивості, якими повинна володіти ця система для адекватного виконання функцій.

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

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

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

Л. Новіков в російській редакції нотації RUP [2.9] приводить наступне визначення: "Вимога - це умова або можливість, якій повинна відповідати система".

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

1.1 Формування вимог до програмного виробу

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

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

ПВ може створюватися як за індивідуальним замовленням від­повідно до вимог конкретного споживача, так і для комерційного застосування. У зв’язку з цим можна виділити такі типи програм­них проектів:

1. проекти, керовані споживачем;

2. проекти, що затверджуються споживачем;

3. незалежні проекти.

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

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

Види вимог.

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

Вимоги користувачів (user requirements) описують цілі і завдання, які користувачам дозволить вирішити система. До способів представлення цього виду вимог відносяться варіанти використання, сценарії і таблиці "подія - відгук".

Системні вимоги (system requirements) означають високорівневі вимоги до продукту, які містять багато підсистем або усі системи. З вимог для усієї системи головними є функціональні вимоги до ПВ.

Функціональні вимоги включають опис вимог по видам і типам функцій, що реалізовуються, і документуються в специфікації вимог до ПВ (software requirements specification, SRS), де описана і очікувана поведінка системи.

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

Атрибути якості (quality attributes) є додатковим описом функцій програмного виробу, виражених через опис його характеристик, важливих для користувачів або розробників. До таких характеристик відносяться легкість і простота використання, легкість переміщення, цілісність, ефективність і стійкість до збоїв.

Бізнес-вимоги (business requirements) містять високорівневі цілі замовників бізнес-системи. Як правило, їх висловлюють ті, хто фінансують проект, покупці системи, менеджер реальних користувачів і відділ маркетингу. Бізнес-вимоги (business rules) включають корпоративні політики, урядові постанови, промислові стандарти і обчислювальні алгоритми. Вони не є вимогами до ПВ, тому що вони знаходяться зовні меж будь-якої системи ПВ. Проте вони часто накладають обмеження на виконання конкретних варіантів використання або на функції системи. Бізнес-вимоги стають джерелом атрибутів якості, які реалізуються у функціональності.

Вимоги до ПВ повинні відповідати прийнятій згідно з ДСТУ системі характеристик якості ПВ. Категорії вимог відповідно до системи характеристик якості подані у табл. 1.1.

 Таблиця 1.1 ХАРАКТЕРИСТИКА ВИМОГ ДО ПВ

Категорія вимог	Характеристика / підхарактеристика якості
Функціональні:
до складу функцій та їх характеристик	Функціональність/функціональна повнота, продуктивність; надійність/реактивність
до даних (структура, формат, діапазон значень)	Функціональність/масовість
до захисту даних	Функціональність/захищеність; надійність/стійкість до аномалій
до взаємодії з іншими ПВ	Функціональність/здатність до взаємодії
до точності розрахунків	Надійність/правильність, точність
до повноти вихідної інформації	Зручність використання/аналізованість
Експлуатаційні:
до умов використання (режим використання, рівень інтерфейсу)	Зручність використання/простота підготовки до роботи
до засобів керування програмним ви­робом	Зручність використання/освоюва­ність, узгодженість
до документації користувача	Зручність використання/освоюва­ність, документованість
до конфігурації апаратно-програмного оточення (ОС, СКБД, ППП)	Переносимість/налагоджуваність; раціональність/зайнятість ресурсів
до застосування у непередбаченому апа­ратно-програмному середовищі	Переносимість/адаптованість
до безпеки функціонування	Надійність/безвідмовність, стійкість до аномалій
Конструктивні:
до структурної побудови ПВ	Супроводжуваність/аналізованість, кори­гованість, модернізованість
до незалежності компонентів	Надійність/відновлюваність; супроводжуваність/коригованість, модернізованість, тестованість
до мінімізації міжмодульних зв’язків	Супроводжуваність/коригованість, модернізованість, тестованість; раціональність/використовуваність ресурсів
до дисципліни кодування	Супроводжуваність/аналізованість

Вимоги до програми повинні мати такі властивості:

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

2. повнота — відповідність вимог користувача і сформованих вимог до ПВ за визначеними категоріями вимог. Для контролю та обґрунтованості повноти врахування вимог користувача можна запропонувати створення порівняльної таблиці вимог, яка дозволить виконувати трасування вимог як вручну, так і за допомогою автоматизованих засобів;

3. обґрунтованість — відповідність вимог рівню якісних характеристик певного класу ПП. Ознаками, за якими різняться вимоги, є: призначення ПВ, структура даних, кількість користувачів, що одночасно мають доступ до даних, ступінь орієнтації на транзакції та запити, рівень безпеки та ін.;

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

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

Вимоги до програмного виробу повинні бути чітко документовані. Для опису кожної вимоги пропонується така сукупність атрибутів [6]: ідентифікатор, вагомість, пріоритет, стабільність, придатність до верифікації.

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

Вагомість указує, наскільки суттєвою є вимога, чи можливе майбутнє її обговорення та змінювання, чи є вона категоричною. Рівень вагомості встановлюється відповідно до шкали рейтингів, прийнятої для ПВ певного класу: обов’язкова, бажана, необов’язкова.

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

Стабільність відображає ступінь сталості вимоги.

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