1. Требования, нормы, проект (и в смысле project, и в смысле design), интересы стейкхолдеров и даже сами процессы и их практики -- все это "требования", и с этим нужно еще разобраться.
2. Нет процесса "управление требованиями" в ISO 15288. Там есть два разных процесса -- "сбор требований" и "анализ требований".
3. Согласно Vee-диаграмме, требования потребуются в процессах архитектурного дизайна, а также верификации и валидации (впрочем, и во всех других), поэтому они должны храниться в форме, удобной для этого использования: должна быть предусмотрена трассировка дизайн-решений к требованиям (возможно, по типу assurance case, т.е. через arguments), а для целей верификации и валидации уж точно должна быть предусмотрена форма assurance case, где к claims (соответствующих требованиям) идут связи от evidence (результаты измерений, симуляционного моделирования и других расчетов, актов испытаний и т.д.), причем через agruments -- и нужно понимать, где именно эти arguments, evidence и связи между ними (включая связи к claims) хранятся. Поэтому "IT-система управления требованиями" не должна просто учитывать требования и позволять их быстро искать. Большой вопрос о функциях этой системы, а также о хранимой в ней информации и способах с ней работать -- эти функции и способы работы должны соответствовать не только и не столько процессам "сбор требований" и "анализ требований", сколько другим процессам, в которых требования используются.
