Можно создавать полную документацию требований в соответствии с вышеизложенными принципами, или ограничиться наброском требований на 2-3 страницы, т.е. создать минимальную документацию. Однако следует отдавать себе отчет в выгодах и рисках этого выбора.
Для работы "не по правилам", во-первых, должны быть объективные предпосылки. Минимальная спецификация уместна, если имеет место наличие одновременно трех обстоятельств (объединение по "И"):
а) цена контракта и размеры проекта таковы, что разработка развернутого ТЗ экономически нецелесообразна;
б) коллектив Разработчика обладает достаточной степенью профессионализма и опыта выполнения проектов в смежных областях, чтобы уметь создавать по краткой спецификации продукт, который пройдет приемку Заказчиком;
в) между Заказчиком и Разработчиком существуют конструктивные отношения и обе стороны понимают и принимают риски мини-спецификации.
Другой вариант работы по мини-спецификации: Заказчик и Разработчик понимают, что создание развернутой спецификации оттягивает окончание выпуска готового продукта, что главная цель проекта - продукт, а не документация и готовы к плотному сотрудничеству в процессе его создания.
Это - путь так называемых agile-методологий разработки ПО.
Основной риск применения мини-спецификации заключаются в том, что они базируются на человеческом факторе.
Хорошие и конструктивные отношения между сторонами "на берегу" должны сохраниться на всем протяжении проекта.
В противном случае у сторон возникнут существенные проблемы в формальном доказательстве того - что должна делать программа, т.к. мини-спецификация для этого недостаточно полна.