Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.

Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.

Описание дизайна:

"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."

Входные условия:

Для использования функциональности пользователь должен авторизоваться в системе СУК, выбрать компанию и перейти на её главную страницу.

Описание функциональности:

Затем следует детальное описание функциональности, представленное в виде нумерованного списка. Этот список описывает шаги, которые система выполняет в ответ на действия пользователя. Подобная структура упрощает понимание логики работы системы и облегчает последующие обсуждения возможных корректировок.

Шаги/Сценарий:

На странице профиля компании система отображает раздел «Кредитная информация».

В разделе «Кредитная информация» отображаются следующие поля/данные:

Кредитный рейтинг (название) – текстовое, неизменяемое.

Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.

Кредитный статус (название) – текстовое, неизменяемое.

Кредитный статус (значение) – неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.

Кредитные условия (название) – текстовое, неизменяемое.

Кредитные условия (значение) – неизменяемые, три текстовых поля со значениями:

а) разрешенная рассрочка: «ХХ» месяцев;

б) статус контракта: «активен», «неактивен» или «истек»;

в) размер задолженности: «нет» или «размер задолженности».

Кредитная история (название) – текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).

Заключение:

Вот и всё – это описание основного блока дизайна для простой функциональности, чтобы избежать множественных страниц детального описания.

Изменение данных:

В данном дизайне изменение данных не предусмотрено, так как у пользователя нет возможности изменять представленную информацию.

Функциональный дизайн готов к использованию разработчиками, но работа здесь не заканчивается. В большинстве проектов важно, чтобы функциональность, предназначенная для пользователя, сопровождалась соответствующими визуальными и дата-компонентами. Это необходимо для того, чтобы команда разработчиков могла не только реализовать функциональность, но и визуально оформить её, а также обеспечить правильную работу с данными.

Для этих целей я разрабатываю два дополнительных документа:

Спецификация по пользовательскому интерфейсу (СПИ / User Interface Specification), которая содержит макеты того, как будет выглядеть раздел «Кредитная история» для пользователя.

Спецификация по модели данных (СМД / Data Model Specification), описывающая хранение данных, использованных в функциональном дизайне.

Эти документы являются неотъемлемой частью дизайна требования и помогают разработчикам понять не только логику работы функции, но и её визуальное представление и источники данных.