Хотя я бы согласился с тем, что вам необходимо иметь какое-то широкое согласие в отношении объема и стоимости создаваемой системы, я думаю, что достаточно солидно думать, что вы можете полностью специфицировать систему до того, как она будет передана заказчику. Руки. Как вы обнаружили, клиент очень часто не знает, чего он хочет, пока он на самом деле не увидит это. Один из способов решения этой проблемы - макеты, как вы привыкли делать. Я тоже использую их во время проектирования и планирования.
Чаще всего, однако, вам нужно получить фактический продукт в руки клиента, чтобы получить неизбежную обратную связь о том, что работает, а что нет. Лучше делать это раньше, чем позже, поскольку изменения, которые происходят в поздней стадии разработки, намного сложнее и дороже, по крайней мере, в традиционных методах. Использование гибкого метода, который доставляет работающее программное обеспечение рано и часто, в сочетании с достаточным планированием и документацией обеспечивает лучшую обратную связь с клиентом, чем повторение множества спецификаций для продукта, который клиент может обнаружить, что он не хочет (или по крайней мере хочет как они сказали).
Я бы предположил, что вам нужны некоторые документы, которые в общих чертах описывают сферу проекта. Достаточно, чтобы вы могли договориться о том, что является частью системы, а что нет. Если вы создаете приложение для управления запасами, они не должны ожидать, например, систему управления взаимоотношениями с клиентами. Затем примените методы из гибких методов разработки, чтобы облегченным образом отслеживать желаемую функциональность и получать некоторый рабочий код в их руки как можно раньше и на регулярной основе после этого. Это потребует доверия от всех сторон, поэтому вы можете начать с небольших проектов и сроков и укрепить это доверие.