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), де робота з вимогами та моделювання/проектування – по суті дві різні дисципліни (про це ми будемо говорити у відповідному розділі).