softwarerДа запросто. {A} - множество методов, упоминаемых в dfm как значения OnClick и подобных свойств. {B} - множество методов, работающих с объектами DataSet. Множества не должны пересекаться (или по вкусу более сильное условие - например, не должны вызывать друг друга).

это похоже на результат, на оценку существующей декомпозиции. а меня оценка предстоящего интересует. архитектура - это скелет, на который в ширь наращивается функциональность. и вот тут интересно выбрать путь - вправо/влево

scfОбъективные метрики... Я бы назвал вот что:
- стоимость внесения изменений. Под изменениями понимаются изменения функциональности и изменения производительности (расширяемость, оптимизируемость).
- стоимость поддержки в продакшне.
- стоимость анализа функционала. Т.е. понимание того, что делает система. Очень актуально для больших и старых проектов.

Как видите, объективно архитектуру можно оценить только после того, как её реализуешь :-)

Из этих метрик следуют следующие качества хорошей архитектуры:
- простота
- расширяемость функционала с сохранением обратной совместимости
- расширяемость по железу (кластеризация)
- модульность
- документированность
- качественное логгирование и сбор статистики по использованию функционала и быстродействию системы - прежде всего, логгирования входных-выходных запросов, нагрузки и задержек
- качественная визуализация предыдущего пункта
- механизм уведомления саппорта о проблемах, понимание типовых проблем, наличие утилит и типовых методов их решения
- устойчивость к аппаратным/программным сбоям, устойчивость к некорректным входным данным, устойчивость к перегрузке

Суховато получилось, будь я студентом на лекции, записал бы в конспект, выучил, сдал и забыл)) Но надеюсь, что кому-то будет полезно.

я бы назвал это не функциональными требованиями . архитектура - это уже некоторая реализация требований, или, лучше, шаблон реализации