Требования

Требования - это то, что продукт обязан делать, документированное ожидание результата реализации проекта. Данный документ документирует ожидания заказчика , а также разработчика программы, функций и проекта в целом. Требования включают характеристики, стоимость, сроки и риски. Таким образом, требования представляют собой формулирование того, что вам необходимо разработать или точное количественное описание того, что вы хотите получить в результате реализации проекта. Плохое определение требований - главная причина возникновения проблем при реализации проекта.

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

Типы требований:

• Функциональные требования определяют, что данный элемент системы должен делать.
• Точностные требования определяют количественные параметры соответствующих функций, выполняемых системой
• Ограничительные требования вытекают из ограничений режима эксплуатации, состояний окружающей среды, безопасности или соответствия правилам.
• Верификационные требования обеспечивают, насколько можно доверят, что система имеет заданные характеристики в реальной среде функционирования.
• Интерфейсные требования определяют функции, характеристики, допуски и ограничения всех интерфейсов.
• Эксплуатационные требования определяют операционную работоспособность системы и её взаимодействие с пользователями.

 

В англоязычной литературе для запоминания  признаков хороших требований используется аббривиатура SMART.

• Specific (Конкретны) - требования должны быть обращены только к одной особенности проекта или характеристике системы. Должны формулироваться в терминах что и насколько хорошо должно быть сделано, но ни в коем случае не в терминах возможного решения - как делать.
• Measurable (Измеряемы) - измеряемый параметр выражается объективно и количественно.
• Achievable (Достижимы) - требование должно быть технически достижимо при разумной стоимости.
• Relevant (Существенны) - требование должно соответствовать выбранному уровню системы.
• Traceable (Доступны для анализа) - требования более низкого уровня должны явно вытекать из требований более высокого уровня и/или ими поддерживаться. Требования без “родительских” рассматриваются как “сиротские” и должны быть оценены на необходимость их внедрения.

 

Необходимость.  Если имеется сомнение в необходимости требования, необходимо просто задать себе вопрос: “А что плохого случится с системой, если данное требование не будет включено в перечень?”. Если у вас нет ответа на данный вопрос, то, вероятно, данное требование не нужно.

Проверяемость.  Как только требование сформулировано, нужно определить, как его можно верифицировать. Для этого необходимо выбрать соответствующий критерий соответствия.

Достижимость.  Чтобы быть достижимым, требование должно быть технически реализуемым в заданные сроки и по заданной цене, в условиях существования дополнительных ограничений. Если существует неопределенность в технической реализуемости требования, необходимо провести соответствующее исследование или дополнительное изучение вопроса. Если и после этого неопределенность остается, нужно сформулировать цель, а не требование. Понятно, что даже если требование технически выполнимо, оно может быть недостижимым из-за стоимостных, временных или других, например весовых ограничений. Бессмысленно формулировать требование на что-то невыполнимое, необходимо быть прагматичным.

Понятность. Каждое требование должно выражать единственную мысль, быть лаконичным и простым. Важно, чтобы требование было понятным и недвусмысленным. Для хороших требований часто достаточно простых предложений.

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

 

 

Системная инженерия

Жизненный цикл

 

На главную страницу