Всего за 199 руб. Купить полную версию
Описание дизайна:
"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."
Входные условия:
Для использования функциональности пользователь
должен авторизоваться в системе СУК, выбрать компанию и перейти на её главную страницу.
Описание функциональности:
Затем следует детальное описание функциональности, представленное в виде нумерованного списка. Этот список описывает шаги, которые система выполняет в ответ на действия пользователя. Подобная структура упрощает понимание логики работы системы и облегчает последующие обсуждения возможных корректировок.
Шаги/Сценарий:
На странице профиля компании система отображает раздел «Кредитная информация».
В разделе «Кредитная информация» отображаются следующие поля/данные:
Кредитный рейтинг (название) текстовое, неизменяемое.
Кредитный рейтинг (значение) неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.
Кредитный статус (название) текстовое, неизменяемое.
Кредитный статус (значение) неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.
Кредитные условия (название) текстовое, неизменяемое.
Кредитные условия (значение) неизменяемые, три текстовых поля со значениями:
а) разрешенная рассрочка: «ХХ» месяцев;
б) статус контракта: «активен», «неактивен» или «истек»;
в) размер задолженности: «нет» или «размер задолженности».
Кредитная история (название) текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).
Заключение:
Вот и всё это описание основного блока дизайна для простой функциональности, чтобы избежать множественных страниц детального описания.
Изменение данных:
В данном дизайне изменение данных не предусмотрено, так как у пользователя нет возможности изменять представленную информацию.
Функциональный дизайн готов к использованию разработчиками, но работа здесь не заканчивается. В большинстве проектов важно, чтобы функциональность, предназначенная для пользователя, сопровождалась соответствующими визуальными и дата-компонентами. Это необходимо для того, чтобы команда разработчиков могла не только реализовать функциональность, но и визуально оформить её, а также обеспечить правильную работу с данными.
Для этих целей я разрабатываю два дополнительных документа:
Спецификация по пользовательскому интерфейсу (СПИ / User Interface Specification), которая содержит макеты того, как будет выглядеть раздел «Кредитная история» для пользователя.
Спецификация по модели данных (СМД / Data Model Specification), описывающая хранение данных, использованных в функциональном дизайне.
Эти документы являются неотъемлемой частью дизайна требования и помогают разработчикам понять не только логику работы функции, но и её визуальное представление и источники данных.
Почему визуальная составляющая хранилась в отдельном документе? На тот момент я не обладал достаточным опытом, чтобы изменить подход, но теперь предпочитаю наиболее оптимальный подход: описание функциональной и визуальной частей в одном месте. Это даёт любому пользователю артефакта сразу понятную картину: что, как и где должно работать. Модель данных, на мой взгляд, должна создаваться отдельно и не может быть представлена кусками в каждом функциональном дизайне. Цель документирования всей модели данных в одном месте это визуализация и создание полной картины о модели данных, её корректности, логичности и связей между всеми объектами, их атрибутами и свойствами. Не буду углубляться сейчас, так как вернёмся к этому позже в следующих шагах подробно.
Мы рассмотрели одно очень простое функциональное требование и функциональный дизайн. Как я упоминал, начинал я дизайн после того, как требование было проверено ведущим БА и подписано клиентом. Но когда дизайн был готов, я не мог отдать его команде разработчиков, чтобы они начали создавать эту часть системы. Не мог, потому что дизайн требовал проверки от БА, с которым я работал. Он мог указать на упущенные нюансы или моменты, которые нужно было поправить. Когда вся функциональная спецификация была готова, мы её отдавали клиенту на проверку.
Вот, собственно, что я хотел рассказать про реальные первые месяцы моей работы бизнес-аналитиком. Я не общался с клиентом и не занимался выявлением бизнес- или функциональных требований таких обязанностей у меня не было, так как не было и опыта, и нужно было сначала изучить базовые активности. Я даже не знал, какой используется и из чего состоит цикл разработки программы/системы. А использовали мы методологию разработки, которая называется «Водопад» (Waterfall).
Почему «Водопад»? Потому что создание системы/продукта поделено на этапы, которые всегда выполняются в последовательном порядке один за другим. Отсутствие этих навыков и знаний было ли это плохо или негативно в плане моего опыта? На мой взгляд, нет, так как я получал полноценный опыт в самом базовом и необходимом БА навыке документирование требований и их дизайна.