Post #344

Собственно, по управлению требованиями у нас есть целый ГОСТ Р 59194-2020. Вот его основные положения. 1. Есть два вида деятельности: — разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию). — контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон). 2. Требования могут быть представлены в форме базы данных или документа. 3. Есть исходные требования — фиксирующие потребности заинтересованных сторон и служащие для валидации, и есть проектные требования — для разработки различной документации готового объекта и для верификации. 4. Есть два типа "контрольных рубежей": — на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности); — на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения). 5. При проверке требований выполняют их валидацию и верификацию. При валидации проверяют: — полноту покрытия спецификацией исходных требований — правильность выражения потребностей или отражения принятого технического решения — наличие связи с потребностями или родительским требованием — непротиворечивость При верификации: — что требования относятся к одному объекту (!) — что требования соответствуют критериям качества — что у них правильно заполнены атрибуты, они правильно классифицированы и связаны — установлены критерии верификации и валидации объекта, который будет разработан по этим требованиям. 6. Минимальный набор атрибутов требования: — Уникальный идентификатор — Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа) — Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!) 7. Очень сильная идея: требования являются частью конфигурации! И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи"). То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой! Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации). Про конфигурации очень часто не задумываются, пока не обнаруживают себя в ситуации, когда развернуто 8-10 экземпляров одной и той же системы, отличающихся набором данных, справочников, функций, набором ролей, подключенных внешних систем и заглушек и средств мониторинга. Причем никто в точности не знает — сколько их точно развернуто, где, чем они друг от друга отличаются и кто к ним имеет доступ. Вот тут-то управление конфигурациями и начинается!