Анатолий Левенчук - Системное мышление

Стандарт описания требований ISO/IEC 29148:2011 подчёркивает то, что требования есть у каждого холона в холархии. Вот пример из этого стандарта:

Чтобы лучше понять этот пример, нужно «перевести с айтишного» слово business.

Стандарт ISO/IEC 29148:2011 даёт чёткое указание, что слово бизнес (business)тут просто условный термин, обозначающий просто организацию (organization): «The term business is used even though it could apply to not-for-profit organizations such as in the public sector. Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users’ environment».

Это относится не только к требованиям, но и ко многому другому. Так бизнес-процесс лучше называть организационным процессом.

Картинка очень неподробно и схематично показывает холархию какой-то организации, в которой внутри организационного окружения (organization environment) находится вся работающая организация (business operation), в которой содержится какая-то часть организации, работающая с системой (system operation), в которой есть система (system), в которой есть элемент системы (system element), в котором есть программное обеспечение (software). Каждый из указанных холонов в холархии имеет какие-то описания «чёрного ящика», называемые требованиями – и на картинке некоторые из них показаны зелёными стрелками, указывающими на границы соответствующих вложенных друг в друга систем-холонов.

Целевой системой тут является «система» (system), требования к ней так и называются: системные требования(system requirements).

Требования к использующей системе будут называться требования стейкхолдеров(stakeholder requirements) или потребности/нужды стейкхолдеров(stakeholder needs). Их не перепутать: они описывают разные системы на их границах (как «чёрный ящик», без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно.

Мы привели эту картинку для того, чтобы показать присутствие в проекте множества самых разных требований.

Нельзя считать, что в проекте есть только требования для целевой системы и потребности для использующей. Они, конечно, основные для рассмотрения, но обычно ситуация сложней, и выявлять приходится множество самых разных требований к самым разным системам из системной холархии, которые приходится учитывать в проекте.

Идея о том, что требования не «объективны», а их субъективно задают стейкхолдеры для того, чтобы достичь каких-то целей, не так уж стара.

В 1986 году Ивар Якобсон предложил технику выявления требований, при которой рассматриваются варианты использования (use cases) 136 136 https://en.wikipedia.org/wiki/Use_case .

Вариант использованияопределяет взаимодействие между пытающимися достичь своих целей внешними актёрами(actors) и целевой системой.

Актёры в вариантах использования (в других практиках термин актёр/актор/actor может означать совсем друге) это функциональные объекты, которые необязательно люди: они могут быть людьми, компанией или просто предпринятием, компьютерной программой, или даже компьютером.

Требования при анализе взаимодействия внешних актёров и системы легко выявлялись, и подход получил широкое признание в инженерии требований.

Вот типичная диаграмма вариантов использования 137 137 http://www.uml-diagrams.org/examples/online-shopping-use-case-diagram-example.html :

В 1995 году появился подход к моделированию требований, называемый i* 138 138 http://www.cs.toronto.edu/km/istar/ , и он продолжил идею взаимодействия актёров и системы для достижения своих целей. Упор был сделан не только на варианты использования системы актёрами, но и на описания взаимодействий самих актёров, а весь подход получил название целеориентированной инженерии требований(goal-oriented requirements engineering). В философии тех, кто может иметь свои цели, принято называть агентами(agents) – независимо от живой или неживой (например, системы искусственного интеллекта) природы этих агентов.

В i* приняли, что требования отражают цели, убеждения, возможности и договорённости агентов, окончательно признав социальную природу требований, их «необъективность»: «Agents attribute intentional properties (such as goals, beliefs, abilities, commitments) to each other and reason about strategic relationships. Dependencies between agents give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning approach. Agents consider alternative configurations of dependencies to assess their strategic positioning in a social context».

Был предложен язык для записи взаимодействий актёров, преследующих свои цели:

С тех пор моделями требований называют такие описания требований, которые включают не только сами модели требований, но и как-то описывают ситуации их возникновения, прежде всего участвующих актёров, достигающих своих целей. Конечно, самый частый вариант актёра – это стейкхолдер.

В 2008 году международный союз телекоммуникаций принял стандарт ITU-T Z.151 139 139 https://www.itu.int/rec/T-REC-Z.151/en , в котором для моделирования требований предлагался целеориентированный язык требований подхода i* (Goal-oriented Requirements Language) и карты вариантов использования (Use Case Maps). В простейшем случае вариант целеориентированной системной инженерии предполагает написание коротких пользовательских историй(user story), в которых актёр сведён до обычной стейкхолдерской роли. Пример формата таких историй 140 140 Mike Cohn, 2008, Advantages of the «As a user, I want» user story template, blog post, http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-userstory-template : « Я как _стейкхолдер_ хочу, чтобы _ целевая-система_ _формулировка требования _, для того чтобы _потребности-для-использующей-системы_ ».

Проверка и приёмка(verification and validation, V&V, верификация и валидация) служат для того, чтобы убедиться в работоспособности системы. По сути, это просто тщательное тестирование системы, проведение испытаний, обоснование успешности системы. Успешность – это соответствие ожиданиям стейкхолдеров. Стейкхолдеров же у нас два набора:

• внешние, которых волнует прежде всего работоспособность использующей системы. Работает ли использующая система с включением в её состав целевой системы как задумано, удовлетворяет ли требованиям стейкхолдеров/потребностям?

• и внутренние, которых волнует работоспособность целевой системы – работает ли целевая система как задумано, удовлетворяет ли системным требованиям?