Система же отличается от гвоздя тем, что управляет своими характеристиками. Т.е. как минимум сама умеет измерять свою собственную производительность, поддерживаемую нагрузку, время ответа на запрос и т.п. Кроме того, зная требования и их границы, должна уметь регулировать эти свои параметры. Уметь повысить производительность, уметь ускорить обработку сложного запроса и т.д.

Ну все, все системные админы дружными рядами пошли переквалифицироваться в управдомы

Возможно во мне заговорил бывший сисадмин  переквалифицировавшийся в управдомы.

Ну, действительно, как можно гарантировать какое-либо качество, не умея его измерять?

Возможно во мне заговорил бывший сисадмин  переквалифицировавшийся в управдомы.

Ну, действительно, как можно гарантировать какое-либо качество, не умея его измерять?

Не факт, что система должна его измерять. Может пользователь с секундомером сидит перед компьютером и ждет ответ сервера :- ).

Может пользователь с секундомером сидит перед компьютером и ждет ответ сервера :- ).

Система точно так же может сидеть перед компьютером и с секундомером ждать ответ сервера 

На производстве для этих целей имеются ОТК, а у нас - подразделения тестирования...

На самом деле вопрос с оценкой нефункциональных параметров ИС достаточно сложный и острый.

В своем докладе на ReqLabs Григорий Печенкин обращал внимание на то, что требования, не подлежащие измерению, следует отбросить, чтобы не подписаться под невыполнимым проектом. Наверное, это будет правильно.

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

В своем докладе на ReqLabs Григорий Печенкин обращал внимание на то, что требования, не подлежащие измерению, следует отбросить, чтобы не подписаться под невыполнимым проектом.

Наверное, это всё-таки был не я. По крайней мере, так я это, вроде бы, не формулировал.

Григорий, вас трудно с кем-либо перепутать, но если со мной действительно такое произошло, приношу свои извинения...

Григорий, вас трудно с кем-либо перепутать, но если со мной действительно такое произошло, приношу свои извинения...

Да что вы, какие извинения. Возможно, я сам не понял, что сказал. А скорее всего, мои общие фразы наложились на какой-то ваш конкретный опыт, и привели к таким выводам.

По сути: наверное, всё-таки, требования нельзя "отбрасывать". Лучше уж "отбросить" сам невыполнимый проект, если это возможно и если он действительно невыполнимый.

Переформулировать - конечно, с этим трудно не согласиться. Только нужно помнить, что каждая прописанная в требованиях цифра тянет за собой методику её получения, а реализация этой методики может обойтись дороже, чем собственно разработка.

Вот что говорит по поводу классификации требований BABOK:

Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.

Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

А я запомнил отличие ФТ от НФТ в следующем выражении, которое где-то вычитал: "ФТ определяют то, что делает Система, НФТ - при каких условиях она это делает".

Кстати, Наталья Желнова недавно опубликовала интересную статью про НФТ: http://softwarepeople.ru/blog/2011/07/11/non-functional-requirements01/