Вот ряд формальных определений требований к ПО из разных источников (кое-что было уже преведено). Я эти определения обычно давал в своих тренингах:
- Условие или возможность требуемая пользователем для решения задач или достижения целей.
- Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами
- Документальная репрезентация условий или возможностей, перечисленных в пред. пунктах.
(Ист. IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology”)

«Требования это спецификация того что должно быть получено. Требования описывают поведение системы или атрибуты и свойства системы. Требования могут являться и ограничениями на процесс разработки системы»
(Ист. Ian Sommerville & Pete Sawyer)

RUP определяет «требования» как «условие или возможность которой должна удовлетворять система» (A requirement is defined as “a condition or capability to which a system must conform”).

Касаясь интерпретации вопроса "что есть требование в ТЗ", то в качестве ответа вполне подходит "Документальная репрезентация условий или возможностей, перечисленных в пред. пунктах" из определения по IEEE Std 610.12. :-).

guest_20040621> Требование — это:

Дерьмо ваше определение. Потому, например, что требует дополнительных определений. Что есть система? Надежность, отказоустойчивость, масштабируемость, быстродействия - это свойства чего? TCO может быть свойством системы? Проектные исследования - это к чему отнести?


Прежде чем столь грубо выражаться (право, будучи анонимом это возможно без необходимости потом краснеть за свою бестактность и неосведомленность), рекомендую таки взглянуть на стандарты IEEE и увидеть в том же глоссарии определение системы на стр. 73.


guest_20040621
> И приходите к нам
В России, уважаемый, нечему учиться.

Довелось поучиться за рубежом, есть с чем сравнивать? Там тоже есть халтура и шоу-тренинги, так что я бы не стал так уж категорично ...
А учиться нужно у конкретных людей, не важно в России или за рубежом.

guest_20040621> Прежде чем столь грубо выражаться
Абсолютно адекватно.
> рекомендую таки взглянуть на стандарты IEEE и увидеть в том же глоссарии определение системы на стр. 73.
Дружище, когда писались эти стандарты? Еще более окаменевшее дерьмо мамонта в качестве ссылки привести слабо? Требования не ограничиваются функциональными требованиями. Например, лицензионные ограничения компонентов системы - абсолютно законное и распространенное требование. И оно никак в функциональные требования не укладывается. Ы? Когда писались эти стандарты, никто и не подозревал о SaaS, cloud computing и связанных с этим публичных сервисах. Ы?

Выражаться "по-быдляцки" будет адекватным в другом месте, если в вашем окружении это принято -- не переносите ваши привычки сюда. Соблюдайте элементарные правила хорошего тона и не демонстрируйте свою невоспитанность. Да и пока что вы не показали глубоких знаний вопроса, чтобы иметь моральное право на "быдляцкое панибратсво".
Второй момент -- вы неверно интерпретируете сказанное ... Посмотрите например тот же IEEE 830 и увидите, что там не только функциональные требования фигурируют.

guest_20040621
> Довелось поучиться за рубежом, есть с чем сравнивать?

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


Вот так всегда ... "Сложеницина я не читал, но осуждаю ...".


guest_20040621> А учиться нужно у конкретных людей, не важно в России или за рубежом.
Чушь собачья. Образование - это школа. В России не только школы нет, а и софта нормального пишется - кот наплакал.

Молодой человек, похоже уровень тестостерона в вашей крови зашкаливает. Есть более приятные способы его уменьшения, чем выливать потоки дефикаций в форуме. Или у вас синдром "непризнанного гения"?
А школы действительно нет. Но что лично вы сделали чтобы она появилась?

guest_20040621> Чушь или нет - это уже вопрос качества определения требований к решению.

Нет. Специально обращаю внимание: ни договорные отношения заказчика с исполнителем, ни пожелания не могут быть предметом требований. Только проект, только то, что связано с проектом, только то, что формализуемо. На самом деле разницу легко понять интуитивно: требования могут включать в себя только то, что можно протестировать или формально оценить каким-то еще образом. Кроме того, не все требования должны включаться в техническое задание. В виде отдельного документа вполне могут существовать требования к квалификации обслуживающего персонала или пользователей, например. Почему я и сказал, что для ответа нужен дополнительный контекст.

Вот и я говорю каша в головах ... в т.ч. в вашей. Не путайте требования к ПО (software requirements) и требования к АС (по ГОСТ 34.602). Вот как раз АС включает требования к квалификации персонала и т.п. Я не зря говорил, что к определениям нужно относиться с уважением, не зря говорил чтобы вы почитали таки что есть система по IEEE. Т.к. по ГОСТ 34, система в терминах IEEE будет только частью АС.

P.S. Уж столько критики навели ... что закрадывается мысль, что у вас есть сокровенное, всеобъемлющее определение требований, которое вы никак не хотите опубликовать :-). ... Ваше определение в студию! Право же, не стесняйтесь ...