Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Разработка начинается с технического задания. Но какое должно быть техническое задание чтобы получить тот результат который вы ожидаете и без проблем провести приёмку?
Это может быть листок бумаги исписанный разными почерками и с пятном от кофе в уголке, а может быть строгий документ в соответствие с ГОСТ «34.602-2020», подразумевающий подготовку документации в соответствие с ГОСТ «РД 50-34.698-90», включая программу и методику испытаний. Мы понимаем что тратить много времени, сил, а зачастую и денег на подготовку объемной документации мало кто хочет, поэтому подготовили облегчённый подход к разработке технического задания, в нём нет ничего нового, скорее тот минимум который поможет прозрачно донести требования до исполнителя.
Цели. Во первых необходимо определить цели, это те программные решения которые ожидает получить заказчик от реализации проекта. Именно над реализацией целей должна фокусироваться разработка. Формулирование целей позволяет избежать избыточных, не способствующих достижению целей, требований, и не упустить ключевых.
Задачи. Здесь описываются задачи разработки, которые потребуется решить для достижения конкретных целей (запросы на реализацию функций совокупность которых обеспечит заказчика необходимым и достаточным инструментарием).
Требования к подсистемам. Здесь подробно описываются подсистемы в рамках которых должны реализовываться функции необходимые для достижения задач. Подсистема не обязательно должна быть отдельным модулем, скорее логическим блоком. Для каждой подсистемы описывается: назначение, полный перечень всех необходимых возможностей, способ доступа к ним, логика работы, требования к соответствующему интерфейсу (программному или пользовательскому), в т.ч. требования к входным и выходным данным (если имеются), вызываемые сервисы в рамках взаимодействия, условия применения, требования к внешней среде и состоянию прочих подсистем.
Сценарии применения. Для представления о том как конкретно будет использоваться функционал в рамках решения задач, важно описать конкретные сценарии последовательного выполнения рабочих процессов с использованием разрабатываемого решения. Данные сценарии должны затронуть весь функционал, при этом нет нужды описывать комбинаторику всех возможных вариантов его применения, а только тот минимум который осветит каждую необходимую, для достижения целей, возможность и логику ее применения. Наличие сценариев применения уточняет требования к подсистемам, подсказывая как именно лучше реализовать функции и конкретизирует как будут выполняться задачи, позволяя на ранних этапах убедиться в эффективности разрабатываемого решения.
Описание объекта автоматизации. Описание деятельности или технических решений, усовершенствование которых планируется произвести за счет достижения целей разработки. Как сейчас реализуются процессы подлежащие автоматизации, присущие проблемы.
