Структурируем документацию проекта. Часть 2
Начало структуры в первой части.
3. Архитектура продукта
Раздел с описанием нефункциональных требований, функциональных элементов продукта, модели данных, структуры БД.
3.1. Описание компонентов
Приводим информацию по компонентам системы, готовим диаграмму с отображением зависимостей между компонентами продукта, интерфейсом компонентов, используемых СУБД, схем данных и связи с компонентами других продуктов. Также отрисовываем диаграмму развертывания с целевую схемой развертывания компонентов продукта. Данный раздел правильнее всего отдать на проработку архитекторам.
3.2. Нефункциональные требования
Информация о свойствах, которыми должна обладать система. Требования могут относиться к трем категориям:
- Требования к производительности и мощности. Содержат информацию о планируемых нагрузках в пиковые моменты работы.
- Требования к безопасности. Описание гарантий защиты системы от вредоносных атак или несанкционированного доступа.
- Требования к совместимости системы. Описание среды, в которой будет содержаться информация об операционных системах, браузерах, других системах, с которыми разрабатываемая система должна слажено работать.
Пример:
Запросы в секунду: 50 запросов.
Пиковая нагрузка: 120 запросов в секунду.
Google Chrome версии 74 и выше.
И т.д.
3.3. Структура БД/Справочников/Представлений
В данном разделе следует приложить модель БД, например в нотации IDEF1.х., и подготовить подробное описание структуры таблиц. Если модель большая, то описание с картинками лучше разбить на несколько разделов/подстраниц. Описание таблиц необходимо для грамотного проектирования БД и корректировки существующих таблиц (например, ввод новых полей, новых сущностей, изменение типа полей). Если на этапе аналитики указать изменения БД и обсудить их с архитекторами и разработкой, то проблем и исправлений при реализации будет в разы меньше.
3.4. Модель данных
В этом разделе приводим ER-диаграммы, отображающие разрабатываемые сущности и связи между ними.
4. Фронт документация
В этом разделе представлены пользовательские сценарии (use-cases) и описание UI-элементов.
4.1. Пользовательский сценарий
Максимально подробно проработайте и распишите основные и альтернативные пользовательские сценарии с описанием пошаговых действий пользователя и UI-откликов системы. Для визуализации можно дополнительно использовать диаграмму активности. Очень важно указывать, какие пользователи могут выполнять данный сценарий.
4.2. Описание экранных форм
В данном разделе описываем экраны и свойства UI-элементов для них. Чтобы документация была цельной настраивайте связи между элементами интерфейса, сценариями, используемыми методами и БД.
В этом кейсе я расскажу, как я из идеи об инструменте которого мне не хватало в моих рабочих процессах, с чистого листа создал в одиночку стартап, проведя его через все этапы от проектирования до запуска, своими руками (и мозгами) делая всю работу. Какой получился результат, принёс проект пользу лично мне, и оказался ли полезен людям. Погнали!
Если вы, как и я, планируете на бумаге — делюсь удачными шаблонами, нашла вот здесь
Выбрав правильное окно можно не только упростить интерфейс, но и снизить когнитивную нагрузку на пользователя, ускорив взаимодействия с ним и сделать шаги очевидными, ясными и понятными повысив удовлетворенность от использования вашего интерфейса.
В этой статье я расскажу о том, что сам безуспешно пытался найти в сети. Мне хотелось узнать, как подступиться к разработке крупной дизайн-системы, на что обратить внимание и как организовать свою работу и работу других дизайнеров, разработчиков и менеджеров. Я покажу этот процесс на своем примере.
Традиционный дайджест Юрия Ветрова, директора по дизайну и бренду Muse Group.
У нас просто накипело… Мы сами активно пользуемся интеграцией жёлтого банка и amoCRM и не могли не заметить все его косяки. Поэтому решили рассказать и показать, как можно (и нужно) сделать лучше. «Хейтерская» статья в формате «критикуешь — предлагай». Разрабы жёлтого банка, закажите у нас доработки, мы всё исправим!
Периодически я смотрю подборки с сайтами по типу Made on Tilda. Как делают красивые, но обычно неэффективные сайты.