Требования нужны не только на момент разработки технического задания. В реальных проектах с реальными стейкхолдерами требования могут меняться ежедневно. Чтобы сохранить целостность требований и сделать, в итоге, успешный продукт, уложившись в срок и бюджет, нужно тщательно следить за всеми изменениями, знать причинно-следственные и другие связи между требованиями, а самое главное — понимать место требований в системной иерархии.
каждое требование привязывается либо к самой функции (например, для Ф6 необходимо указать максимальное расстояние), либо к связи (например, для С1 следовало бы подробнее указать особенности электрического тока, с которым придется иметь дело).
Для каждого требования должен быть справедлив вопрос «зачем?». С этой точки зрения, все требования, на самом деле, функциональные, поскольку ответ на вопрос «зачем?» должен приводить нас к той функции, которую требование определяет.
Если бы Ингеборг Карлович был руководителем проекта по строительству жилой многоэтажки, то его слова звучали бы так:
— Вы мне спроектируйте нормальную жилую многоэтажку, да так чтобы я ее мог воткнуть в любую инфраструктуру на любой местности, в любом районе, независимо от класса жилья — там же все одинаково, а потом мы ее будем всем продавать. Когда продадим первую, вторую, третью — построим все по-быстрому и проверим, хороший у вас проект или нет.