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

Здравствуйте, Cynic, Вы писали:

C>В связи с этим, чтобы избежать возможных ошибок в архитектуре, решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе! Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения. Как обычно ставлю баллы за самые интересные ответы)

Например Firmware для любой железки. Интерфейса нет, функциональность есть.

Чтобы избежать ошибок надо думать чуть более общими категориями.
Через UI можно понять как пользователь ожидает увидеть реализацию функционала. По сути полное описание UI является приемочным тестом для программы. Концепцию приемочных тестов можно распространить на любое ПО. Более того во многих методологиях разработки закреплено использования приемочных тестов, от нашего ГОСТа (ЕСПД), до XP.

Здравствуйте, Cynic, Вы писали:

C>В связи с этим, чтобы избежать возможных ошибок в архитектуре, решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе! Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения. Как обычно ставлю баллы за самые интересные ответы)
— Формат входных и выходных файлов
— Алгоритм расчёта
— Модель security
...

Здравствуйте, Cynic, Вы писали:

torrent качалки: способы (методы) обмена: TCP, uTP, DHTP, ...

Здравствуйте, Cynic, Вы писали:

C>привести примеры ситуаций, в которых требования не выражаются в интерфейсе!

Вы про интерфейс == UI или про интерфейс == все способы обратиться к системе?

Как пример — любая система со сторонними для вас клиентами. Классика — совместное использование одной базы данных несколькими приложениями. Посовременней — любой веб-сервис (который именно сервис, а не способ передать данные вашему клиенту).

X>torrent качалки: способы (методы) обмена: TCP, uTP, DHTP, ...

я бы сказал более общо: все, что касается OSI. В клиент-сервере это может составлять под 100% кода )).

Здравствуйте, Cynic, Вы писали:

C>Например, если программа рассчитывает динамику газа, будет важен ещё и способ её расчета. Вполне возможно, что в данном случает существует несколько способов её рассчитать и соответственно при анализе возникает сущность которая представляет именно способ это сделать.
...
C>Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения.

противоречие-с ))

Но вообще, я тоже пришел к выводу, что надо _начинать_ с проектирования гуя. И потом по нисходящей — как ни крути, придется описать все. Зато это работает как "бритва оккамы" — не придется ломать голову, куда засунуть ненужные, но уже придуманные и спроектированные сущности )), типа капюшона у носков.

Здравствуйте, Cynic, Вы писали:

C>В связи с этим, чтобы избежать возможных ошибок в архитектуре, решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе! Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения. Как обычно ставлю баллы за самые интересные ответы)

Да все нефункциональные требования: ограничения среды и реализации, производительность, зависимость от платформы, расширяемость, надежность и т.д.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Cynic, Вы писали:

C>>В связи с этим, чтобы избежать возможных ошибок в архитектуре, решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе! Давайте рассматривать НЕ специализированный софт, а обычные офисные приложения. Как обычно ставлю баллы за самые интересные ответы)

1. Все нефункциональные требования — надежность, производительность, требования к ресурсам, требования к окружающему ПО и т.д.
2. Как уже упоминали — модель безопасности (то есть варианты аутентификации и авторизации), связь с системными средствами.
3. Все алгоритмы — от правил округления до эвристик по управлению запасами.
4. Форматы логов, средства для всяческого troubleshooting'а
5. Неплохо бы предусмотреть возможности автоматического обновления версий (и вообще всю логику автоапдейта — через плагины или еще как-то). Если есть необходимость в плагинах — то нужно описать внутренние интерфейсы для плагинов.
6. Время отклика системы (это, конечно, UI — но не совсем)
7. Требования к документации (как внешней, так и внутренеей)
8. Схема аудита действий пользователя (если нужно)
9. А вообще — у каждой системы свои требования

Здравствуйте, ZevS, Вы писали:

ZS>Да все нефункциональные требования: ограничения среды и реализации, производительность, зависимость от платформы, расширяемость, надежность и т.д.

не совсем так
нефункциональное требование может влиять на UI
например, ограничение по пропускной способности канала может вынудить проектировщика
предусмотреть в интерфейсе механизмы ручного управления передачей наборов данных

Здравствуйте, _Dinosaur, Вы писали:

_D>нефункциональное требование может влиять на UI
_D>например, ограничение по пропускной способности канала может вынудить проектировщика
_D>предусмотреть в интерфейсе механизмы ручного управления передачей наборов данных

1. Под интерфейсом я понимал не только UI.
2. Одно дело влиять на интерфейс, а другое — "примеры ситуаций, в которых требования выражаются в интерфейсе", то есть требования к интерфейсу и есть требования к системе.

Здравствуйте, Cynic, Вы писали:
C>... решил Вас попросить привести примеры ситуаций, в которых требования не выражаются в интерфейсе!...
Вот пример (вообще без ЮИ) просто интерфейс

interface CriticalSection {
  void Lock();
  void Unlock();
}

Из него не следуют например такие требования
1. что после каждого Lock надо вызывать Unlock
2. что после Lock можно вызывать еще один Lock
3. что Lock можно вызывать из разных потоков.
...
В один и тот же интерфейс может иметь разную семантику. Которая не следует из самого интерфейса.