Данная статья относится к циклу статей по разработке требований к программному обеспечению. Если вы сразу попали на эту статью, то вам необходимо начать читать с первой. В конце каждой статьи есть ссылка на следующую, поэтому в итоге вы вернетесь сюда. У нас есть исходные данные, теперь необходимо понять, а что именно мы решаем. Я думаю, что все прекрасно понимают, что решить можно две вещи: проблему или задачу. Но при разработке требований мы в первую очередь решаем проблему, а во-вторых, проблему связанную непосредственно с процессом компании, следовательно, решаем бизнес-проблему...

В этой статье мы расскажем, как самостоятельно составить действительно полезный документ, который поможет понять задачу, а не наоборот. Что такое техническое задание (и почему на самом деле вам нужно не оно) Для начала пора бы разобраться в терминологии: в процессе разработки проекта мы постоянно пишем какие-то документы, у всех них разное назначение и пишутся они для разных участков проекта и разной аудитории. На старте проекта команде важно понять бизнес-задачу: Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием — техническое задание...

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