Разработка начинается с технического задания. Но какое должно быть техническое задание чтобы получить тот результат который вы ожидаете и без проблем провести приёмку?
Это может быть листок бумаги исписанный разными почерками и с пятном от кофе в уголке, а может быть строгий документ в соответствие с ГОСТ «34.602-2020», подразумевающий подготовку документации в соответствие с ГОСТ «Р 59795-2021», включая программу и методику испытаний. Мы понимаем что тратить много времени, сил, а зачастую и денег на подготовку объемной документации мало кто хочет, поэтому подготовили облегчённый подход к разработке технического задания, в нём нет ничего нового, скорее тот минимум который поможет прозрачно донести требования до исполнителя.
Цели. Во первых необходимо определить цели, это те программные решения которые ожидает получить заказчик от реализации проекта. Именно над реализацией целей должна фокусироваться разработка. Формулирование целей позволяет избежать избыточных, не способствующих достижению целей, требований, и не упустить ключевых.
Задачи. Здесь описываются задачи разработки, которые потребуется решить для достижения конкретных целей (запросы на реализацию функций совокупность которых обеспечит заказчика необходимым и достаточным инструментарием).
Требования к подсистемам. Здесь подробно описываются подсистемы в рамках которых должны реализовываться функции необходимые для достижения задач. Подсистема не обязательно должна быть отдельным модулем, скорее логическим блоком. Для каждой подсистемы описывается: назначение, полный перечень всех необходимых возможностей, способ доступа к ним, логика работы, требования к соответствующему интерфейсу (программному или пользовательскому), в т.ч. требования к входным и выходным данным (если имеются), вызываемые сервисы в рамках взаимодействия, условия применения, требования к внешней среде и состоянию прочих подсистем.
Сценарии применения. Для представления о том как конкретно будет использоваться функционал в рамках решения задач, важно описать конкретные сценарии последовательного выполнения рабочих процессов с использованием разрабатываемого решения. Данные сценарии должны затронуть весь функционал, при этом нет нужды описывать комбинаторику всех возможных вариантов его применения, а только тот минимум который осветит каждую необходимую, для достижения целей, возможность и логику ее применения. Наличие сценариев применения уточняет требования к подсистемам, подсказывая как именно лучше реализовать функции и конкретизирует как будут выполняться задачи, позволяя на ранних этапах убедиться в эффективности разрабатываемого решения.
Описание объекта автоматизации. Описание деятельности или технических решений, усовершенствование которых планируется произвести за счет достижения целей разработки. Как сейчас реализуются процессы подлежащие автоматизации, присущие проблемы.
Комментарии (20)
alien007
25.04.2022 18:16+2Так начиналось десятилетие науки и технологий
Dmitry1987 Автор
25.04.2022 18:28Ну извините, видимо мои скромные труды не помогут вам гордиться отчизной. Спасибо за политическую ноту
Dmitry1987 Автор
26.04.2022 00:48Это же был сарказм, или я вас неправильно понял ?
alien007
26.04.2022 00:57+1Да нет, не сарказм. Скорее сожаление внутреннее по поводу происходящего и грядущего, судеб отчизны и ее людей. Горько осознавать, что тем, кто не уедет, единственная область применения останется на госконтрактах. В любом случае, не имел намерения вас обидеть.
Dmitry1987 Автор
26.04.2022 01:45-1Да, и мне тяжело, но ты не волнуйся. У нас великая страна, мы были первые в космосе, Менделеев изобрел таблицу Менделеева, и хоть мы не научились делать красивые машины, но во многих областях нам нет равных. Мы бы не пропали даже если бы оказались на единственном континенте, окруженном мировым океаном. Нужно только верить друг в друга и поддерживать, не важно где ты, важно кто с тобой рядом.
a_nick
25.04.2022 20:08+4Дмитрий, во первых РД 50-34.698-90 не является ГОСТом, во-вторых, он отменен в 2019 году, а в третьих, в этом году вступил в действие ГОСТ Р 59795-2021, вместо этой РД-шки.
Если у вас в одной строке столько неточностей, то и остальное читать, видимо, не стоит.
Dmitry1987 Автор
25.04.2022 20:22Спасибо обновил. Не сказать что я слежу за изменениями в ГОСТах, а то что указанная РД была отменена, еще не повод не требовать его соблюдать. И как вы понимаете разбираться во всех тонкостях ГОСТов не просто для обывателя, даже если ты имел опыт с ними работать.
Dmitry1987 Автор
25.04.2022 20:24Т.е. подчеркну что эта статья не для таких корифеев как вы, а скорее для тех кто в ГОСТы не погружался.
DrPass
26.04.2022 00:10+5Я не знаю вообще, для кого эта статья. Когда четверть века назад я был студентом, нам, конечно, задавали рефераты на подобные темы. Но если бы я взял и передрал реферат из вашей статьи, мне бы даже за него влепили тройку, т.к. нет ни введения, ни выводов :)
Но это для студентов. Что из этой заметки может почерпнуть чувак, которому надо писать техническое задание, мне неведомо. «Укажите в ТЗ цели, задачи и требования». Ну ок. А я-то там хотел написать пасхальное поздравление, автобиографию и считалочку. А вон оно как что надо было…Dmitry1987 Автор
26.04.2022 00:28Все гениальное просто. Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности, а не просто перечисляете список пожеланий за циферками. Это базис который необходим, но мало кто так делает. А также полезно описать сценарии применения, вот это обычно никто в техническом задание не пишет, даже по ГОСТу, там это появляется уже перед этапом приемки, и называется "программа и методика испытаний". А если включить это в требования, то это будет как "Бритва Оккама", для описания подсистем, и фактически исключит двусмысленность в формулировках. Возможно вы живете в мире где все друг друга понимают, но на практике зачастую, то что говорят, как это понимают и что имелось ввиду, обычно как выясняется разные вещи. И это не для студентов, как вы правильно заметили.
randomsimplenumber
26.04.2022 09:39Для нестудентов есть универсальная формула: "Больше бумаги - чище ***а".
DrPass
26.04.2022 17:22Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности,
Ну а почему именно в такой последовательности? Я, например, предпочёл бы видеть «Описание объекта автоматизации» либо на первом месте, либо вообще отдельным документом. А сценарии применения вполне логично разместить после целей. Потому что описание объекта автоматизации — это «что мы имеем сейчас, цели — его хотим добиться, сценарии применения — то, как это должно выглядеть, и задачи — то, как это нужно сделать. Но опять же таки, у кого-то может быть иное видение и/или потребности в документировании. ГОСТы в данной сфере, это ведь даже не набор „best practices“, а всего лишь один, согласованный на государственном уровне, формат.Dmitry1987 Автор
26.04.2022 18:11Цели, задачи и требования к подсистемам, это в некотором роде базис описания, в котором формулируется, что и как должно быть реализовано. А сценарии, они ближе к приемочным испытаниям которые по логике возникают позже, к тому же будет сложно описать как пользоваться системой которая еще не описана. Т.е. в требованиях к подсистемам мы, в том числе, например, описали интерфейс включая кнопки на нем и логику их работы, какие-то сервисы и т.д., и вот уже в сценариях мы пишем что нажали такую-то кнопку, произошло то-то, перешли в другой интерфейс под другим юзером и увидели там какие-то объекты, с опциями и т.д. Конечно нужно понимать что нужно сделать до того как описывать требования к подсистемам, но они все же должны формироваться исходя из задач. Например если у нас есть цель: "автоматизация выпуска эцп" и задачи: "реализовать возможность юзера сделать запрос на выпуск эцп", "интеграция с налоговой в части формирования запроса", "реализовать функционал активации выпущенной эцп юзером" и т.д.. Так вот на основание этого и формируется образ системы, а сценарии фактически уже, в некотором роде, демонстрируют как этим можно будет пользоваться, на сколько это юзабельно и удовлетворяет требованиям. И вот после формирования и анализа сценариев, уже могут быть скорректированы требования к подсистемам. А что касается описания объекта автоматизации, то возможно это уже не столь критично в начале он или в конце, просто я его разместил в конце, т.к. сначала мне хочется узнать что вообще нужно сделать, а потом понять как это интегрировать в существующую систему, и что уже там есть, а не слушать пролог не понимая к чему это все. Хотя возможно на этот счет вы правы. На счет формулировок: задачи, как я понимаю, это как раз то "что мы хотим сделать", описание подсистем уже "как мы хотим это сделать", а вот сценарии уже то "как мы этим планируем пользоваться".
alx_2003
27.04.2022 11:52Годная статья. Очень кратко и по делу. Можно давать студентам, чтобы сами писали ТЗ к лабораторным.
Спасибо.
Dmitry1987 Автор
27.04.2022 11:58Спасибо. Правда я не уверен в полезности для студентов данного подхода, мне казалось это больше для малой коммерции. Хотя я сам на айти не учился, поэтому не уверен чему там учат, просто как мне казалось преподаватели рады если студент в принципе справился с поставленным заданием, а не оценивают удовлетворенность гипотетических пользователей и эффективность оптимизации бизнес-процессов. Но первые три пункта конечно это де-факто стандарт
saipr
Надо бы переслать статью или ссылку на неё в комитеты/комиссии (что там ещё?) по импортозамещению ;)
Dmitry1987 Автор
Это видимо юмор, т.к. это не продукт чтобы им замещать что-то, да и ГОСТы которые я упоминаю наши российские, да и они неплохие впрочем, качество технических заданий на госзаказе вполне приличное. Просто на малобюджетном коммерческом рынке мало кто их придерживается зачастую и технические задания очень абстрактные и сулят большие проблемы при приемке. А тот вариант который я описал может помочь грамотно структурировать ТЗ не вдаваясь в тонкости сложного описания по ГОСТу
yaguarundi
Вникать в тонкости описания по ГОСТу требуется, только если у вас есть госзаказ. Если вы уже доросли до того, что имеете шанс получить госзаказ, то и с ГОСТами уже сможете разобраться.
Dmitry1987 Автор
На госзаказ могут выйти и небольшие компании, есть даже специальные категории тендеров, только для субъектов МСП. И действительно нет проблемы с ними разобраться. Речь не о том чтобы упразднить применение ГОСТов, там где они сейчас используются. Но в небольших коммерческих контрактах тоже не помешало бы чуть более серьезно относится к техническому описанию.