Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.
На основе этого бизнес-требования я разработал функциональное требование: «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента, включая кредитный статус, кредитный рейтинг и текущие кредитные условия».
Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное требование включает в себя несколько важных пунктов, каждый из которых имеет ключевое значение:
«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.
«должна» – ключевое слово, указывающее на обязательность поддержки функциональности системой, в отличие от формулировок «может» или «будет». Такая точность важна, так как любая неоднозначность может стоить значительных сумм, а разные трактовки могут использоваться как заказчиком, так и исполнителем.
«на главной странице…» – указывает на конкретное местоположение и содержание функции, что помогает точно определить, где именно будет реализована функция в интерфейсе.
«информацию о:…» – здесь конкретно перечисляются параметры, которые должна отображать система. Это может включать параметры, которые обязательно будут реализованы, а также те, которые могут быть добавлены позже, если это будет возможно в рамках проекта.
Таким образом, мы подробно описываем каждый аспект требования, обеспечивая его полную прозрачность и предотвращая возможные недоразумения в будущем. Так формируется функциональное требование.
Возможно, у вас возник вопрос: «Как, исходя из краткого и общего бизнес-требования, вы сформулировали такое детализированное функциональное требование? Откуда взялись детали о месте и содержании информации?». Часть ответа заключается в моем доменном опыте, о котором я упоминал ранее. Многолетняя работа в бизнесе и опыт использования различных бизнес-систем, которые обычно содержат похожий набор параметров и функций, позволяют мне предложить наиболее подходящий подход к информации о платежеспособности клиента для нашей системы.
Вторая часть ответа касается процессов, связанных с документированием требований. Помимо написания самого документа, в процесс включены коммуникационные действия, такие как обсуждение требований, их обновление и подписание. Написанное мной функциональное требование не будет сразу же переведено в дизайн. Сначала оно пройдет внутреннее обсуждение с моим ведущим бизнес-аналитиком, в ходе которого могут быть внесены правки. Затем следует обсуждение с клиентом, возможные дополнительные изменения и окончательное подписание требования. Только после всех этих этапов начнется документирование дизайна для этого функционального требования.