Комментарий
У программистов в хорошо сделанной архитектуре получается практически 1:1 соответствие функционального и модульного описаний, и получается этакая двусторонняя моделька, со стороны пользователя есть вершки: функции его пользовательского интерфейса, со стороны машины есть такие же модули, реализующие функционал (они могут быть загружаемыми модулями, плагинами, подпрограммами, объектами в ООП и т.д.) и уходящие корнями к базовым системным библиотекам. Если сделано так, то требования, запросы на изменение функционала, сообщения об ошибках и прочие элементы взаимодействия с пользователем легко отображаются на куски кода, к которым это относится и к ответственному за поддержку конкретно этого куска кода. Поскольку программисты люди почти всегда ленивые, они опускают описание этого внутреннего функционального представления, существующего у них в голове для этой модели, и вспоминают о нём только тогда, когда приходится работать с тем кодом, где так ещё, или уже сейчас по глупости не делали. Собственно, потому мы в курсе разбираем пример матрицы DSM на модели мозиллы, в код которой мне лично страшно заглядывать даже сейчас, после оптимизации. Ну и собственно потому я, например, про ту же матрицу DSM услышал в первый раз на этом курсе несмотря на 9 лет работы с большим хорошо спроектированным софтом до этого. Плюс появлется некоторая дихотомичность в описаниях --- программисты говорят функциональными терминами, когда разговаривают об интерфейсе к пользователю и модульными терминами когда говорят об интерфейсе к машине. В развитых проектах, когда в них становится сложно ориентироваться новичку, обычно в какой-то момент появляется описание дерева библиотек-модулей для программистов: этот функционал ищите здесь. Или оно сразу прививается к пишущемуся коду какой-нибудь системой документирования типа Doxygen, откуда генерируется потом описание связей функция-модуль для человека.