2024-09-02 22:14

Ограничения (Design and Implementation Constraints)

Бизнес-анализ

Сегодня хотелось бы поговорить об ограничениях (в значении “ограничения дизайна и реализации” — design and implementation constraints). Это будут рассуждения в вольном формате на тему этих весьма специфичных и редких в практике многих аналитиков требований, дабы понять, что об этом пишут знатоки, и поделиться своими мыслями на эту тему. Сталкиваюсь часто с тем, что этот вид требований сложен для аналитиков, в особенности для начинающих, а потому попробуем разобрать.

Для начала: что это вообще такое и какое место занимает в информации, которой оперируют аналитики?

Karl Wiegers and Joy Beatty — Software Requirements v. 3 (далее просто Вигерс):

A restriction that is imposed on the choices available to the developer for the design and construction of a product.

Переведем, но не дословно, а уразумения ради: Ограничение, налагаемое на спектр решений, доступных для разработчиков в контексте проектирования и разработки продукта.
Я подчеркнул важные вещи, которые мы чуть позже разберем. У Вигерса это подвид нефункциональных требований к решению. Вигерс в целом довольно щедро рассуждает на тему ограничений, и далее я этого коснусь.

BABOK v 3.0:

An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.

Переводить уже не буду, т. к. читатели, полагаю, привыкли к тому, что у нас тут в некоторой степени двуязычность. По сути, если начать философствовать, можно прийти к тому же, что и у Вигерса. Но это не точно — можно и к другим интерпретациям приплыть. Однако BABOK больше ничего полезного не глаголит об ограничениях, поэтому дальше плавать в пучинах догадок не будем.

CPRE Foundation Level Handbook (IREB):

Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality requirements.

Требования, которые ограничивают решение за пределами того, что необходимо (т. е. в дополнение к) для удовлетворения функциональных требований и требований к качеству . Т. е. это также требования, причем по смыслу это аналогично тому, что у нас было от дядюшки Карла выше. Стоит только отметить, что ограничения тут вынесены в самостоятельный вид в рамках местной классификации: т. е. есть Functional Requirements, Quality Requirements и Constraints.

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

В частности, что нам важно понять для этой заметки: есть требования (т. е. что нужно заложить в решение), а есть детали реализации решения / дизайны (обожаю этот перевод в контексте Requirements VS Designs) (т. е. как реализовать требования). Фича “Создание заказа” и ее функциональные и качественные детали, важные для стейкхолдеров — это требования. Код и как его написать, структура БД и прочие девелоперские решения (и тут внимание: мы не ограничиваемся только разработчиками — возьмем лучше всю команду разработки — фронтендеры, бэкендеры, тестировщики, юиксеры, проектное управление — в общем, любой аспект разработки) для реализации данной фичи — это то, как реализовать эти требования. Это смежные области информации и принимаемых решений, и они могут пересекаться, т. е. иногда не очень понятно, что и куда отнести, и это зависит от команды и принятых в ней процессов (читаем упомянутую выше статью):

В идеальном мире заказчик и прочие внешние по отношению к исполнителю стейкхолдеры — источники требований и именно требований. Им важно (и нам от них важно узнать) “что”. За “как” отвечает команда разработки — они эксперты. Т. е. “Чуваки, не лезьте сюда: мы сами решим, как разработать то, что вам нужно. Вы нам за это деньги платите. Вам же ведь не таблица “Заказы” в базе данных нужна, агась? Вам нужно заказ мочь определенным образом создавать.” На самом деле, мы с вами знаем, что “что” мы собираем не только с людей — источниками требований могут быть бизнес-правила, документы, процессы, системы и прочие вещи, а не только то, что шевелится.

Фишка тут в том, что иногда внешние обстоятельства (внешние стейкхолдеры, законодательство, сторонние системы и прочие факторы за пределами исполнителя) могут лезть в “как”. Просто потому что имеют право. Этим самым они ограничивают креатив и спектр доступных опций для команды разработки в области designs. Это ни разу не идеальная для нас ситуация, потому что наша команда не любит, когда ей кто-то/что-то диктует, как работать. Но выбора как бы нет: заказчик платит деньги и заказывает музыку; государство волнуют явно не нежные чувства команды; сторонние сервисы, с которыми нам надо интегрироваться, диктуют свои правила в рамках оказываемой услуги и т. п. И, получается, кому это все узнать, как не нашему мостику, который занимается большей частью коммуникаций с внешним миром касательно решения?🙂

Взглянем на сабж еще так: ограничения — это такой крайне специфичный вид требований, который отражает то, как внешние обстоятельства или люди лезут не в требования. Вероятно, нужно время, чтобы это осело в голове 🙂

Примеры ограничений от дяди Карла с пояснениями:

CO-1: The system’s design, code, and maintenance documentation shall conform to the Process Impact Intranet Development Standard, Version 1.3.

Архитектура, код и документация (да-да, это также то, как разрабатывать систему — это часть процесса разработки) должны соответствовать какому-то внешнему (по отношению к исполнителю) стандарту. На самом деле не факт, что в примере у Карла это внешний стандарт — надо раскапывать, что там внешнее, а что — внутреннее, но в иной трактовке понимание рушится. Если это внутренние стандарты исполнителя, то это не ограничения — это свои же правила, которые являются частью внутренних решений.

CO-2: The system shall use the current corporate standard Oracle database engine.

Тут нас (исполнителя) ограничили в используемой СУБД.

CO-3: All HTML code shall conform to the HTML 5.0 standard.

Нас ограничили в том, как писать HTML-код.

Также у Вигерса есть интересное пояснение такого рода:

Requirements that incorporate or are written in the form of solution ideas rather than needs are imposing design constraints, often unnecessarily, so watch out for those.

Тут говорится о том, что как только стейкхолдер бомбит не требованиями, а решениями, это становится ограничениями. Таки да. Что это значит для нас, нашего процесса и команды, мы определяем сами, но факт в том, что полезным будет такое определить. Например, как описано было в заметке, на которую я ссылался выше, частая типовая “серая” область на стыке Requirements и Designs — UI. В целом, большинство склоняется к тому, что UI — это “как”, а не “что”. То есть стейкхолдеры не должны в идеальном сферическом вакууме хотеть конкретный UI — они могут качественные требования к нему предъявлять (удобство, скорость и пр.), но не конкретную реализацию. Такие вещи полезно понимать и учитывать, потому что у вас в команде, как правило, есть спецы, ответственные за UI и умеющие его круто колбасить. Может быть, это как раз вы как аналитик, и это вполне ок — вы тоже часть dev team. Суть тут в том, что общаясь с пользователем Васей, тот может сказать: “А вот тут я хочу нажать на ссылку, чтобы создать заказ”. И вам тут стоит действовать не как с требованиями любого иного плана (”Ага, пасиб, учтем, насыпай еще!”), а как с ограничением: 1) услышали, 2) спросили, а какого икса именно так (”Мы тут эксперты, чел. Тебе прямо принципиально это ссылкой делать? Почему, если да? А может все-таки оставишь конкретный контрол нашим экспертам aka умным людям?”), 3) если ограничения не избежать (а в случае Васи оно может вполне быть избегаемым — не он принимает окончательные решения по требованиям), то передать нашему дизайнеру со словами “Ну а тут вот так и никак иначе — сорян, брат.”, 4) если же убедили Васю, что не стоит ставить палки в колеса специалистам (как вариант, сразу предложив более приятственные ему решения), то ничего не делаем.

Что еще Вигерс пишет об ограничениях (и далее я дерзну не со всем согласиться — вполне может быть, что я еще не дорос до верного понимания — кстати, буду рад обсудить в комментариях в канале, если есть, где поправить).

Sources of constraints include: ■ Specific technologies, tools, languages, and databases that must be used or avoided.

Да, если это не внутренние решения команды, а прилетает извне.

■ Restrictions because of the product’s operating environment or platform, such as the types and versions of web browsers or operating systems that will be used.

Тут не согласен. Требования к операционной среде — это часть требований к решению. Не внешние обстоятельства, а часть решения. И если требования диктуют принимаемые командой решения по реализации, то это обычный процесс разработки. Требования вообще-то склонны себя так вести, как говорит кэп. Ок, нам надо поддерживать Google Chrome в качестве браузера — дальше, значит, будем просто это реализовать, сами выбрав “как” и учтя, на что это может повлиять. Неясно, чем подобное отличается от учета наличия какой-нибудь фичи по требованиям.

■ Required development conventions or standards. (For instance, if the customer’s organization will be maintaining the software, the organization might specify design notations and coding standards that a subcontractor must follow.)

Именно, йеп. В скобках приведено важное пояснение, делающее описанное ограничением.

■ Limitations or compliance requirements imposed by regulations or other business rules.

Да, бизнес-правила (например, законодательство в области хранения данных в отдельно взятом домене и стране) — легитимные источники ограничений.

■ Interfaces to other existing systems, such as data formats and communication protocols.

Да: если нам надо с чем-то взаимодействовать, это что-то может наложить ограничения на то, как мы, например, храним эти самые передаваемые данные у себя. Сторонний сервис может сказать, что, мол, мы готовы открыть вам API, только если на вашей стороне данные клиента хранятся именно в таком зашифрованном формате.

■ Restrictions because of the size of the display, as when running on a tablet or phone.

Не согласен — по той же логике, что и ранее. Размеры экрана — это операционная среда. Если мы делаем систему для айфона, то его размер и прочие параметры — это требования к тому, где система будет устанавливаться и запускаться. Порождают ли эти аспекты определенные решения от разработчиков? Да, конечно, как и любые прочие требования. Внешнего фактора я тут не вижу.

Это не все, но самые интересные и яркие, на мой взгляд, области из труда Вигерса.

И еще немного примеров от него же, которые хороши:

CON-1. The user clicks at the top of the project list to change the sort sequence. [specific user interface control imposed as a design constraint on a functional requirement]

CON-2. Only open source software available under the GNU General Public License may be used to implement the product. [implementation constraint]

CON-3. The application must use Microsoft .NET framework 4.5. [architecture constraint]

CON-6. All textual data used by the application shall be stored in the form of XML files. [data constraint]

Однако… вот еще один отрывок:

Note that some of these constraints exist to comply with some perhaps-unstated quality expectation. Ask why each constraint is imposed to try to reach that underlying quality requirement. Why must open-source software be used, as stated in CON-2? Perhaps because of a desire for increased modifiability, so that’s the requirement that leads to the constraint.

Тут я снова позволю себе поспорить с мэтром или попытаться его дополнить. А в чем ограничение-то? Если на базе требования к modifiability команда разработки приняла решение, описанное в CON-2, это уже не ограничение — это принятое командой разработки банальное решение о том, как разрабатывать выданное им требование. Если же это поступило не от команды, а от внешнего стейкхолдера, то: 1) копаем, чтобы узнать, почему именно так; 2) узнали, например, что стейкхолдер решил предложить свое решение на базе некой корневой потребности (связанной с modifiability); 3) отразили от него мысль, что раз именно расширяемость важна, то, может, мы сами как эксперты решим, как ее реализовать; 4) если убедили, то CON-2 не нужен как требования ни разу; 5) и только если не убедили, плюс обязаны этого придерживаться (т. е. у стейкхолдера есть подобный рычаг), только тогда это остается легитимным примером.

А вот что говорит об источниках IREB:

When specifying constraints, the following categories of constraints should be considered:
▪ Technical: given interfaces or protocols, components, or frameworks that have to be used, etc.
▪ Legal: restrictions imposed by laws, contracts, standards, or regulations
▪ Organizational: there may be constraints in terms of organizational structures, processes, or policies that must not be changed by the system.
▪ Cultural: user habits and expectations are to some extent shaped by the culture the users live in. This is a particularly important aspect to consider when the users of a system come from different cultures or when Requirements Engineers and developers are rooted in a different culture to the system’s users.
▪ Environmental: when specifying cyber-physical systems, environmental conditions such as temperature, humidity, radiation, or vibration may have to be considered as constraints; energy consumption and heat dissipation may constitute further constraints.
▪ Physical: when a system comprises physical components or interacts with them, the system becomes constrained by the laws of physics and the properties of materials used for the physical components.
▪ Furthermore, particular solutions or restrictions demanded by important stakeholders also constitute constraints.

Что вызывает некое смущение, так это выделенные курсивом пункты. Кажется, что Organizational — это обычные бизнес-правила, которые, будучи релевантными для решения, будут превращены аналитиком в требования. Где там ограничения в области designs? Ну то есть как некий аспект бизнеса, которому система должна соответствовать, становится не чем-то, что нужно заложить в требования, а лезет прямо в то, как систему надо колбасить команде в плане процессов и технических решений? Слабо представляю, но, вероятно, стоило бы примеры бы увидеть.
C Cultural аналогично: неужели user habits and expectations могут стать источником не требований к функциональности или качеству, а к процессу разработки и техническим решениям? Снова хорошо бы примеров в студию.

Если по итогу просуммировать:

Ограничения полезно понимать и работать с ними.

Без этого понимания дев-команда может только надеяться на то, что отловит где-то и когда-то подобные вещи, причем желательно, чтобы не очень поздно (когда еще, например, смена архитектуры не выльется в безумные превышения проектных параметров).
С этим пониманием и с аналитиком, надрессированным на эту работу, у команды будет список всего, что надо учесть в порыве безумного креатива.

Общий алгоритм работы с этим необычным видом требований:

1) узнать (подметить в процессе бесед или целенаправленно пройтись по чеклисту с наводящими вопросами; изучить законодательство; изучить API сторонних систем; подумать, где они в контексте проекта еще могут лежать),
2) убедиться, что они не избегаемы (а если избегаемые, то избежать), спрашивая “А точно есть такое ограничение? А что, если убрать?”
3) передать команде вместе с платочком, чтобы утереть слезы — как главу в SRS или отдельную страничку в Confluence.