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") задовольнити вимоги кожного зацікавленої особи, саме робота інженера включає проведення переговорів і пошук компромісу, прийнятного для ключових зацікавлених осіб ("стейкхолдерів") і задовольняє бюджетним, технічним, тимчасовим та іншим обмеженням проекту. Необхідно розуміти, що така діяльність практично напевно призведе до змін у вимогах, як мінімум, на рівні відповідних пріоритетів вимог і, отже, робіт з їх реалізації.