Описывайте нужные функции в формате сценария использования русским языком!
Сценарий проще всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.
В конечном итоге, пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Например, вполне адекватные функциональные требования в формате сценария:
Гость должен иметь возможность зарегистрироваться на сайте, путем заполнения формы регистрации (обязательно указав своё имя, адрес электронной почты и желаемый пароль). Также гость, при наличии у него учётной записи, должен иметь возможность войти на сайт, указав в соответствующей форме свой адрес электронной почты и пароль. Это нужно для того, чтобы у него была возможность выполнять действия, требующие наличия учетной записи (например, покупать товары в интернет-магазине или оставлять комментарии).
Каждый аутентифицированный (вошедший на сайт) пользователь должен иметь возможность выйти из системы, например, чтобы исключить осуществление дальнейших действий на сайте от своего имени другими пользователями компьютера.
Примеры некорректных требований ТЗ
Субъективные требования — это все требования с оценочными прилагательными типа удобный, красивый, простой и тому подобными. Они некорректны для ТЗ, так как их никак нельзя проверить, а значит принять работу, основываясь на таких критериях просто не получится:
Форма входа в систему должна быть удобной и понятной для пользователя.
Непонятно изложенные требования — это еще один пример того, что не должно попадать в ТЗ. Такие требования формулируются так, что нельзя без должной подготовки понять о чём вообще идёт речь, например:
Пользователь должен иметь возможность реструктуризировать компоненты своего аккаунта путём декомпозиции отдельных сущностей на произвольно задаваемое число взаимно зависимых компонентов.
Субъективные требования чаще всего формулирует бизнес и маркетинг, а непонятно изложенные — ИТ и другие технические специалисты. И с тем, и с другим надо бороться, так как ТЗ должно быть руководством к действию и чек-листом, по которому можно проверить выполненную работу. А некорректные требования приводят к тому, что ТЗ для этого не может быть использовано, и не очень понятно зачем его было вообще писать, если никто им не пользуется.
Примеры корректных требований ТЗ
Еще примеры нормальных функциональных требований:
Гость на каждой странице может войти на сайт. По нажатию кнопки «войти» открывается форма для ввода логина и пароля. При корректном вводе логина и пароля пользователь входит на сайт и ему выводится уведомление об этом, дальше он работает с сайтом как аутентифицированный пользователь и ему становятся доступны дополнительные возможности. При некорректном вводе логина и/или пароля отображается уведомление о произошедшем и пользователю предлагается повторно заполнить форму
Зарегистрированный пользователь при посещении сайта должен видеть персональное приветствие «Здравствуйте, [Имя] [Отчество]!» и ссылку для выхода с сайта. При нажатии на своё имя пользователь попадает в личный кабинет, при нажатии на ссылку «выход» — выходит из системы и дальше работает с сайтом как гость.
Администратор может удалить страницу сайта. В списке страниц напротив каждой страницы есть кнопка для удаления, по нажатию на эту кнопку выводится диалог подтверждения удаления. При подтверждении страница удаляется, а при отказе — удаления не происходит.
Как правило, функциональные требования развиваются: уточняются и конкретизируются как в процессе согласования, так и в процессе разработки.
Например, описание процедуры регистрации в конечном итоге может выглядеть так:
Гость должен иметь возможность зарегистрироваться на сайте. Для этого он может с любой страницы сайта по ссылке «зарегистрироваться» перейти на страницу с формой регистрации.
Форма регистрации содержит поля: Фамилия, Имя, Адрес электронной почты, Пароль и его Подтверждение, а также флаг согласия с публичной офертой. Все поля являются обязательными для заполнения. Адрес электронной почты должен быть корректным адресом e-mail, Пароль должен быть не короче 6 символов и содержать буквы и цифры, Пароль и Подтверждение должны совпадать, флаг согласия с публичной офертой должен быть установлен. При некорректном заполнении формы выводится список ошибок при заполнении формы, а поля с ошибками подсвечиваются.
Корректно заполнив и отправив форму регистрации гость создаёт новую учётную запись, а ему на указанный адрес электронной почты отправляется письмо с уведомлением о регистрации и со ссылкой для активаци аккаунта. Для активации аккаункта пользователь должен перейти по полученной ссылке, после чего он будет автоматически аутентифицирован (войдёт на сайт).
Если пользователь не получил ссылку для активации, то он может запросить её повторную отправку, просто указав свой адрес электронной почты, в этом случае ему должно быть также выведено сообщение с рекомендацией поискать письмо в спаме.
Вход при помощи формы входа до активации учётной записи невозможен, в случае попытки входа или регистрации с реквизитами доступа неактивной учетной записи пользователю должно быть выведено уведомление о том, что учетная запись неактивна, а также предложение повторно отправить письмо со ссылкой для активации аккаунта.
Если пользователь не активирует свою учётную запись в течение одной недели, то она будет удалена из базы данных.
В случае перехода по ссылке «зарегистрироваться» уже зарегистрированным и аутентифицированным пользователем форма регистрации не должна показываться, а должна быть осуществлена переадресация на страницу профиля текущего пользователя с уведомлением: «Вы уже зарегистрированы и уже вошли на сайт».
Такая подробная спецификация пусть и не очень проста в написании, но зато достаточно точно описывает требования к итоговой логике работы компонента, что позволяет без проблем провести сдачу-приёмку выполненных работ.
Разумеется, что в написании любой спецификации рационально соблюдать баланс между полнотой / детализированностью требований и простотой понимания / написания самого ТЗ.
Избыточная детализация времязатратна и делает ТЗ перегруженным очевидными деталями, но недостаточная детализация приводит к тому, что какие-то важные требования не будут описаны и могут не быть реализованы. Задача бизнес-аналитика, составляющего ТЗ, как раз и заключается в том, чтобы найти баланс между полнотой изложения и лаконичностью.
Уровень необходимой детализации ТЗ обычно зависит от компетентности специалистов и от корпоративной культуры. Профессионалам можно ставить высокоуровневые задачи и они их решат адекватным способом, а начинающим специалистам лучше более полно детализировать задачи, декомпозировать их и формулировать критерии приёмки. С корпоративной культурой всё несколько сложнее, например: чёткое следование регламентам и формализация — это отличный фактор для процессной деятельности, но в проектной / продуктовой разработке это несколько замедляет работу, так как требует более формальной и детализированной постановки задач.
