Очень часто в работе приходится читать входящие техзадания (ТЗ), где на 20 страницах подробно расписывается, как должна работать регистрация, авторизация и восстановление пароля, а потом еще на полстраницы что-нибудь про, собственно, бизнес-логику и предметную область. Почему так происходит, в принципе понятно — данные функции типичны для многих сервисов и сайтов, с ними автор документа скорее всего сталкивался сотни раз и может худо-бедно пересказать свой опыт. В то время как предметная область и необходимая бизнес-логика — тут думать надо, это же что-то новое, написать-то не так и просто. Понятно, почему про одно написано 20 страниц а про другое — 2.
Тем не менее. Не делайте так.
Во-первых, если только вся бизнес-логика не крутится вокруг авторизации и регистрации (например, если вы какой-нибудь необычный SSO-сервис хотите сделать) то детали входа в систему не имеют никакого значения. Во-вторых, современные разработчики пользуются современными же инструментами: библиотеками, фремворками и цмсками, в которых все эти функции реализованы:
а) давно;
б) общепринятыми способами;
в) скорее всего лучше, чем вы придумали;
г) наверняка не так, как вы придумали.
Ну и в третьих, даже если по каким-то причинам фреймворки и цмски использовать не получится, нормальный разработчик лучше знает, как эти функции должны быть устроены.
Поэтому 20 страниц описания тривиальной логики скорее помешают, чем помогут. В худшем случае их наличие приведет к конфликтам на этапе сдачи функционала, т.к. из лучших побуждений будет сделано не так, как было написано. А в лучшем случае — придется потратить изрядно времени на проработку вопросов типа «А вы уверены что нужно при регистрации вводить и никнейм, и ФИО, и почту, а то обычно это стараются упростить, а никнейм у вас вообще нигде не используется?» Или «а вы уверены, что при восстановлении пароля нужно присылать пользователю его пароль по почте, а то это небезопасно и так давно не делают?» Причем, по факту задавания вопросов обычно обнаруживается, что 99% старательно расписанных в ТЗ деталей будущей реализации не имеет никакого значения даже для самого автора документа. Просто так написали, потому что вроде надо было что-то написать, ну и мы старались чтобы солидно выглядело.
Не нужно подробно описывать как должен с вашей точки зрения быть реализован тривиальный и общепринятый функционал. Не нужны текстовые или визуальные схемы полей ввода логина и пароля, и где там рядом кнопочка. Для этого есть прототипирование и дизайн. Необязательно присылать статьи про техническое устройство cookie-based-авторизации, которые вам посчастливилось прочитать. Нормальный разрабочик читал и эти две, и двадцать восемь других статей по теме тоже читал. Вместо этого просто напишите «Нужно реализовать регистрацию и авторизацию», а дальше — то, что немного отличает желаемый вами вариант авторизации и регистрации от миллиона других существующих в интернете. Например:
— нужно реализовать регистрацию на сайте
— при регистрации пользователь вводит электронную почту и телефон
— телефон должен верифицироваться отправкой смс
— после верификации телефона на введенную электронную почту отправляется одноразовая ссылка
— пройдя по ссылке, пользователь автоматически входит в систему и его направляет на страницу настроек
— на странице настроек пользователь должен ввести новый пароль для входа в систему, а также может указать свое ФИО, никнейм и поменять электронную почту
— а еще мы хотим чтобы кроме обычной регистрации была регистрация и вход через гугл, фейсбук, одноклассники и госуслуги с заполнением пользовательских данных из этих сервисов
И всё. Обычно ни один из этих пунктов не нуждается ни в дальнейшей детализации, ни в рисовании схем из овалов, стрелок и прямоугольников. Этого списка достаточно и аналитику, чтобы конкретизировать требования, и дизайнеру, чтобы понять, как нарисовать, и разработчику, чтобы понять, как сделать, и даже тестировщику, чтобы всё сломать.
Как же тогда написать длинное ТЗ, спросите вы? А никак. Если у вас нет прожженого продукт-оунера и бизнес-аналитика, съевших хотя бы толстый край собаки на разработке, то вообще не нужно его писать. Напишите коротко, что вы хотите сделать, найдите разработчика, которому вы готовы это доверить. И поговорите с ним. Если разработчик опытный, у него будет кто-то, кто выступит в качестве бизнес-аналитика и напишет требования. И будет кто-то, кто выступит как ведущий разработчик, он эти требования конкретизирует, уточнит противоречия и то чего не хватает (такое есть всегда), и декомпозирует в задачи для непосредственных исполнителей. Возможно, всё это будет даже один человек. Но главное что так всем будет проще.
