сразу забегу вперёд — а как вы наблюдением поймете, что у него нет онкологии, например?

как предприниматель и инженер по требованиям/аналитик, я могу предложить методику проверки требования «1. «семья с ребёнком должна обеспечивать выживание ребёнка»
- контролёр измеряет у ребёнка пульс и убеждается, что он есть

мед наблюдения, анализы

как предприниматель и инженер по требованиям/аналитик, я могу предложить методику проверки требования «1. «семья с ребёнком должна обеспечивать выживание ребёнка»
- контролёр измеряет у ребёнка пульс и убеждается, что он есть

Правда тут вопрос, а семья ли обеспечивает это, или он жив и здоров вопреки её действиям?

Вот про это я и говорил. Что пульс - это критерий живости в данном случае. Он взялся откуда то. Поэтому нужно на что-то опереться, чтоб этот критерий сформулировать.

Коллеги, мне кажется, эта тема уходит в общий ффилософский вопрос: можно и нужно ли все выводы об изменении состояния систем (в данном случае имеется ввиду бизнес-системы) подтверждать математически?

Я считаю, что нет. И уверен, что большинство управленческих решений в истории принималось и оценивалось без математического расчета

Доброго дня! Хотел бы узнать мнение сообщества на следующую тему:

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

Моё мнение почему это может быть полезно:
- Требование - постановка задачи. Если изначально отсутствуют критерии приёмки результата, то есть вероятность, что задача невыполнима. Следовательно ресурсы выделенные на эту задачу будут потрачены зря. Следовательно такой может привести проект к закрытию по выходу за рамки бюджета.
- Требование - в процессе разработки превращается в согласованное обязательство сторон (постановщика-исполнителя) о качестве результата работ. Если отсутствует способ определить качество выполнения работы - это может привести к снижению качества итогового результата. Что в итоге может привести к закрытию проекта по несоответствию целям.

Моё мнение почему может быть вредно:
- Есть некоторая вероятность, что требование может оказаться непроверяемым или невыполнимым на любой стадии жизненного цикла разрабатываемой системы. Тогда аналитик при разработке методов проверки должен быть достаточно компетентен в предметной области, чтобы предлагать такие методы. Это требует дополнительной квалификации и следовательно увеличения стоимости подготовки такого аналитика. Что в свою очередь сужает рынок поиска и может привести к закрытию проекта по выходу за сроки.

Моё мнение какие способы решения:
- В пару к аналитику давать предметника, способного указать проверяемость требований.
- Ввести понятие зрелости требований по их соответствию некоторым критериям качества. Например по INCOSE GfWR или ISO 29148 или внутренним стандартам предприятия др. Как следствие ввести понятие жизненного цикла требования со всеми последствиями. Например признать, что вся совокупность требований к системе - это её модель, и на основании оценки зрелости такой модели можно принимать решение о дальнейшей разработке и финансировании проекта.

Правда тут вопрос, а семья ли обеспечивает это, или он жив и здоров вопреки её действиям?

на самом деле семья не может ГАРАНТИРОВАТЬ жизнь и здоровье ребенка, это утопия

Дополню кейс:

я предприниматель, у меня есть 100 тр чтобы разработать ТЗ на прототип. Какое количество бюджета ты хочешь потратить на проработку потребностей, при условии, что аналитик со знанием INCOSE GfRW стоит от 3 тр в час?

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

поэтому только с какими-то оговорками/ограничениями

На согласование общей концепции и глоссария - 7-10% бюджета.
На анализ нормативки и общих требований к прототипу до 60%, включая обоснование требований.

3-5% на формирование документа.
Остальное на и разработку планов и этапности выполнения работ по созданию прототипа.

Я бы делал так.

какую задачу ты решаешь?

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

Конечно, если мы находимся в суровом корпорате, эти расхождения есть всегда, и каждое решение приходится обосновывать, желательно с цифрами. Но это же не нужно считать общим и однозначно правильным кейсом?

Выявить для себя возможные преимущества и недостатки объединения аналитика и инженера по испытаниям. Со стороны бизнеса, со стороны аналитика.
Это необходимо для повышения своей собственной компетенции при подборе специалистов и управленцев в проекты.

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