При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.
Таким образом, разбив концептуально целую систему на модули, я рисую ДВИ каждой подсистемы, описывая в спецификации то, как взаимодействуют с этой подсистемой пользователи + поведение самой подсистемы (алгоритмы работы - по сути те же UC, но ДЛ является сама подсистема).
Правильно ли я делаю?
Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?
Имхо в таком подходе получается месиво бизнес-архитектуры (внешняя группировка свойств системы, полезная для заказчика и аналитика) и технической архитектуры (внутренняя группировка свойств системы, полезная для архитектора и разработчика).
По моему опыту более полезно приходить к технической архитектуре через бизнес-процессы, фичи, способы применения. и их бизнес-группировку, а не так, что «модули» с техническим назначением вознимают как проектные решения раньше, чем способы применения.
Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?