При написании требований часто возникает вопрос, на каком уровне должны быть детализированы требования и какие артефакты должны появиться в результате системного анализа.
Я стараюсь придерживаться позиции, что это сугубо индивидуально и зависит от команды и того, кому с ней комфортно работать.
Бывает, что разработчикам достаточно варианта использования, чтобы сделать дизайн, а тестировщикам этого достаточно, чтобы написать тест-кейсы.
Поэтому я буду писать о тех артефактах, которые могут возникнуть при написании требований и о которых нужно тщательно подумать к моменту завершения разработки, а вы сами решите и договоритесь внутри команды, когда стоит описывать.
Ясно одно: к концу разработки документация должна содержать все, о чем пойдет речь дальше.
Если не учитывать мелкие возможности, реализация которых требует незначительных доработок, то можно достаточно просто внести изменения в существующие описания.
Системно можно выделить два типа задач, которые возникают в работе системного аналитика и описывать их нужно по-разному:
- Задача разработки нового сервиса или новой функциональности, которая лишь косвенно влияет на другие системы или компоненты.
- Задачи, реализация которых требует доработок в ряде систем по процессам (а как известно, системы часто сегментируются по процессам, а бизнес-функция обычно проходит по всему конвейеру и улучшения требуются в ряде систем)
Для описания задач первого типа я выделил следующую структуру и блоки описания:
Общие требования
Блок, предполагающий обозначение контекста.Что это за система, чему она служит, какие объекты содержит, каковы ее границы.
- цель Необходимо четко сформулировать цель системы и для чего она служит. - описание Описание границ системы, какие задачи решает система, в общих чертах опишите функционал.
- термины и сокращения Приведение в табличной форме основных терминов, сокращений и их определений, если они есть в документации.
Конечно, например, в Confluence есть функционал терминов, но, к сожалению, реализовать эту практику для всех оказывается сложно, поэтому иногда проще включить этот раздел.
- Полезные ссылки Ссылки на внешние источники, прикрепленные документы.
Ссылки на внутренние документы, которые могут быть полезны.
Нефункциональные требования
Пожалуй, один из самых важных блоков и то, о чем обязательно должен задуматься системный аналитик.Наиболее важные требования, которые я выделяю и которые почти всегда нужно описывать, — это производительность, доступность и масштабируемость.
Существует множество источников, в которых подробно описано, как рассчитать эти показатели.
Если мы говорим о данных, мы должны учитывать правовые ограничения, конфиденциальность, время хранения.
Используемые технологии
Необязательный блок, в котором можно перечислить языки программирования (также используемые библиотеки), технологии интеграции, СУБД.
Случаи использования
Это до боли известно всем аналитикам, и я даже не буду останавливаться на этом блоке.И конечно, все варианты использования должны присутствовать в документации и быть хорошо проработанными.
Выбирайте метод описания на свой вкус, будь то текстовое описание или UML-диаграммы.
Схема компонентов
Диаграмма компонентов из нотации UML. Позволяет понять, из каких частей состоит система и какие взаимодействия происходят на верхнем уровне.В нем может быть дано описание конкретной системы, но я предпочитаю дополнять схему компонентами, с которыми эта система/сервис может взаимодействовать.
Обязательно включите пояснения в текст диаграммы.
Модель данных
Диаграмма классов или диаграмма ER. Опишите основные сущности, которые предполагается использовать в системе.Это одна из определяющих вещей, поскольку почти всегда, как ни странно, границы сервисов и контекстов лежат вокруг данных.
И при проектировании систем всегда проще начать с данных и приступить к их структурированию.
И когда решается вопрос, где разместить необходимый функционал, интуитивно начинаешь задумываться, правильно ли здесь размещать сущности с данными или нет. Определите основные сущности и их атрибуты, типы, ограничения и проверки атрибутов (это часто важно).
Определите отношения между сущностями.
Интеграции
- Внешний Если необходима интеграция с внешним поставщиком данных, рисуется диаграмма последовательности, описывающая, какие данные мы собираем/поставляем на уровне звонка.Описаны все схемы сообщений, триггеры отправки, частота и особенности взаимодействия (если есть).
- Внутренний Если сервис предоставляет данные извне, то в зависимости от способа интеграции либо делается swagger (в случае интеграции через передачу сообщений), либо описываются сами структуры данных (если речь идет о шине данных), для ftp описана файловая структура и т.д. Также рисуется диаграмма последовательности для обозначения зависимостей для визуализации взаимодействия других систем с описываемой.
Для описания задач второго типа предлагается описать следующие разделы: Это несколько сложнее, так как, вообще говоря, нужно место, где описан общий процесс и где можно увидеть, как задача будет распадаться на несколько систем.
И тогда описание конкретных изменений отображается в описании соответствующей системы (что вполне логично).
Проще всего описать общий процесс следующим образом:
общее описание
Раздел, предполагающий указание контекста.Что это за функционал, каково назначение и ограничения.
Пользовательский сценарий (вариант использования)
Описание пользовательских сценариев для общей задачи с указанием всех альтернатив.
Диаграмма последовательности
Это самый простой способ отобразить взаимодействие системы и потоки данных для реализации.Необходимо весь функционал декомпозировать на системы в разрезе данных, вызовов и триггеров.
указать все связи и зависимости задач.
Далее детализируйте это на уровне каждой системы отдельно.
Теги: #Анализ и проектирование систем #Подготовка технической документации #техническая документация #архитектура программного обеспечения #анализ системы
-
Моя Безбумажная Технология
19 Oct, 24 -
Внешняя Аутентификация Для Веб-Приложения
19 Oct, 24 -
Задача О Рюкзаке В Криптографии
19 Oct, 24
