Лекция
Привет, Вы узнаете о том , что такое техническое задание, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое техническое задание, спецификация задания, бриф, тз, тех. задание, технические требования, спецификация , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Нельзя взять и просто сделать сайт после разговора с заказчиком. Сначала нужно провести проектные работы. На этом этапе собираются все идеи клиента, предлагаются решения, а также проверяется их жизнеспособность и в итоге все фиксируется в едином документе. Более того, только после проектных работ можно точно оценить, сколько в итоге будет стоить сайт.
Для описания требований к Программному обеспечению(ПО) существует документ SRS (IEEE 830) и его разновидности -- с включением юзкейсов (это из RUP) и т.п. техническое задание - по сути это документ описывающий требования к ПО.
Перед началом работы с заказчиками, подрядчиками или прямыми подчиненными важно быть уверенным, что тебя все правильно поняли. Когда люди ставят размытые задачи, не утруждают себя бриф ом и не хотят давать референс — они мешают процессу, вводят в заблуждение коллег и тратят драгоценное время всей команды.
«Штатного экстрасенса уволили, теперь придется объясняться словами»
Задача — это цель. Она должна быть описана в логике действия (нарисовать, проанализировать, финализировать, согласовать) и нести в себе законченность. Задача «выложить пост» не может считаться выполненной, если пост написан, но не опубликован.
ТТ ( технические требования к сайту) — это перечень функционала и список разделов, которые должны быть реализованы. Заказчик рассказывает, каким он видит свой будущий сайт, рассказывает о своих хотелках, показывает примеры понравившихся ресурсов и «фишек», а наш менеджер формирует ТТ. Обычно этот документ представляет собой развернутый бриф, который составляется в произвольной форме по результатам личной встречи, телефонного разговора или почтовой переписки. На этом этапе оценивается сложность проекта, определяется цена проектирования сайта и заключается договор. Кроме того, при составлении технических требований становится понятно, что будет сопровождать готовый прототип — спецификация или тз
Бриф — еще одна важная часть постановки задачи. Бриф — это контекст. Забрифовать можно устно или письменно, в свободной форме или заполнив анкету. Главное, что надо помнить про бриф — он вводит исполнителя в контекст. Как мы пришли к идее создать социальную сеть? Какие действующие лица будут? Что они смогут делать? Эти и многие другие поверхностные вопросы раскрываются не в задаче, не в техническом задании, а именно в брифе.
Техническое задание - это то, что пишет технический специалист или продукт менежер совместно с заказчиком, когда хочет получить продукт. При этом они декомпозируют задачу, описывают последовательность действий, дополнительные параметры, участие сторонних специалистов, API, а также все свойства и характеристики продукта . Техническое задание исключает домысливание и неоднозначность. Оно должно быть настолько подробным, и в таких формулировках составлено, чтобы у исполнителя не возникло дополнительных вопросов и уточнений. Как у юристов в договорах. Техническое задание это документ, который берешь в руки, читаешь, и начинаешь выполнять работу.
«Создать социальную сеть или искусственный интеллект» — это задача.
«Для создания социальной сети применяем фремворк ... и язык программирования .... Для этого испоьзуем ... методологию, .... паттерны, тестирование будем выполнять .... . После взгляда на подобное ТЗ возникает ряд вопросов: а что будет если будут ... события в системе? доступн и функционал ... группе пользователей?
Техническая спецификация или просто спецификация (спека) - это то, что пишут для конечных потребителей системы, что есть в ней, как пользоваться кажой фичей(функцией). Некоторые производители(разработчики) программного обеспечения не делают техническое задание, вместо него составляя только спецификацию, этим экономися время. Спецификация - почти то же самое что ТЗ, но без требований к исполнению.
Функциональная спецификация (также, specs , функциональная характеристики документа (FSD) , функциональные требования спецификации ) в инженерных систем и разработки программного обеспечения является документом , который определяет функции , которые система или компонент должен выполнять (часто часть спецификации требований) (ISO / IEC / IEEE 24765-2010).
В документации обычно описывается, что нужно пользователю системы, а также запрашиваемые свойства входов и выходов (например, программной системы). Функциональная спецификация - это более технический ответ на соответствующий документ требований, например, документ требований к продукту «PRD» . Таким образом, он подбирает результаты этапа анализа требований . В более сложных системах несколько уровней функциональных спецификаций обычно вкладываются друг в друга, например, на уровне системы, на уровне модуля и на уровне технических деталей.
Чем отличаются техническое задание от спецификации? - Спецификация - почти то же самое что ТЗ, но без требований к исполнению. Таким образом , задание может содержать в себе спецификацию объекта исполнения, а вот спецификация не содержит заданий.
Спецификация это то, что пишет производитель, описывая функционал и технические свойства своего прораммного продукта. Техническое задание содержит требования, описание функционала, используемые технологии, сроки разработки, тестирования, внедрения и другие разделы.
Чем отличается тех. задание от брифа ? Бриф это «нечеткое, более свободно составленное» ТЗ (т. е. в котором нет конкретной информации, непосредственно касающейся текстов, а есть пожелания: относительно тематики, стиля, структуры, акцентов), или это своего рода «помощник» для заказчика, который не может составить техзадание.
Таким образом, для успешной реализации идеи нам необходимо:
Помните об этих простых правилах, соблюдайте их, и тогда ваших переделок и спонтанных хотелок от заказчика будет гораздо меньше!
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Об этом говорит сайт https://intellect.icu . Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
Последние 2 пункта специфичны, советую на них обратить внимание читателям близким к разработке.
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
Посмотрели на пример плохого дизайна, теперь вытрите кровь с глаз и перейдем к обсуждению интерфейса. В этой части технического задания стоит приложить реферы — примеры того, каким вы хотите видеть свой продукт. Это могут быть аналоги похожих разработок или просто примеры, дизайн которых вам понравился.
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.
Существуют разные типы технических или инженерных спецификаций (спецификаций), и этот термин используется по-разному в разных технических контекстах. Они часто относятся к определенным документам и / или конкретной информации в них. Слово « спецификация» в широком смысле определяется как «изложить явно или подробно» или «конкретизировать».
Спецификация требование документально требование , или набор документированных требований, должны быть выполнены с помощью данного материала, дизайн, продукта, услуги и т.д. Это общая начальная часть инженерного проектирования и разработки продукта процессов во многих областях.
Функциональная спецификация является разновидностью спецификации требований, и может показать функциональные блок - схему.
Дизайн или продукт спецификация описывает особенность решений для требования спецификации, имея в виде либо разработанный раствор или конечный полученным раствор. Он часто используется для руководства изготовлением / производством. Иногда термин « спецификация» используется здесь в связи с техническими данными (или спецификациями ), что может сбивать с толку. Лист данных описывает технические характеристики предмета или продукта, часто публикуемый производителем, чтобы помочь людям выбрать или использовать продукты. Спецификация не является технической спецификацией в смысле информации о том, как производить.
Спецификация « в эксплуатации » или « поддерживается как » определяет условия системы или объекта после многих лет эксплуатации, включая последствия износа и обслуживания (изменения конфигурации).
Спецификации - это тип технических стандартов, которые могут быть разработаны организациями любого типа как в государственном, так и в частном секторах. Примеры типов организаций включают корпорацию , консорциум (небольшую группу корпораций), торговую ассоциацию (отраслевую группу корпораций), национальное правительство (включая его военные , регулирующие органы , национальные лаборатории и институты), профессиональные ассоциация (общество), специализированная организация по стандартизации, такая как ISOили разработанные без учета поставщика общие требования. Одна организация обычно ссылается ( ссылается , вызывает , цитирует ) стандарты другой. Добровольные стандарты могут стать обязательными, если они приняты государственным или деловым контрактом.
В радиоэлектронной технике широко используется нестандартизованный термин (профессиональный жаргон) даташит (от англ. datasheet) [10].
В разных областях техники спецификация может содержать:
Исследование, описанное в статье про техническое задание, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое техническое задание, спецификация задания, бриф, тз, тех. задание, технические требования, спецификация и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем