Бизнес-анализ от а до я: гид для начинающих. Михаил Бахрах

Чтение книги онлайн.

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

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

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

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

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

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

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

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

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

      Заключение:

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

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

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

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

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

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

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

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

      Почему визуальная составляющая хранилась в отдельном документе? На тот момент я не обладал достаточным опытом, чтобы изменить подход, но теперь предпочитаю наиболее оптимальный подход: описание функциональной и визуальной частей в одном месте. Это даёт любому пользователю артефакта сразу понятную картину: что, как и где должно работать. Модель данных, на мой взгляд, должна создаваться отдельно и не может быть представлена кусками в каждом функциональном дизайне. Цель документирования всей модели данных в одном месте – это визуализация и создание полной картины о модели данных, её корректности, логичности и связей между всеми объектами, их атрибутами и свойствами. Не буду углубляться сейчас, так как вернёмся СКАЧАТЬ