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

PD>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.

F>>Не хотите статью на rsdn написать? Это новое слово в разработке требований.

PD>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.

Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!

F>>И что, всегда требования производительности более важны, чем функции системы?

PD>А кто сказал, что функции не важны или менее важны ? Я ? Ссылку!

В том, что вы написали разобраться трудновато, то все же

PD>>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.

Ну, вот перед вами 3 функции и требование чтобы никакая из них не выполнялась медленнее 2х секунд. Максима всегда такая, сделайте быстрее, если сможете. Т.е. пока вы окончательно не уперлись в предел своей квалификации, вы их не закончите? Заказчик спрашивает: "когда закончишь", а вы ему: "у нас есть еще 5 способов, которые могут повысить производительность на 2%". Заказчик: "О чём речь, делайте!"

>>Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?

PD>Зависит от задачи. Иногда новые фичи просто не нужны, а надо ускорить обработку.

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