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".