5.2 Специфікація системних вимог (System Requirements Specification)

У складних проектах прийнято розділяти специфікацію системних вимог (system requirements) і специфікацію програмних вимог (software requirements). При такому підході програмні вимоги породжуються системними вимогами і деталізують вимоги до компонентів і підсистем програмного забезпечення. Документ описує програмну систему в контексті системної інженерії (system engineering), ідеї якої коротко описані в главі 12 SWEBOK "Пов'язані дисципліни програмної інженерії". Строго кажучи, специфікація системних вимог описує діяльність системних інженерів і виходить за рамки обговорення SWEBOK. Стандарт IEEE 1233 є одним з визнаних керівництва по розробці системних вимог. І, як вже зазначалося раніше, не варто забувати про те, що поняття система, в загальному випадку, охоплює програмне забезпечення, апаратну частину і людей. Системна інженерія (див. матеріали INCOSE - www.incose.org), в свою чергу, самостійна і не менш об'ємна дисципліна ніж програмна інженерія. SWEBOK розглядає системну інженерію як важливу пов'язану дисципліну. Ну а системні вимоги - один з елементів реального зв'язування різної інженерної діяльності - програмної і системної.

5.3 Специфікація програмних вимог (Software Requirements Specification - srs)

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

Програмні вимоги встановлюють основні угоди між користувачами (замовниками) та розробниками (виконавцями) стосовно того, що робитиме система і чого від неї не варто очікувати. Документ може включати процедури перевірки одержуваного програмного забезпечення на відповідність запропонованим йому вимогам (аж до змісту планів тестування), характеристики, що визначають якість і методи його оцінки, питання безпеки та багато іншого. Часто програмні вимоги описуються на звичайній мові. У той же час, існують напівформальні і формальні методи і підходи, які використовуються для специфікації програмних вимог. У кожному разі, завдання полягає в тому, щоб програмні вимоги були ясні, зв'язки між ними прозорі, а зміст даної специфікації не допускав різночитань і інтерпретацій, здатних привести до створення програмного продукту, що не відповідає потребам зацікавлених осіб. Стандарт IEEE 830 є класичним прикладом стандарту на утримання структурування і методи опису програмних вимог - "Recommended Practice for Software Requirements Specifications".

На думку авторів, в документацію на вимоги не слід вносити елементи дизайну системи (скажімо, логічну модель бази даних). А ось сценарії використання Use Case часто включають в специфікацію вимог нарівні з трасуванням (traces) до відповідних моделей у формі діаграм, наприклад, до UML Use Case, UML Activity, BPMN і т.п. . Говорячи про написання специфікацій вимог, то тут є одна серйозна помилка, яку зазвичай роблять недосвідчені аналітики - це фактична підміна вимог як таких, моделями графічного інтерфейсу, тобто коли в документи-специфікації вимог просто включаються «картинки» для користувача інтерфейсу з невеликими поясненнями. Це аж ніяк не означає, що з зацікавленими особами і зокрема з користувачами, не слід взагалі обговорювати дизайн GUI, часто є сенс це робити, але для цього існує, наприклад, прототипування. Судячи із змісту багатьох прочитаних документів вимог у різних організаціях, практично всі вони мали одні і ті ж проблеми:

1. Термінологічна невизначеність. Часто використовуються терміни, які володіють багатозначністю, і такі терміни не визначені в глосаріях, щоб можна було чітко зрозуміти, що конкретно автор має на увазі в даному випадку (це не завжди буває зрозуміло з контексту). Як приклад можна привести власне використання (і, що важливо, розуміння!) Терміна «вимоги». Під цим ѐ мкім терміном можна розуміти як вимоги до бізнес процесів, так і функціональні або нефункціональні вимоги до забезпечення загалом. Цікаво, що на рівні багатьох стандартів (на жаль, в основному, англомовних) прописано використання тих чи інших дієслів, форм і структурування пропозицій, що описують вимоги - наприклад використання дієслів (will, shall, should, may, can - перераховані в порядку "убування директивності "). Дійсно, "програмний модуль X відсилає повідомлення на e-mail адресу користувача ..." несе, м'яко кажучи, інше смислове навантаження, ніж "надсилається повідомлення".

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

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

4. Зайве акцентування уваги на деталях реалізації. Спроба відобразити в документі з вимогами до створюваного ПЗ не ЩО має робити система, а то ЯК вона це робитиме. Це одна з ключових проблем. Багато в чому, тому, часто виділяють внутрішні технічні вимоги до системи, які не проходять атестацію з боку користувачів і розробляються не аналітиками, а архітектором і провідними розробниками вже на етапі проектування - software design (див. наступну область знань SWEBOK).

5. Слабка формалізація бізнес-процесів. У документах перемішується опис бізнесу та вимоги до ПЗ, що приводить складнощів у розумінні суті і спільного розуміння як повинна бути спроектована система.