Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля
Ещё бы. Ведь вы выполните за них часть работы.
В техническом задании должны быть изложены требования и ограничения, важные Заказчику.
В статье на картинке ER-модели видны следующие ограничения: ID -тип Integer, created_at — тип datetime и т.д. Но не указано требование: ID — уникальный идентификатор, created_at — время по UTC и т.д. Таким образом, Заказчик (по Вашему) зафиксировал в тех. задании форматы данных, хотя это не его область компетенции, и не отразил важные для бизнес-процессов требования, касающиеся особенностей ввода и вывода даты/времени, часовых поясов, зимнего/летнего времени и т.д.
В статье на картинке ER-модели видны следующие ограничения: ID -тип Integer, created_at — тип datetime и т.д. Но не указано требование: ID — уникальный идентификатор, created_at — время по UTC и т.д. Таким образом, Заказчик (по Вашему) зафиксировал в тех. задании форматы данных, хотя это не его область компетенции, и не отразил важные для бизнес-процессов требования, касающиеся особенностей ввода и вывода даты/времени, часовых поясов, зимнего/летнего времени и т.д.
Согласен, это важное замечание, но решил на перегружать пост. Лучше тогда в следующей статье подробно разберу все по программным интерфейсам. И это не совсем по моему, с моей стороны тут только трактовка IEE-830, а это все равно что библия или PMbook. Техническое задание это общий документ. покрывающий все требования заказчика и позволяющий оценить проект и производить общее руководство. Касательно ограничений их в целом лучше писать отдельно в спецификациях или просто держать в Confluence.
Взятые вами за незыблемые истины ингредиенты IEEE-830 уже ставят под сомнение формализацию процесса составления ТЗ — когда видишь в одном слое "функции", "интеграцию" и "монетизацию", то сразу включается критический ум и становится понятно, что для более-менее нестандартных проектов ничего из описанного либр не работает, либо с КПД в 5-10%.
Если вы внимательно прочитали статью и потом прочитали стандарт, то вы могли заметить, что это вольная трактовка. Также эта схема указана как продукт работы профессионального бизнес-аналитика, который работает не с интернет-магазинами под копирку, а с сервисами от фриланс-биржи, до чата с AR.
Любой проект можно разложить на данную схему. Если вы приведете пример проекта, который нельзя, то я буду крепко удивлен.
Проект в котором нет «монетизации», но есть «логирование». Но суть даже не в этом: и то, и другое можно отнести к функциональным/не функциональным требованиям, поэтому протекшее на этот уровень конкретное функциональное требование (монетизация) говорит о многом и задаёт резонный вопрос: «а раскладываем ли мы проект на самом деле или только делаем вид?»
Конечно нужно руководствоваться здравым смыслом, если в продукте например нет пользовательского интерфейса, то конечно не нужно заполнять пункты с ним связанные. Монетизация относится к функциональным требованиям, потому что весьма распространенная функция и часто происходит прямым образом (e-commerce, реклама, подписка, покупки в приложении, донат и т.д.).
Для кого: начинающим разработчикам
Лично мне было очень полезно как начинающему "войтивайти"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ликбез по техническому заданию