Вот, что я думаю по этому поводу.
Любая информационная система включает такие важные элементы как
* информационное обеспечение
* техническое обеспечение
* математическое и программное обеспечение
* организационное обеспечение
* правовое обеспечение и т.п.
Отсюда следует, что создаваемая ИС должна отвечать требованиям, которые накладываются на эти виды обеспечения.
О, ОБЕСПЕЧЕНИЕ - это один из самых дурацких терминов, всё давно хочу пройтись по нему

Что такое в данном случае ОБЕСПЕЧЕНИЕ - это ОБЪЕКТ, ПРОЦЕСС, УСЛОВИЕ, ПОДСИСТЕМА? Что-то другое? Что?
По поводу "и т.д." - лингвистическое обеспечение нужно? А технологическое? А где полный перечень? Где-таки ответы на вопросы А-Г? Кто сказал, что люой системе нужно каждое это ОБЕСПЕЧЕНИЕ?
Скажем откуда взялось требование наличия пользовательской документации? Безусловно оно вытекает из хотя бы такого факта, что система делается для людей, которые будут пользоваться ее.
ВЫТЕКАЕТ - это хорошо сказано. А если системой будут пользоваться не люди, а она инфраструктурная? Т.е. мы должны иметь перечень правил формирования требований типа:
...
Правило 143.2.а Если систему будут использовать люди, ТО нужна пользовательская документация. ЕСЛИ систему не будут использовать люди, ТО пользовательская документация не нужна.
...
Система должна иметь документацию о внутреннем устройстве. Любая система как элемент содержит такую составляющую как персонал. Соотвественно данная документация направлена на обеспечение нормальной работы персонала ИС.
Почему? Тебе для того, чтобы использовать Windows, нужно иметь документацию о её внутреннем устройстве? Покажи.
Как я понимаю, ты сам прекрасно видишь ответ на свои вопросы.
У меня есть идея для метода выявления требований, но она никак не "прекрасно видима".
По моему очень скромному мнению, целостное видение системы формируется из различных моделей и артефактов.
Короче, сплошной постмодернизм. Значит, владелец системы, который сформировал концепцию системы, которой созданная система соответствует, целостным видением её не обладает?
Требования один из таких артефактов но не единственный. Генерация требований опять же идет от общего к частному: часть требований есть результат бизнес-анализа и направлены на достижения цели бизнеса, другая часть требований пользователей или функциональных могут детализировать бизнес-требования и иметь частный характер, то есть определяющий способ реализации системы
Я бы даже сказал так, что под определённым углом всё есть требования, как всё есть игра и т.д.