Занимаясь проектирование приложения наткнулся на одну замечательную вещь. Оказывается прототипирование интерфейса в значительной мере способствует выработке требований к приложению. И это не удивительно. Ведь приложение в конце концов должно обладать определённой функциональностью, которую надо как-то задействовать и делается это через интерфейс. Я уже было поверил в универсальный механизм выработки требований, который заключается в том, что если интерфейс реализует все необходимые функции, то он таким образом диктует требования которым должно удовлетворить в конечном счёте приложение. Таким образом список возможностей интерфейса и будет законченным списком требований. (Делая такое утверждение я не рассматривал НЕ функциональные требования)
Однако немного поразмыслив я понял, что помимо собственно возможности выполнить действие, часто важен и способ которым это действие выполняется. Например, если программа рассчитывает динамику газа, будет важен ещё и способ её расчета. Вполне возможно, что в данном случает существует несколько способов её рассчитать и соответственно при анализе возникает сущность которая представляет именно способ это сделать. При этом не обязательно, что способ должен где-то явно выбираться в интерфейсе. Способ будет просто функциональным требованием к приложению, которое явно через интерфейс ни как не выражается.
В связи с этим, чтобы избежать возможных ошибок в архитектуре, решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе! Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения. Как обычно ставлю баллы за самые интересные ответы)