Руководство по написанию требований INCOSE версии 4 только на первый взгляд не сильно отличается от предыдущей версии, для которой есть русский перевод. На уровне источников требований есть одно принципиальное различие: теперь главным, самым верхним источником считаются "концепции жизненного цикла". Это новое понятие, в предыдущей версии всё начиналось со стратегии компании, а потом шли интересы стейкхолдеров.
Давайте разбираться. Во-первых, кроме Руководства по написанию требований у INCOSE теперь есть ещё один документ: Needs and Requirements Manual (NRM), выпущенный в 2024 году, то есть совсем свежий. Почему один из них guide, а другой manual, и как это адекватно перевести на русский, непонятно. Видимо, дело в размере — guide всего 140 страниц, а manual — почти 500!
Во-вторых, в мануале есть детальное объяснение всей используемой онтологии. Руководство её только использует.
Всё начинается с Сущности (Entity). Сущность — это то, к чему применяется концепция, потребность или требование. Сущности бывают трех типов:
— физические или программные (системы или части систем),
— процессные (включая сюда модели и рабочие инструкции),
— бизнес или люди (тут могут быть компании, подразделения или роли).
Следующее понятие: Концепт (или концепция, concept): текстовое или графическое представление, которое кратко выражает, как именно сущность может решить проблему, устранить угрозу, реализовать возможность, миссию, цели, задачи и меры, для решения которых она предназначена.
Идея решения, короче.
Ещё раз: в мануале от крупного индустриального сообщества инженеров написано черным по белому, что всё начинается с идеи решения, а не интересов или требований.
На самом деле, это ещё в ГОСТ 34.601—90 написано, но кто ж его читал. И в ГОСТ Р 59793—2021 повторено. Если вас в следующий раз попросят всё "по ГОСТу" делать, вы людям этот самый ГОСТ покажите, там начинается всё не с ТЗ, а с обследования, формирования пользовательских требований и разработки вариантов концепции АС (нескольких!). А ТЗ — это третья по счету стадия, перед ним ещё 2 стадии и 8 этапов работ, на минуточку.
Концепции, из которых проистекают потребности, берутся не любые, а именно концепции жизненного цикла. Правда, не уточняется — ЖЦ чего именно. Судя по этапам — сущности. То есть, как организация собирается управлять, приобретать, проектировать, разрабатывать, строить/программировать, интегрировать, верифицировать, валидировать, передавать, инсталлировать, эксплуатировать, поддерживать, обслуживать и выводить из эксплуатации сущность.
Кажется, из всего этого аналитик обычно думают про эксплуатацию и в последнее время про интеграцию.
В общем, у нас на каждый этап жизненного цикла есть некая концепция, из неё следуют свои стейкхолдеры и их потребности. Ну дальше всё по цепочке: потребности, требования, проектировочные решения, архитектура, спецификации, система.
Что интересно: почти везде вместе со словом "анализ" используется хитрое слово 'maturation' — "вызревание". То есть, пока вы анализируете, эти самые концепции и потребности "вызревают" в головах и стейкхолдеров. Это, мне кажется, ещё круче, чем elicitation (извлечение, добыча) — нечего там добывать, оно созреть должно!
Ещё одна важная деталь: в мануале ясно написано, что первично установленные значения целевых показателей и метрик очень часто не являются осуществимыми, и приходят к каким-то реальным значениям только через несколько итераций анализа и "дозревания", да и то с оговоркой "с приемлемым уровнем риска для этой стадии жизненного цикла"! (Кто вообще оценивает уровень риска?)
В общем, кажется, у нас есть довольно свежий документ (или даже книга), требующий пристального изучения. Я бы сказал, выглядит как минимум на уровне Вигерса, а то и лучше (но более формально, конечно, больше на стандарт похоже).
>>Click here to continue<<
