Сравнение бизнес-анализа и системного мышления

http://www.babokonline.org/

Резюме после пролистанных по диагонали 120 страниц.

Бизнес-анализ примерно соответствует инженерии требований. Главными артефактами работы аналитика, работающего на основе BABOK является гармонизированный набор требований и логической архитектуры решения.

Два ключевых отличия аналитика от инженера по требованиям:
1) Не используется прием абстрагирования системы как черного ящика с сервисом и интерфейсом, требованиями называются как требования, так и ограничения и архитектура;
2) Не рассматривается воплощение системы, работа аналитика завершается выпуском т.н. "архитектуры требований", которая состоит из гармонизированного набора требований и логической архитектуры. Модели привязаны (оттрассированы к модулям).

В чем системное мышление и бизнес-анализ схожи?

1. Работают со стейкхолдерами, сгруппированными по интересам. Каждому интересу предъявляют свой частный метод описания и частное описание.
2. Работают с потребностями, потребности фокусируют требования. Используется целеориентированная инженерии требований, есть трассировка от стейкхолдеров и их целей к требованиям и архитектуре. Требования рассматриваются как функциональный объект (альфа), с набором состояний.
3. Используется функциональная декомпозиция, требования трассируются к модулям.
4. Есть понятие платформы системы как набора типовых архитектурных решений

В чем системное мышление и бизнес-анализ различаются?

1. Требования и архитектура (requirements and designs) постоянно путаются и смешиваются. Прямо заявляется "Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle".
2. Состояния альфы "Требования" определяется по усмотрению, нет чек-листа для определения состояния требований.
3. Под верификацией БА подразумевает " Requirements (verified): a set of requirements that have been verified to be of sufficient quality to be used as a reliable body of work for further specification and development...Verify Requirements: ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality." Т.е., верификация требований в БА - это соответствие требований требованиям к требованиям.
4. Под валидацией БА подразумевает "Validate Requirements: ensures that a set of requirements or designs delivers business value and supports the organization's goals and objectives", т.е., валидация производится против требований к обеспечивающей системе.
5. Методы БА не могут быть рекурсивно использованы на любом уровне холархии системы. Системы задаются объективно. Холархия требований отсутствует.
6. Воплощение системы не рассматривается, жизненный цикл системы с выделенной стадией эксплуатации не используется, хотя стейкхолдеры из стадий использования и обслуживания заявлены.
7. Стейкхолдеры не рассматриваются в ролях, 4Д экстенсионализм к ним не применяется. Роль стейкхолдера фиксирована на исполнителе.
8. В БА платформы системы не содержит типовых интерфейсов и модулей.
9. БА использует пять аспектов рассмотрения системы "The perspectives included in the BABOK® Guide are:• Agile• Business Intelligence• Information Technology• Business Architecture• Business Process Management"
10. Функциональное разбиение используется по большей части при анализе оргпроцессов, не используется при модульном синтезе. Модульный синтез основан на фольклоре (мозговые штурмы, рабочие встречи), нет метода.
11. Логическая и физические архитектуры не связаны "Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.Business analysts use a requirements architecture to:• understand which models are appropriate for the domain, solution scope, and audience,• organize requirements into structures relevant to different stakeholders,• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,• ensure the requirements work together to achieve the overall objectives, and• make trade-off decisions about requirements while considering the overall objectives. Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)). Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work."