Comments 10
Понятно, что это перевод международного нормативного документа, но хорошо бы раскрыть в нескольких статьях с примерами "вот так правильно формулировать требования в техдокументации, а так - неправильно", поскольку человеку вне контекста системной инженерии трудно понять все эти многочисленные пункты перечислений...
И еще - сущность и атрибуты - это то же самое, что и классы и атрибуты в ООП? Можно ли их формализовать в коде?
Здравствуйте, спасибо за комментарий. По поводу раскрытия правил в примерах - согласна, постараюсь привести их в отдельной статье. По поводу сущности, как я понимаю, это подлежащее в формулировке требования, т.е. субъект который выполняет действие. Например, если требования сформулированы с точки зрения пользователя, то сущностью является пользователь: Пассажир должен иметь возможность зарегистрироваться на рейс. В этом случае при дальнейшем проектировании системы "Пассажир" может быть определен как класс и формализован в коде. Про атрибуты: тут имеется ввиду атрибуты самого требования. Самый простой пример, когда заводится задача в трекере задач (например, мы используем Redmine, YouTrack), то там задаем атрибуты: статус, приоритет, принадлежность спринту, плановый срок реализации и пр. В данном руководстве приводится расширенный список этих атрибутов, а какие использовать, каждый решает сам. Так что эти атрибуты не формализуются в коде целевой системы.
Хорошо изложено. А сущности и потребности это entities and capabilities?
Система должна выполнить функцию А в случае одновременного выполнения следующих условий:
Условие X
Условие Y
Условие Z.
Возможно, лучше было бы использовать в таком контексте пару "неправильно/правильно". Не дословно, зато по смыслу.
Шикарный документ, на который можно сослаться особенно по таким пунктам как С3,С4,С6,С7 по составлению "хотелок", а главное, отказ от новых безумных по С10,С11,С15.
Но очень проблемное место с "уровнями", например, удовлетворение потребности и потребностей более высокого уровня, где не совсем понятно почему они более высокого, а не низкого уровня и вообще что это такое.
Здравствуйте, уровни согласно INCOSE следующие (см. рисунок по ссылке https://sebokwiki.org/wiki/Life_Cycle_Processes_and_Enterprise_Need):
Уровень предприятия (стратегический).
Уровень бизнес-управления.
Уровень операционной деятельности.
Уровень системы.
Уровень элемента системы.
На каждом уровне есть потребность и требование.
Потребность более высокого уровня (наверно это уровень операционной деятельности): Департамент экономики и контроллинга должен формировать плановую смету доходов и расходов на 1 год.
Требования к системе (более низкий уровень):
Система должна формировать заявки на доходы и расходы
Система должна загружать данные по доходам и расходам из ...
Система должна ...
То есть на 1 потребность может быть много требований к системе. Пример конечно некачественный, от балды.
К сожалению, я не нашла в работах INCOSE примеров формулировок потребностей и требований на уровнях выше уровня системы. У них есть руководство по потребностям и требованиям, наверно там подробно описано про уровни и даны примеры потребностей и требований на разных уровнях.
К. Вигерс мне кажется облегчил это дело и выделил три уровня: Бизнес-требования->Пользовательские требования (требования заинтересованных сторон)->Функциональное требование к системе.
Для полного понимания не хватило определений "потребности" и "требования". Что у них общего? Что различного с точки зрения INCOSE?
Итоговая сводка по руководству по написанию требований INCOSE (Июнь 2023)