ОПІ


7 Лекції
Програмні вимоги (Software Requirements)
 
Програмні вимоги – Software Requirements – це властивості програмного забезпечення, які повинні бути належно представлені в ньому для вирішення конкретних практичних завдань. Ця галузь знань стосується питань збору, аналізу, специфікації і затвердження вимог.
Управління вимогами  (як показує досвід індустрії IT-технологій) надають критично-важливий вплив на програмні проекти і певною мірою - на сам факт можливості успішного завершення проектів.
Системна робота з вимогами дозволяє коректним чином забезпечити моделювання задач реального світу і формулювання необхідних приймальних тестів з метою забезпечення відповідності створюваних програмних систем критеріям, заданим реальними практичними потребами.
На практиці часто застосовується підхід, який використовується в різних методологіях розробки ПЗ і базується на визначенні груп вимог до продукту. Такий підхід зазвичай включає групи (типи, категорії) вимог, наприклад: системні, програмні, функціональні, нефункціональні (зокрема, атрибути якості) і т.п. Класичний приклад (див. малюнок 1) високорівневого структурування груп вимог як вимог до продукту описаний в роботах одного з класиків дисципліни управління вимогами - Карла Вігерса.
 
Рис. 1. Рівні вимог згідно Вігерса [Вігерс, 2003, с.8, рис. 1-1] 
SWEBOK охоплює не тільки питання структурування та систематизації вимог, але і різних процесів етапів і процесів роботи з вимогами, а також деякі практичні міркування.
Рис. 2. Область знань "Програмні вимоги" [SWEBOK, 2004, с.2-2, рис. 1] 
Сама ж структура обговорюваної області знань у великій мірі сумісна із стандартами IEEE 12207.x, ISO/IEC, ДСТУ ISO/IEC 12207 (структура стандарту буде розглянута пізніше). Така структура побудована виходячи з ідеї виділення ключових груп питань дисципліни.
Область знань керування вимогами включає 7 секцій, кожна з яких представлена ​​у вигляді ключових тем (див. рис. 2). Крім того, дана галузь знань тісно пов'язана з наступними областями:
                        • Software Design
                        • Software Testing
                        • Software Maintenance
                        • Software Configuration Management
                        • Software Engineering Management
                        • Software Engineering Process
                        • Software Quality
 
1. Основи програмних вимог (Software Requirements Fundamentals)
 
Ця секція включає визначення програмних вимог як таких і описує основні типи вимог і їх відмінності: до продукту і процесу, функціональні та нефункціональні вимоги і т.п.
Теми даної секції:
 
1.1 Визначення вимог (Definition of a Software Requirements) - в даному випадку мається на увазі не процес визначення (витягу, збору, формування, формулювання) вимог, а дається саме поняття "вимоги", як такої, і відзначаються її основні характеристики, наприклад, верифікованість (перевірюваність) вимоги.
На думку авторів, необхідно звернути увагу на такі визначення поняття "вимога" (на основі робіт Вігерса і стандарту IEEE Standard Glossary of Software Engineering Terminology, 1990):
• Умова, можливість, необхідна користувачем для вирішення завдань або досягнення цілей.
• Умова, можливість, які повинні задовольнятися системою/компонентом системи або якими система/компонент системи повинна володіти для забезпечення умов контракту, стандартів, специфікацій або іншими регулюючими документами.
• Документальна репрезентація (зафіксоване подання, визначення, опис) умов чи можливостей, перерахованих у попередніх пунктах.
 
1.2 Вимоги до продукту та процесу (Product and Process Requirements) - проводиться розмежування відповідних вимог як властивостей продукту, який необхідно отримати, і процесу, з допомогою якого продукт буде створюватися; відмічається, що ряд вимог може бути закладений неявно і програмні вимоги можуть породжувати вимоги до процесу, наприклад: робота в режимі 24x7 (як бізнес-вимога) напевно призведе до обмеження вибору тих чи інших програмних засобів, платформ розгортання і архітектурних рішень, у свою чергу, вибір платформи J2EE (Java 2 Enterprise Edition) та її реалізації у вигляді конкретного сервера додатків практично напевно вимагатиме застосування модульного тестування (Unit testing) як практики процесу розробки та JUnit, як інструменту реалізації цієї практики.
 
1.3 Функціональні та нефункціональні вимоги (Functional and Non-functional Requirements) - функціональні вимоги задають, "що" система повинна робити; нефункціональні - з дотриманням "яких умов" (наприклад, швидкість відгуку при виконанні заданої операції). На думку авторів, певною мірою, систематизуючи роботи Вігерса, Лефінгвелла і Відріга, Коберна, а також інших експертів, необхідно привести класифікацію різних категорій (видів) вимог і пов'язаних з ними понять, найважливіших з точки зору їх розуміння та подальшого практичного застосування:
• Потреби (needs) - відображають проблеми бізнесу, персоналії або процесу, які повинні бути співвіднесені з використанням або придбанням системи.
• Група функціональних вимог
• Бізнес-вимоги (Business Requirements) - визначають високорівневі цілі організації або клієнта (споживача) - замовника розробляється програмного забезпечення.
• Користувацькі вимоги (User Requirements) - описують цілі/завдання користувачів системи, які повинні досягатися/виконуватися користувачами за допомогою створюваної програмної системи. Ці вимоги часто представляють у вигляді варіантів використання (Use Cases).
• Функціональні вимоги (Functional Requirements) - визначають функціональність (поведінку) програмної системи, яка повинна бути створена розробниками для надання можливості виконання користувачами своїх обов'язків в рамках бізнес-вимог і в контексті Користувацьких вимог.
• Група нефункціональних вимог (Non-Functional Requirements)
• Бізнес-правила (Business Rules) - включають або пов'язані з корпоративними регламентами, політиками, стандартами, законодавчими актами, внутрішньокорпоративними ініціативами (наприклад, прагнення досягти зрілості процесів по CMMI 4-го рівня), обліковими практиками, алгоритмами обчислень і т.д. Насправді, досить часто можна бачити недостатнє приділення уваги такого роду вимогам з боку співробітників ІТ-департаментів і, зокрема, технічних фахівців, залучених до проекту. Business Rules Group дає розуміння бізнес-правила, як "положення, які визначають або обмежують деякі аспекти бізнесу. Вони мають на увазі організацію структури бізнесу, контролюють або впливають на поведінку бізнесу ". Бізнес-правила часто визначають розподіл відповідальності в системі, відповідаючи на питання "хто буде здійснювати конкретний варіант, сценарій використання" або диктують появу деяких функціональних вимог.
У контексті дисципліни управління проектами (вже поза проектом розробки програмного забезпечення, але виконання бізнес-проектів і бізнес-процесів) такі правила мають високу значимість, і саме вони часто визначають обмеження бізнес-проектів, для автоматизації яких створюється відповідне програмне забезпечення.
• Зовнішні інтерфейси (External Interfaces) - часто заміняються "користувацьким інтерфейсом". Насправді питання організації призначеного для користувача інтерфейсу безумовно важливі в даній категорії вимог, однак, конкретизація аспектів взаємодії з іншими системами, операційним середовищем (наприклад, запис до журналу подій операційної системи), можливостями моніторингу при експлуатації - все це не стільки функціональні вимоги (до яких помилково приписують іноді такі характеристики), скільки питання інтерфейсів, оскільки функціональні вимоги пов'язані безпосередньо з функціональністю системи, спрямованою на вирішення бізнес-потреб.
• Атрибути якості (Quality Attributes) - описують додаткові характеристики продукту в різних "вимірах", важливих для користувачів і/або розробників. Атрибути стосуються питань портативності, інтероперабельності (прозорості взаємодії з іншими системами), цілісності, стійкості і т.п.
• Обмеження (Constraints) - формулювання умов, що модифікують вимоги або набори вимог, звужуючи вибір можливих рішень з їх реалізації. Зокрема, до них можуть відноситися параметри продуктивності, що впливають на вибір платформи реалізації та/або розгортання (протоколи, сервери додатків, баз даних, ...), які, в свою чергу, можуть відноситися, наприклад, до зовнішніх інтерфейсів.
• Системні вимоги (System Requirements) - іноді класифікуються як складова частина групи функціональних вимог (не плутайте з так званими "функціональними вимогами"). Описують високорівневі вимоги до програмного забезпечення, яке містить кілька або багато взаємопов'язаних підсистем і додатків. При цьому, система може бути як цілком програмною, так і складатися з програмної і апаратної частин. У загальному випадку, частиною системи може бути персонал, що виконує певні функції системи, наприклад, авторизація виконання певних операцій з використанням програмно-апаратних підсистем.
Необхідно зробити декілька важливих зауважень з бізнес-правилами. Бізнес правила, як такі, є предметом пильного вивчення різних фахівців в області як бізнес-моделювання, так і програмної інженерії в цілому. Практика розробки програмних вимог включає ідентифікацію та опис бізнес-правил як самостійних артефактів. Наприклад, методологія RUP виділяє окремий артефакт Business Rule в рамках дисципліни Business Modeling. Всі бізнес-правила в рамках даної дисципліни ідентифікуються та описуються в документі Business Rules Document. При розробці вимог в сценаріях Use Cases зазвичай включається посилання на вже описане бізнес-правило. Скотт Амблер (див. www.agilemodeling.com/artifacts/) так само виділяє бізнес-правило як один з артефактів, який використовують в сімействі Agile-методологій.
В даний час розроблені методи і підходи формального подання бізнес-правил, аж до формальних мов опису (використання OCL - Object Constraint Language, BRML - Business Rules Markup Language). Бізнес-правила можуть бути не тільки використані при визначенні вимог до розроблюваного ПЗ, але й можуть окремо оформлятися в дизайні ПЗ (клас або група класів), відбиваючись в кінцевому підсумку в програмному коді певною мовою програмування. Існують спеціалізовані інструментальні засоби і бібліотеки, що дозволяють розробляти і підтримувати програми, які інтенсивно використовують бізнес-правила.
Розглядаючи бізнес-правила як артефакти, що відносяться до області програмних вимог, можна відзначити, вірніше дати одне з пояснень, чому БП відносять до нефункціональних вимог: Наприклад, при написанні певного кроку в сценарії use case, використовується посилання на бізнес правило: «... система проводить розрахунок вартістю згідно бізнес-правила BP41 ... ». У свою чергу дане бізнес-правило може визначати алгоритм розрахунку вартості. Тобто наявність «з дотриманням яких умов система робить розрахунок».
Одним з найбільш відомих фахівців з BR є Рональд Росс, автор книги «Principles of the Business Rule Approach» (Ronald G. Ross. "Principles of the Business Rule Approach», 2003).
Нарівні з представленою класифікацією вимог можуть використовуватися й інші підходи. Навіть у рамках цієї класифікації існують і різні погляди на її інтерпретацію і деталізацію. Наприклад, як результат визначення цільової аудиторії і в рамках маркетингової стратегії просування тиражованою рішення, можна визначати високорівневі можливості (ключові характеристики, особливості) - "фічі" (features) розроблюваного продукту. Іноді, такі можливості деталізуються в якості функціональних вимог у деяких agile-техніках, наприклад, FDD - Feature-Driven Development (як ви бачите аж до самої назви цілого комплексу практик, методу розробки).
Вігерс описує feature як "безліч логічно пов'язаних функціональних вимог, які надають певні можливості для користувача і відповідають бізнес-цілям <організації>". З точки зору маркетингу програмного забезпечення, як зазначає Вігерс, feature - це «група вимог, яку упізнають зацікавлені особи, які залучені до процесу прийняття рішення з придбання ПЗ - це список <відмінних особливостей або можливостей, характеристик>, присутній в описі продукту». У той же час Леффінгвелл і Відріг (D. Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Second Edition, 2003) визначають feature як "сервіси, які надає система для задоволення однієї або більше потреб зацікавлених осіб (stakeholders needs) ". Ними ж наголошується, що в реальних проектах можуть бути не визначені stakeholders needs (а їх часто виділяють, особливо якщо у проекту/продукту є багато зацікавлених осіб зі своїми потребами, і ці потреби можуть носити взаємовиключний характер), але існувати features можуть і самостійно ( як і stakeholder needs), і звичайно ж можливе існування і stakeholder needs і features із взаємним трасуванням.
Розвиваючи тему features - Kurt Bittner & Ian Spence у своїй книзі "Use Case Modeling" (Kurt Bittner, Ian Spence. Use Case Modeling, 2002), дають схоже, хоча й більш формальне визначення features. Вони відзначають, що features можуть належати як до функціональних, так і до нефункціональних вимог. І можуть змінюватися від версії до версії продукту.Аналізуючи різні джерела на предмет роботи з features, слід зазначити наступне: З точки зору інженерії вимог, features є самостійним артефактом, який може бути співвіднесений як до функціональних вимог, так і з нефункціональними (в т.ч. з обмеженнями проектування або атрибутами якості).
Необхідно також зазначити, що Features володіють певним дуалізмом у своїй інтерпретації, залежним від контексту конкретного продукту - з одного боку це може бути «той самий список характеристик, вказаний на коробці продукту» в разі створення «коробкового ПО», з іншого боку це може список високорівневих можливостей системи, наприклад при замовний розробці ПЗ автоматизації бізнес-процесів конкретної організації.
Features можуть бути різного рівня деталізації - від виразу високорівневих можливостей системи (наприклад, «Розрахунок заробітної плати ...»), до досить конкретних вимог (наприклад, «Автоматичне повідомлення Клієнта по e-mail про резервування товару на складі»)
 
1.4 Незалежні властивості (Emergent Properties) - ці властивості позначають вимоги, які адресовані до системи в цілому, і не можуть бути співвіднесені з отдельними її елементами. Тобто дані вимоги ставляться до того синергетичного ефекту, яким може володіти така система («ціле більше, ніж сума його частин»). Прикладом може служити вимоги до «пропускної здатності» коллцентра, яка залежатимуть від того, яким чином будуть взаємодіяти комунікаційне обладнання, оператор і програмне забезпечення в конкретних умовах.
 
1.5 Вимоги з кількісною оцінкою (Quantifiable Requirements) - вимоги, які піддаються обчисленню/виміру, наприклад, система повинна забезпечити пропускну здатність "стільки-то запитів в секунду"; в той же самий час, вкрай важливо розуміти, що постановка питання (тобто формулювання вимоги) у формі "система повинна забезпечити зростання пропускної спроможності" без вказівки конкретних кількісних характеристик є просто некоректно певним вимогою.
На думку авторів, при цьому, наприклад, вимога "система повинна вести журнал підключень користувачів" може і повинна деталізуватися з точки зору опису інформації, яку необхідно зберігати в журналі, однак, така вимога вже не буде кількісною вимогою. А вимога з формулюванням "система повинна володіти інтуїтивно-зрозумілим призначеним для користувача інтерфейсом" – нездатною до перевірки. У певних випадках, на думку автора книги, це може виглядати просто знущанням, навіть не будучи спочатку таким - все залежить від точки зору: наприклад, в устах "цільового" користувача спеціалізованого програмного забезпечення - системного адміністратора, який звик працювати в kshell (популярної командної оболонці Unix/Linux), що пояснює свої потреби аналітику, що фіксує запити користувачів та звиклого оперувати Microsoft Office;) Чи може така вимога бути переформульовані та/або деталізовано для адекватності інтерпретації? Так. Наприклад, так - середній показник помилок оператора не повинен перевищувати 2% від обсягу введеної інформації і 85% користувачів мають дати позитивну оцінку прототипу Користувацького інтерфейсу на етапі дослідної експлуатації.Такі вимоги повинні однозначно відповідати на питання, що припускають відповіді з чисельними величинами - як часто? наскільки швидко? в якій кількості? і т.п. Більшість вимог з кількісною оцінкою відносяться до атрибутів якості.
Як приклад можна навести реальну вимогу, присутню в реальному проекті з електронного документообігу: "Система повинна проводити пошук документів <певного виду> за час, не перевищує 5 секунд". Це типова вимога з кількісною оцінкою, в якому визначена верхня межа діапазону часу, за який повинен бути здійснений пошук документів. Безсумнівно, цей атрибут якості системи існує в контексті певної функціональної вимоги про можливість пошуку документів за певними критеріями. І цей контекст або зв'язок має бути визначений або явно, в рамках ієрархії вимог, або за допомогою трасування, між вимогами різних видів (функціонального і атрибуту якості). Примітно, що Вігерс у своїй книзі виділяє вимоги по продуктивності системи в окремий вид вимог, тим не менше входять у поняття нефункціональних вимог або атрибутів якості.
 
1.6 Системні вимоги і програмні вимоги (System Requirements and Software Requirements) - такий розподіл базується на визначенні "системи", поданому INCOSE (International Council on Systems Engineering) "комбінація взаємодіючих елементів <створена> для досягнення певних цілей; може включати апаратні засоби, програмне забезпечення, вбудоване ПЗ, інші кошти, людей, інформацію, техніки (підходи), служби та інші підтримуючі елементи "; таким чином, мається на увазі, що система є більш змістовним поняттям, ніж програмне забезпечення і включає оточення, в якому функціонує ПЗ, таке, яким воно є, звідси, природним чином, випливають вимоги до системи в цілому і програмного забезпечення (або програмної системі), зокрема. Часто в літературі з управління вимогами зустрічається опис системних вимог як "користувацьких вимог" (user requirements), SWEBOK обмежує застосування поняття "Користувацька вимога" вимогами до системи кінцевих користувачів/замовників. Системні вимоги по SWEBOK, в свою чергу, оточують Користувацькі вимоги (або вимоги інших зацікавлених осіб - stakeholders, наприклад, регулювання повноважень) без вказівки ідентифікованого джерела-людини.
 
2. Процес роботи з вимогами (Requirements Process)
 
Дана секція вводить процеси, що стосуються питань роботи з вимогами, і певною мірою "зшиває" в єдине ціле решту п'ять секцій галузі знань, присвяченої вимогам до програмного забезпечення.Мета даної теми, згідно SWEBOK, дати розуміння того, що таке процес роботи з вимогами, як такої. У російській мові також стійко використовується його назву як "процес визначення вимог". ми його будемо використовувати взаємозамінним чином, маючи на увазі весь процес роботи з вимогами по SWEBOK. Що ж, розглянемо структуру декомпозиції тим процесу роботи з вимогами.
2.1 Модель процесу визначення вимог:
• Не є дискретною; це постійно діючий процес на всіх етапах життєвого циклу програмного забезпечення. Процес роботи з вимогами ініціюється на початку проекту і триває протягом усього життєвого циклу, аж до завершення проекту. Наприклад, функціональні тести створюються відповідно до функціональних вимог до програмної системи і зазвичай виконуються, в тому числі, при проведенні приймальних випробувань. Як ви вже помітили, автор використовував все ж "робота з вимогами" для акцентування уваги на тому факті, що вимоги не тільки "визначаються" на початкових етапах робіт, але й модифікуються і використовуються у всьому життєвому циклі.
• Ідентифікує програмні вимоги як елементи конфігурації (в термінах конфігураційного забезпечення) і контролює їх з використанням тих же практик конфігураційного управління, що і для інших активів програмних проектів (наприклад, файлів або запитів на зміни).
• Вимагає адаптації до проектного та/або організаційного контексту, в рамках якого ведеться відповідний програмний проект.
Зокрема, тема процесу визначення вимог стосується тих питань, які охоплюються в рамках збору, аналізу, специфікації і затвердження вимог з точки зору організації цих видів діяльності для різних типів проектів і значимості тих чи інших обмежень по відношенню до процесу. У більшості випадків, процес визначення, роботи з вимогами виділений в самостійний набір і описаний як послідовність (сценарії) дій, пов'язаних з ними ролей і безпосередніх результатів (їх часто називають "артефактами", наприклад, в RUP - Rational Unified Process), в рамках конкретних методологій розробки програмного забезпечення.
 
2.2 Учасники процесів (Process Actors)
У цій темі вводиться поняття "ролі" і дається розуміння "ролей" для людей, які беруть участь в процесі роботи з вимогами (відчуваєте відмінність між "визначенням" вимог і "роботою" з ними?). Таких людей також називають "зацікавленими особами" (в даному контексті - software stakeholders). Зацікавлена ​​особа - хтось, що має можливість (у тому числі, матеріальну) вплинути на реалізацію проекту/продукту.
Типові приклади ролей:
• Користувачі (Users): група, що охоплює тих людей, хто буде безпосередньо використовувати програмне забезпечення, користувачі можуть описати завдання, які вони вирішують (планують вирішувати) з використанням програмної системи, а також очікування стосовно атрибутам якості, які відображаються в призначених для користувача вимоги.
• Замовники (Customers): ті, хто відповідають за замовлення програмного забезпечення, або, в загальному випадку, є цільовою аудиторією на ринку програмного забезпечення (утворюють цільовий ринок ПЗ);
Стандарт 12207 (його огляд буде приведений в іншій главі) визначає більш звужене поняття " замовника "(зверніть увагу - acquirer, а не customer, хоча часто обидва терміни переводяться на російську мову однаково) як організацію, яка купує або отримує систему, програмний продукт або програмну послугу від постачальника. Тут можливо використовувати таке загальне визначення: замовник - особа або організація, які отримують пряму або опосередковану вигоду від використання продукту. Клієнтами вважають тих зацікавлених осіб, хто вимагає, оплачує, вибирає, використовує або отримує результати роботи програмного забезпечення. У цьому плані, "замовник" у розумінні стандарту 12207 скоріше ближче до "клієнту" в такій інтерпретації.
• Аналітики (Market analysts): продукти масового ринку програмного забезпечення (як і інших масових ринків, наприклад, побутової техніки) не мають "замовниками" в розумінні персоніфікації тих, хто "замовляє розробку. У той же самий час, особи, відповідальні за маркетинг, потребують ідентифікації потреб та обігу до тих, хто може грати роль <кваліфікованих> "представників" споживачів;
• Регулятори (Regulators): багато областей застосування ("домени") є регульованими, наприклад, телекомунікації або банківський сектор. Програмне забезпечення для низки цільових ринків (у першу чергу, корпоративного сектора) вимагає відповідності з керівними документами та проходження процедур, визначених уповноваженими органами.
• Інженери з програмного забезпечення, інженери-програмісти (Software Enginner): особи, що володіють обгрунтованим інтересом до розробки програмного забезпечення, наприклад, повторному використанню тих чи інших компонент, бібліотек, засобів і інструментів. Саме інженери відповідальні за технічну оцінку шляхів вирішення поставлених завдань та подальшу реалізацію вимог замовників. SWEBOK особливо підкреслює, що якщо неможливо в точності (в оригіналі - "perfectly") задовольнити вимоги кожного зацікавленої особи, саме робота інженера включає проведення переговорів і пошук компромісу, прийнятного для ключових зацікавлених осіб ("стейкхолдерів") і задовольняє бюджетним, технічним, тимчасовим та іншим обмеженням проекту. Необхідно розуміти, що така діяльність практично напевно призведе до змін у вимогах, як мінімум, на рівні відповідних пріоритетів вимог і, отже, робіт з їх реалізації.
2.3 Управління та підтримка процесів (Process Support and Management)
Ця тема зачіпає питання розподілу ресурсів, необхідних для здійснення проектної діяльності, встановлюючи контекст для першої секції "Ініціація і визначення змісту" (Initiation and Scope Definition) галузі знань "Управління в програмної інженерії" (Software Engineering Management). Основна мета даної теми - забезпечення зв'язку між процесами та діяльністю, визначеними в 2.1 "Моделі процесу визначення вимог" і питаннями використання проектних ресурсів - вартістю, людськими ресурсами, інструментами і т.п.
2.4 Якість та поліпшення процесів (Process Quality and Improvement)
Ця тема пов'язана з оцінкою якості процесів роботи з програмними вимогами і поліпшенням цих процесів. Особливе значення даної теми полягає у підкресленні значимості роботи з вимогами, ключової ролі цих процесів для визначення вартісних і часових ресурсів, необхідних для реалізації програмного проекту в цілому.
Задоволення потреб замовника є метою будь-якого програмного проекту. Відповідно, забезпечення адекватності реалізації вимог у проекті просто неможливо уявити без адекватних процесів роботи з ними - починаючи зі збору вимог, закінчуючи перевіркою відповідності отримуваного програмного продукту цим вимогам на всіх етапах його створення.
Покращення процесів і зокрема процесів розробки та управління вимогами повинно передувати формулюванням проблеми. Тобто немає сенсу займатися поліпшенням заради поліпшення, потрібно чітко розуміти яка в даний час є проблема в роботі з вимогами, і наскільки ця проблема значима, і тільки потім приступати до її усунення, зокрема через поліпшення процесів. Реальна вітчизняна практика багатьох організацій, що займаються розробкою ПО, показує, що дуже небагато мають дійсно чітке уявлення про те, яким чином організація роботи з вимогами може вплинути на успіх компанії в цілому. Зазвичай, вітчизняні компанії, в кращому випадку просто документують вимоги, випускаючи документи, наприклад, Технічне завдання по ГОСТ. Але навряд чи в цьому документі можна побачити вимоги - на жаль. Дотримуючись тільки рекомендацій, які є в ГОСТ можна тільки відповідним чином оформити розділи, що практично ніяк не впливає на якість та інформативність документа. Питання вдосконалення процесів - process improvement будуть розглядатися як в розділах, присвячених CMMI, так і в інших частинах цієї книги.
Дана тема тісно пов'язана з областями знань "Якість програмного забезпечення" (Software Quality) і "Процес програмної інженерії" (Software Engineering Process). У цьому контексті фокуси обговорюваної теми - визначення атрибутів і метрик якості, а також визначення відповідних процесів в застосуванні до програмних вимог, які можна звести в три групи практик:
• Покриття процесів роботи з вимогами з точки зору стандартів і моделей поліпшення процесів, в цілому;
• Вимірювання та кількісна оцінка (benchmarking) процесів роботи з вимогами;
• Планування і реалізація процесу покращення, як такого
Прослушать
 
3. Витяг вимог (Requirements Elicitation)
 
Дана секція висвітлює питання збору вимог як з точки зору організації процесу, так і визначення джерел, звідки надходять вимоги. Це перша стадія побудови бачення автоматизованої проблемної області. Ідентифікація зацікавлених осіб, їх взаємодії, виконуваних ними бізнес-процесів - все це є ключовими питаннями, без чіткої й однозначної відповіді на які навіть не варто думати про успішність проекту (до речі, не тільки програмного ...).Один з ключових принципів програмної інженерії полягає в забезпеченні взаємодії між користувачами та інженерами. Перш ніж починається розробка програмного забезпечення, саме фахівці "за вимогами" - аналітики перекидають той самий "місток" між замовниками та виконавцями, який задає той рівень комунікацій і взаєморозуміння між ними, який необхідний для вирішення завдань проекту.
3.1 Джерела вимог (Requirement Sources)
Необхідно ідентифікувати всі можливі джерела вимог, значимі для вирішення завдань проекту. Тільки після цього можна визначити їх вплив на проект. Дана тема стосується питань розуміння інформованості джерел вимог і їх значимості.
Дана тема фокусується на:
• Цілях
• Знаннях предметної області
• Зацікавлених особах
• Операційному оточенні
• Організаційному середовищі
Виділення пріоритетів, однозначність вимог, переданих інженерам, зв'язок між вимогами та їх взаємний вплив одна на одну - все це є наслідком чіткого і однозначного розуміння джерел вимог.
3.2 Техніки вилучення вимог (Elicitation Techniques)
Ідентифікувавши джерела вимог ми не повинні "спочивати на лаврах". Навіть володіючи розумінням того, хто володіє необхідною інформацією, ми далеко не застраховані від проблем, пов'язаних з отриманням вимог, необхідних для подальшої роботи. Здійснення своєї професійної діяльності користувачами далеко не гарантує, на жаль, здатність ясно, чітко і однозначно сформулювати те, що вони роблять, і що саме їм необхідно для вирішення їх завдань сьогодні і завтра. Багато в чому, через те, збір вимог, найчастіше, перетворюється в такий важкий і конфліктний процес дійсно-таки вилучення, "витягування" інформації, без якої неможливо переходити до подальших проектних робіт. Непорозуміння між аналітиком і користувачем, недогляд тих чи інших аспектів, що на перший погляд здаються другорядними, неоднозначність або тим більше некоректність інтерпретації інформації, отриманих від користувачів - все це найбільш типові причини "над-витрат" (часу, грошей і т.п.) , а іноді, і повного провалу проектів.
Існує безліч практик і підходів, що дозволяють добитися дійсно стрункої системи вимог, що відповідають реальним потребам і пріоритетам замовників. Серед них можна виділити наступні:
• Інтерв’ювання - традиційний підхід витягання вимог; не варто забувати, що отримання інформації від користувача "не дорівнює" отримання вимог; інформація повинна бути проаналізована і трансформована у вимоги, таким чином, інформація від користувача є "входом" в процеси збору вимог, а самі вимоги - "виходом" цих процесів;
• Сценарії - контекст для збору користувацьких вимог, що визначає відповіді на питання "що якщо" і "як це робиться" щодо бізнес-процесів, що реалізуються користувачами;
• Прототипи - відмінний інструмент для уточнення та/або деталізації вимог; існують різні підходи до прототипування - від "паперових" моделей до пілотних підсистем, що реалізуються як самостійні (в термінах управління ресурсами) проекти або бета-версії продуктів; часто прототипи поступово трансформуються в результати проекту і використовуються для перевірки і затвердження вимог;
• "роз'яснювальні зустрічі" - в оригіналі звучить як "facilitated meetings"; досить ємний за змістом термін, що прийшов із загальної практики менеджменту і базується на ідеях співробітництва зацікавлених осіб для спільного аналізу шляхів вирішення проблем, визначення та попередження ризиків і т.п. На відміну від "звичайного", з дозволу сказати, "мозкового штурму", як виняткової форми обговорення тих чи інших завдань (часто в критичні моменти робіт над проектом), "запланований мозковий штурм" - особлива форма зустрічей учасників проекту та зацікавлених осіб з боку замовника, присвячена обговоренню тих питань, відповіді на які не можуть бути визначені в результаті звичайних інтерв'ю і які вимагають залучення більшої кількості осіб, ніж просто пари "користувач-аналітик"; я дозволили собі сконструювати російською мовою цей термін ще і як "запланований мозкової штурм ", тому що такого роду зустрічі справді зазвичай плануються із заданою періодичністю для забезпечення однозначності інтерпретації інформації, значимої для проекту і, що дуже важливо - проведення таких зустрічей до того, як пов'язані з цими питаннями ризики не перетворилися на реальні проблеми, які потребують вирішення" вчора ", а, отже, і додаткових (спочатку незапланованих) ресурсів часу, грошей і т.д.;
• Спостереження (observation) - має на увазі безпосередню присутність аналітиків та інженерів поруч з користувачем в процесі виконання останнім його робіт із забезпечення функціонування бізнес-процесів: в певній мірі можна провести аналогію з практикою присутності представника замовника у проектній групі виконавця (типова практика в eXtreme Programming " on-site customer "-" присутній замовник "); дана техніка є досить витратною, але, в той же час, дуже ефективною, а іноді - просто незамінною, особливо, якщо мова йде про досить складних і взаємозалежних бізнес-процесах;
Існують і інші, досить ефективні практики, опис яких можна знайти в літературі і які ви, напевно, самі використовуєте у своїй роботі (наприклад, Requirements Workshop, Role Playing, Storyboarding і т.п.). Деякі з них будуть також згадуватися в контексті конкретних методологій.
 
4. Аналіз вимог (Requirements Analysis)
 
Ця секція присвячена процесам аналізу вимог, тобто трансформації інформації, отриманої від користувачів (та інших зацікавлених осіб) у чіткі і однозначні певні вимоги, передані інженерам для реалізації в програмному коді.
Аналіз вимог включає:
• Виявлення та вирішення конфліктів між вимогами;
• Визначення меж завдання, розв'язуваної створюваним програмним забезпеченням; в загальному випадку - визначення "scope" (або "bounds"), меж та змісту програмного проекту;
• Деталізація системних вимог для встановлення програмних вимог;
Практично завжди, хоча це явно і не зазначено в описі аналізу вимог як секції SWEBOK, на практиці виділяється і деталізація бізнес-вимог для встановлення програмних вимог. Наприклад, горезвісний режим роботи 24x7, сформульований у вигляді бізнес-вимоги, накладає досить жорсткі рамки на вибір технологічної платформи і архітектурних рішень, таких,  як технічні вимоги до розроблюваної програмної системи.
SWEBOK зазначає, що традиційний погляд на аналіз вимог часто сфокусований або зменшений до питань концептуального моделювання з використанням відповідних аналітичних методів, одним з яких є SADT - Structured Analysis and Design Technique (методологія структурного аналізу і техніки проектування), знайомий багатьом за нотаціям IDEF0 (функціональне моделювання - стандарт IEEE 1320.1), IDEF1X (інформаційне моделювання - стандарт IEEE 1320.2, відомий також як IDEFObject), часто вживаним як для моделювання бізнес-процесів, так і структур даних, зокрема - реляційних баз даних.
Так чи інакше, незалежно від засобів вираження, які є лише інструментом аналізу та фіксування результатів, результатом аналізу вимог повинні бути однозначно інтерпретовані вимог, реалізацію яких можна перевірити, а вартість і ресурси - передбачувані.
4.1 Класифікація вимог (Requirements Classification)
Вимоги можуть класифікуватися по цілому ряду параметрів, наприклад:
• Функціональні та нефункціональні вимоги
• Внутрішні (з іншими вимогами) або зовнішні залежності
• Вимоги до процесу або продукту
• Пріоритет вимог
• Зміст вимог щодо конкретних підсистем створюваного програмного забезпечення
• Змінність/стабільність вимог
Інші варіанти класифікації можуть, і часто базуються на прийнятих в організації підходах, що застосовуються методологіях, методах і практиках, а, найчастіше, і специфіці проектів і навіть вимоги замовників до процесу розробки і, зокрема, визначення вимог і формою представлення результатів їх аналізу.
4.2 Концептуальне моделювання (Conceptual Modeling)
Розробка моделі проблеми реального світу - ключовий елемент аналізу вимог. Мета моделювання - розуміння проблеми, завдання і методів їх вирішення до того, як почнеться рішення проблеми.Часто доводиться чути, що прагматичність підходу щодо програмних проектів полягає в "пропуску" етапу (або стадії, фази) моделювання. У свою чергу, часто ставлять знак рівності між моделюванням і "цими красивими квадратиками зі стрілочками". Ні те, ні інше твердження неправильні. Наприклад, в XP і в інших гнучких (Agile) практиках існують і історії користувачів, і картки завдань, і процедури аналізу (зокрема, пов'язаних з ними "мозкових штурмів", як запланованих, так і, на жаль, не дуже), в результаті якого ми сформулювали завдання, високорівневі можливості - "фічі" продукту (feature - особливість), а також необхідні моделі (див. [Амблер, 2002]). Обсяг моделей, їх деталізація та засоби подання можуть бути різні. Їх вибір базується і/або диктується конкретним культурним контекстом організацій, залучених до проекту, і практик, що застосовуються проектною групою. Саме не форма, але сама ідея моделювання як спроба спростити і однозначно інтерпретувати на концептуальному рівні проблематику діяльності в реальному світі - обов'язкова складова як керування вимогами, так і програмної інженерії, в цілому.
Серед факторів, які впливають на вибір моделі, методу і деталізації її подання, ступеня пов'язаності з програмним кодом та іншими питаннями:
• Природа проблеми (проблемної області)
• Експертиза і досвід інженерів
• Вимоги замовника до процесу
• Доступність методів та інструментів
• Внутрішньокорпоративні стандарти і регламенти
• Культура розробки
У кожному разі, моделювання розглядається в програмному контексті, а не тільки з точки зору бізнес-завдань як таких, Це обумовлено необхідністю розуміння операційного та системного контексту, тобто оточення, в якому програмна система буде реально використовуватися і яке накладає свої, іноді досить жорсткі обмеження.
Питання моделювання тісно пов'язані з застосовуваними методами і підходами. Однак, приватні методи чи нотації, як зазначається в SWEBOK, так чи інакше дотримуються поширених в індустрії практик і тяжіють до тих форм, з якими пов'язаний накопичений досвід і підтверджені загальноприйнятою практикою знання. SWEBOK зазначає, що можуть бути розроблені різні види моделей, що включають потоки робіт і даних, моделі станів, трасування подій, взаємодії користувачів, об'єктні моделі, моделі структур даних, і т.п. До речі, саме така ситуація склалася з UML, яку все частіше сприймають, як загальноприйнятого або de-facto-стандарту в моделюванні і включає цілий комплекс моделей (в UML 2.0 включено 14 моделей, представлені в двох групах - статичні моделі і поведінкові), пов'язаних і об'єднаних загальною архітектурою, на основі концепції метамоделей.
На думку автора, сучасний стан стандарту UML (уніфікованої мови моделювання Unified Modeling Language, що розробляється консорціумом OMG - www.omg.org) версії 2.0, цілком дозволяє говорити про розширення його застосовності в "чистому" бізнес-моделюванні. На тлі багатства виражальних засобів, появи відповідного інструментального забезпечення роботи з UML 2.0, тривалої історії успішного застосування стандарту UML 1.x, інструментів на його основі і повсюдного використання UML в області об'єктно-орієнтованого аналізу і проектування не тільки аналітиками, але архітекторами і розробниками ПО , можна з упевненістю говорити про зміщення фокусу індустрії програмного забезпечення в сторону UML і відходу (як мінімум, часткового) від IDEF, у застосуванні до аналітичної діяльності. Темпи такої "міграції", зазвичай залежать від ступеня консервативності поглядів конкретних фахівців-аналітиків. Однак, тиск ринку, вимога уніфікації, зокрема, виразних засобів опису активів проектів в рамках всієї проектної команди - ті причини, по яких, на думку автора, аналітики не сприйняли UML-орієнтований тренд, можуть опинитися за бортом серйозних корпоративних ІТ-проектів . Навіть на тлі "неприйняття" UML деякими гравцями ринку, критична маса знань і практик по його застосуванню вже виявилася досить велика, щоб ігнорувати його застосування. У той же самий час, не варто сприймати UML як панацею - це стосується будь-якої технології, практики або підходу. Створений, активно розвивається і вже підтриманий індустрією стандарт BPMN - Business Process Management Notation (див. www.bpmi.org). Таким чином, все визначається конкретним "культурним" контекстом. Просто треба пам'ятати про це і залишатися "прагматиками", в позитивному розумінні цього слова, не втрачаючи креативності в повсякденній діяльності.
Необхідно зазначити, що на практиці спостерігається тенденція розділення питань визначення вимог і моделювання. Це, наприклад, помітно в сучасних методологіях, таких як RUP (Rational Unified Process), де робота з вимогами та моделювання/проектування – по суті дві різні дисципліни (про це ми будемо говорити у відповідному розділі).
 
4.3 Архітектурне проектування та розподіл вимог (Architectural Design and Requirements Allocation)
Вважається, що створення архітектури програмних рішень є обов'язковим елементом успішності таких проектів. Архітектурне проектування перекривається з програмним і системним дизайном (проектуванням) та ілюструє наскільки складно провести чітку грань між різними аспектами проектування. Дана тема роботи з програмними вимогами тісно пов'язана з секцією "Структура та архітектура програмного забезпечення" (Software Structure and Architecture) галузі знань "Проектування програмного забезпечення" (Software Design). У багатьох випадках, інженери діють як архітектори, тому що процеси аналізу і вироблення вимог залежать від програмних компонент, що створюються для вирішення поставлених заданими вимогами завдань, покликаних, в кінцевому рахунку, домогтися реалізації поставлених перед проектом цілей.
Архітектурне проектування дуже близьке до концептуального моделювання. Безпосереднє відображення бізнес-сутностей реального світу на програмні компоненти не є обов'язковим. Багато в чому тому й існує такий поділ між моделюванням і проектуванням. В принципі, можна говорити про те, що діяльність з моделювання більшою мірою стосується того, "що" треба зробити, а архітектура - "як" це буде реалізовано.
Існує ряд стандартів і загальноприйнятих практик, пов'язаних з архітектурним проектуванням. Серед них найбільш популярні:
• Стандарт IEEE 1471-2000 "Recommended Practice for Architectural Description of Software Intensive Systems"
• Модель Захмана - Zachman Framework (www.zifa.com)
• TOGAF - The Open Group Architecture Framework (www.opengroup.org/architecture/)
Важливо зауважити, що ні в якому разі не треба плутати архітектурні рекомендації (Architectural Guidelines) з практиками та стандартами архітектурного проектування. Одні (наприклад, Federal Enterprise Architecture Framework FEAF -!) Дають рекомендації з конкретних архітектурно-технологічним рішень. Інші концентруються саме на те, чому варто приділити увагу при створенні архітектури, як її описати і деталізувати, і що з себе представляє архітектура, як така (наприклад, ISO 15704 Industrial Automation Systems - Requirements for Enterprise-Reference Architectures and Methodologies).
 
5. Специфікація вимог (Requirements Specification)
 
На інженерному жаргоні та в термінології ряду методологій, устоявся термін "software requirements specification" (SRS) - специфікація програмних вимог. Для складних систем, насправді, існує цілий комплекс специфікацій, документів, які є результатом аналізу вимог, їх моделювання та архітектурного проектування. Ці документи систематично аналізуються, в них вносяться зміни, вони переглядаються і затверджуються. Найчастіше, для опису комплексних проектів (в частині вимог) використовуються три основні документи (специфікації):
• Визначення системи (system definition)
• Системні вимоги (system requirements)
• Програмні вимоги (software requirements)
 
5.1 Визначення системи (System Definition Document)
Даний документ, який часто називають як "специфікація користувацьких вимог" (user requirements specification) або "концепція" (concept <of operations>), описує системні вимоги. Зміст документа визначає високорівневі вимоги, часто - стратегічні цілі, для досягнення яких створюється програмна система. Принциповим моментом є те, що такий документ описує вимоги до системи з точки зору сфери застосування - "домену". Відповідно, виклад вимог в ньому ведеться в термінах прикладної області. Документ описує системні вимоги разом з необхідною інформацією про бізнес-процеси, операційному оточенні з точки зору бізнес-процедур і організаційних та інших регламентів. Прикладом стандарту для створення і структурування такого документа є IEEE 1362 "Concept of Operations Document".
 
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. Слабка формалізація бізнес-процесів. У документах перемішується опис бізнесу та вимоги до ПЗ, що приводить складнощів у розумінні суті і спільного розуміння як повинна бути спроектована система.
 
6. Перевірка вимог (Requirements Validation)
 
Визначення вимог безпосередньо пов'язано з процедурами перевірки (verification) та затвердження (атестації - validation, як це сформульовано в ГОСТ Р і ISO/IEC 12207). Взагалі кажучи, прийнято вважати, що вимоги описані не повністю, якщо для них не задані правила V & V (verification & validation - перевірка та атестація), тобто не визначені способи перевірки і затвердження. Процедури перевірки є відправною точкою для інженерів-тестувальників і фахівців з якості, що безпосередньо відповідають за відповідність отримуваного програмного продукту пропонованим до нього вимогам.
На жаль, як вже коментували вище, часто, у великих організаціях замість повноцінної перевірки суті і змісту документів, все зводитися до так званого "нормоконтролю" - коли перевірка документів вимог полягає у перевірці на дотримання прийнятих стандартів зовнішнього оформлення документа (відступи і розміри поля , підписи таблиць/малюнків і т.п.), але ніяк ні оцінки якості вимог. І абсолютно неправильно вважати такий "нормоконтроль" повноцінною перевіркою вимог.
Якщо стандарти життєвого циклу описують як правильно створювати продукт, то стандарти (в тому числі, внутрішньокорпоративні) відповідають за створення правильного продукту, тобто того продукту, який відповідає очікуванням користувачів та інших зацікавлених осіб.
Для досягнення цієї мети застосовується ряд практик, в тому числі, представлених нижче.
6.1 Огляд вимог (Requirements Review)
Один з поширених методів перевірки вимог - інспекція або огляд вимог. Суть його полягає в тому, що ряд осіб, залучених до проекту (для великих проектів - спеціально виділені фахівці), "вичитують" вимоги в пошуках необгрунтованих припущень, описів вимог, допускають численні інтерпретації, протиріч, неузгодженості, недостатньою мірою деталізації, відхилень від прийнятих стандартів і т.п. Питання огляду вимог, взагалі кажучи, мають безпосереднє відношення до теми якості, тому вони також описуються в галузі знань SWEBOK "Якість програмного забезпечення" (Software Quality) в темі 2.3 "Огляд та аудит" (Review and Audit).
6.2 Прототипування (Prototyping)
У загальному випадку Прототипування увазі перевірку інженерної інтерпретації програмних вимог і витяг нових вимог, невизначених або неясних на ранніх ітераціях збору вимог. Існує безліч підходів до прототипування, як з точки зору деталізації, так і того, чому приділяється увага при прототипуванні. Найбільш часто прототипи створюються для оцінки способу реалізації користувацького інтерфейсу і перевірки архітектурних підходів і рішень.
При всій безумовній корисності прототипування для забезпечення перевірки вимог та рішень, необхідно розуміти, що з прототипуванням пов'язаний ряд проблем, здатних привести до негативних наслідків або, як мінімум, роботит, що вимагає додаткового часу та коштів. Серед можливих негативних наслідків прототипування варто виділити наступні:
• Зміщення уваги з цільових функцій прототипу і, як наслідок, незадоволеність користувачів огріхами прототипу, відсутністю стоїть за ним реальної функціональності (для прототипів користувацького інтерфейсу), помилками в прототипі і т.п.
• Перетворення прототипу в реальну систему за рахунок постійного додавання нових властивостей і функціональності "для перевірки" - часто буває порушена архітектурна цілісність, незабезпеченими необхідна масштабованість і якість одержуваного програмного продукту;
Тут автори хотіли б додати і ще одну типову проблему - переключення уваги зацікавлених осіб на ергономіку і деталі дизайну графічного інтерфейсу, при початковій меті побудови прототипу для виявлення функціональних та інших вимог і навпаки. Проблема не в увазі користувача інтерфейсу, проблема в підміні, якщо так можна висловитися, функціональної складової користувача інтерфейсом (згадайте, як часто ви самі говорили або чули - "я не про" кнопочки "і" віконця ", я про завдання ..." ). Звичайно, ясно, що ці фактори можна перетворити і в позитивні сторони прототипу. Крім того, не варто вважати що прототип це завжди щось, втілене в код. Прототипом для користувача інтерфейсу може бути, наприклад, просто "промальований" на папері або в електронній формі набір переходів між екранами/діалоговими вікнами системи (до речі, це підхід, що часто використовується в Agile-практиках, але аж ніяк не замінює вимог до системи).
Так чи інакше, вибір того чи іншого методу прототипування, та й самого факту такого способу перевірки вимог або технологічних ідей, повинен грунтуватися на тимчасових та інших наявних ресурсах, досвіді в прототипуванні і, звісно, ступеня складності створюваної програмної системи.
6.3 Затвердження моделі (Model Validation)
Затвердження або атестація моделі пов'язана з питаннями забезпечення прийнятної якості продукту. Впевненість у відповідності моделі заданим вимогам може бути закріплена формально з боку користувачів/замовника. У той же час, перевірка і атестація моделі, наприклад, об'єктно-орієнтованого зображення бізнес-сутностей і зв'язків між ними може бути перевірена з тим або іншим ступенем використання формальних методів, наприклад, статичного аналізу (пошук зв'язків та шляхів взаємодії між описаними об'єктами і виділення різного роду невідповідностей). Це - інша сторона затвердження моделі.
6.4 Приймальні тести (Acceptance Tests)
Вимоги повинні бути верифіковані. Вимоги, які не можуть бути перевірені і атестовані (затверджені) - це всього лише "побажання". Саме так вони буду сприйматися розробниками, навіть у разі їх високої значимості для користувачів. Якщо описана вимога не супроводжується процедурами перевірки - в більшості випадків говорять про недостатню деталізацію або неповний опис вимоги і, відповідно, специфікація вимог повинна бути відправлена ​​на доопрацювання, і, якщо необхідно, необхідно вжити додаткові зусилля, спрямовані на збір вимог.
Можна говорити про те, що процедура аналізу вимог вважається виконаною лише тоді, коли всі вимоги, включені в специфікацію, володіють методами оцінки стану відповідності їм створюваного програмного продукту. Найчастіше таке суворе обмеження на ступінь завершеності специфікації накладається на функціональні вимоги і атрибути якості (наприклад, час відгуку системи).
Ідентифікація та розробка приймальних тестів для нефункціональних вимог часто виявляється найбільш трудомістким завданням. Для її вирішення зазвичай "шукають точку опори", тобто можливість погляду на описувані вимоги з кількісної точки зору, впритул до переформулювання і більшої міри деталізації опису таких вимог.
Додаткова інформація, пов'язана з приймальними тестами представлена ​​в галузі знань SWEBOK "Тестування програмного забезпечення" (Software Testing) в описі 2.2.4 "Тести відповідності" (Conformance testing).
 
7. Практичні переконання (Practical Considerations)
 
Перший рівень декомпозиції секцій даної галузі знань нагадує опис послідовності дій. Це, безумовно, спрощений погляд на процес роботи з вимогами. Даний процес, точніше, комплекс процесів, охоплює весь життєвий цикл програмного забезпечення. Управління змінами та супровід, підтримка актуальності вимог і їх реалізації - ключ до успішних процесів програмної інженерії.
Далеко не кожна організація має культуру документування та управління вимогами. Особливо часто це зустрічається в молодих невеликих компаніях, які виводять на ринок нові продукти і володіють "сильним vision-ом", чітким розумінням цілей, для яких створюється продукт, але не мають достатньо ресурсів і, багато в чому тому що вважають, що динамізм - запорука успіху. Поступово такі компанії виростають, проекти - ускладнюються і, як наслідок складається ситуація, коли відстежити всі необхідні вимоги в неформальній формі вже просто неможливо. Ця тема практично невичерпна. Багато середніх за масштабами компаній намагаються зберегти той же рівень гнучкості і динамізму, який застосовувався в часи народження компанії, коли вона ще була "стартапом" (start-up - назва молодих компаній, які розкручували свої проекти за часів інтернет-буму кінця 90-х і яке прижилося для новоутворюваних малих бізнесів, що ростуть не стільки на зовнішніх інвестиціях, скільки на ідеях і завзятості її творців). Так чи інакше, динамізм притаманний не тільки компаніям, але й продуктам, самим вимогам до них. Управління змінами, концепцією, баченням продукту не може бути хаотичним - історія індустрії однозначно це доказує. Тому ставлення до управління вимогами як до постійно діючого бізнес-процесу - абсолютно обгрунтований підхід, що вимагає застосування певних практик. В іншому випадку, ми практично гарантовано зіткнемося із вкрай негативними наслідками, які не раз описувалися і згадувалися вище.
7.1 Ітеративна природа процесу роботи з вимогами (Iterative Nature of the Requirements Process)
У більшості випадків розуміння та інтерпретація вимог продовжують еволюціонувати в процесі проектування і розробки програмного забезпечення. Крім того, вимоги часто змінюються в силу змін бізнес-контексту для якого створюється і в якому експлуатується програмне забезпечення. Необхідно розуміти неминучість змін і планувати кроки по зменшенню проблем, пов'язаних зі змінами. У той же самий час, сучасні практики гнучкої розробки говорять про те, що необхідно концентруватися тільки на тому, що вимагає уваги "прямо зараз", не закладаючись на попередження всіх можливих ризиків, у тому числі пов'язаних із змінами, включаючи зміни вимог. Говорити про те, який підхід - попередження або реагування є гарантовано призводить до успіху - складно сказати. Більше того, якщо хтось однозначно наполягає тільки на одній з ідей і повністю відкидає іншу - це профанація. Сприйняття змін та можливість їх своєчасної обробки - питання спроможності проектної команди працювати в умовах постійно мінливих умов, прийнятих архітектурних рішень і багатьох інших культурних, технологічних та організаційних чинників. Так чи інакше, розуміння мінливої ​​природи вимог - один із чинників адекватного реагування на самі зміни, а, отже, і можливості успішного завершення проекту.
 
7.2 Управління змінами (Change Management)
Управління змінами - одна з ключових тем управління вимогами. Необхідність визначення процедур для обробки змін зовсім не те ж саме, що і їх детальна формалізація. Такі процедури необхідні. Їм присвячена тема управління змінами в додатку до вимог. У той же час, розглядати зміну вимог окремо від інших процесів, щонайменше здається дивним. Відповідно, дане питання є складовою частиною управління змінами та конфігураціями програмного забезпечення (Software Configuration and Change Management, SCCM), яке сьогодні прийнято називати просто конфігураційним управлінням (Software Configuration Management, SCM), маючи на увазі, що це не тільки питання контролю версій, але й управління всіма активами проекту, включаючи код, вимоги, запити на зміни - change requests (у тому числі, звіти про помилки - defect чи bug reports), завдання (в термінах проектного менеджменту) і т.п. Загальний комплекс питань конфігураційного управління розглядається в галузі знань SWEBOK "Управління конфігураціями програмного забезпечення" (Software Configuration Management).
 
7.3 Атрибути вимог (Requirements Attributes)
Вимоги повинні складатися не тільки з опису того, що необхідно зробити, але й містити інформацію, необхідну для інтерпретації вимог і управління ними. Наприклад, з одними вимогами часто асоціюють сценарії Use Case (як у текстовому, так і графічному представленні) і, в той же час, функціональні вимоги часто трансформуються в завдання в термінах проектного управління, з якими пов'язані параметри закінченості (наприклад, у відсотках), відповідальності (наприклад, хто є "власником" вимоги, хто з інженерів призначається виконавцем або бере на себе обов'язки, пов'язані з реалізацією заданої функціональності, як це прийнято, наприклад, в XP або FDD). Прикладів існує багато і, в залежності від застосовуваних практик і методів, що склалася проектної та організаційної культури, спектр атрибутів може змінюватися досить широко, практично необмежено.
Необхідно також пам'ятати, що до обговорюваних атрибутів також відносяться параметри, пов'язані з класифікацією вимог (див. вище тему 4.1 "Класифікація вимог"). У свою чергу, приналежність до того чи іншого класу (категорії, типу, виду) вимог означає не тільки семантику того, "чому присвячені" вимоги (функціональності, параметрам якості тощо), а й комплекс атрибутів, загальний для всіх вимог даного класу.
На думку авторів, можна провести паралель між вимогами та записами (рядками) в реляційній базі даних, де кожен запис має набір атрибутів (стовпців). У певному сенсі, можна і необхідно говорити про той чи інший рівень атомарності вимог (що не виключає зв'язків між вимогами), що подається такою метафорою.
 
7.4 Трасування вимог (Requirements Tracing)
Трасування вимог забезпечує зв'язок між вимогами та відстеження джерел вимог. Трасування є фундаментальною основою проведення аналізу впливу (impact analysis) при зміні вимог, допомагаючи передбачати ефект від внесення таких змін. Трасування передбачає спрямований зв'язок (подається у вигляді складного спрямованого ациклічного графа) між вимогами, тобто залежності.
Вимоги (B) аолодіють зворотною залежністю (тобто вторинні) по відношенню до вимог (A) і зацікавлених осіб, які є джерелом або утворюють причину появи аналізованих вимог (B). І, навпаки, вимоги (A) трасуються безпосередньо до тих вимог (B) і елементів дизайну (наприклад, моделі або, в загальному випадку, коду, запитів на зміни і т.п.), які породжуються або задовольняють вимогам (A).
 
7.5 Вимірювання вимог (Measuring Requirements)
З практичної точки зору, звісно, корисно мати щось, що дозволяє визначити "обсяг" вимог для заданого (створюваного) програмного продукту. Це число корисно для дослідження "масштабів" змін у вимогах, оцінки вартісних характеристик (cost estimation) розробки та підтримки програмної системи, опосередковано - оцінки продуктивності розробки та ефективності підтримки на етапах реалізації вимог і внесення змін і т.п.
Вимірювання об'єму функціональності (Functional Size Measurement, FSM) техніка такого роду чисельної оцінки, визначена на концептуальному рівні в стандарті IEEE 14143.1. Стандарти ISO/IEC та інші джерела описують приватні методи FSM (наприклад, модель COCOMO II для оцінки вартості, наприклад, можуть використовуватися в тісному зв'язку з методами функціональних точок - functional points для оцінки масштабів функціональності, тобто вимог, поставлених до заданої програмної системи).
Додаткова інформація про стандарти та підходи в оцінці масштабів подана ​​в галузі знань "Процес програмної інженерії" (Software Engineering Process).
На додаток до практичних міркувань, представленим у SWEBOK, на тлі загальної тенденції розробки моделей <оцінки> зрілості, варто зазначити, що існують певні роботи і по створенню різних моделей зрілості вимог. Наприклад, найбільш популярна модель зрілості в індустрії програмного забезпечення - CMMI включає різний обсяг і зміст робіт з визначення і управління вимогами для рівнів зрілості 2 і 3.

Приложенные файлы

  • docx 789210
    Размер файла: 64 kB Загрузок: 0

Добавить комментарий