Вы ответите, это что, шутка, мы и без тебя знаем, чем занимаемся на работе!

Что могу сказать, моё уважение.

В таком случае вы точно в курсе, что:
1) система - это всегда множество объектов, связанных между собой, существующее с какой-то целью;
2) анализ - один из фундаментальных, наряду с синтезом, методов научного познания, особенностью которого является дифференциация множеств на составляющие;
3) системное мышление - ключевой хард-скилл нашей профессии, суть которого в способности видеть и понимать системы в широком смысле слова, анализировать их элементы и связи между ними, а также наблюдать за динамикой жизненного цикла систем в контексте их целей.

Таким образом, системный, да и бизнес-анализ - это (во дела!) про интеллектуальный труд над системами, тем, что ими действительно является. И, как вы уже догадались, мы НЕ работаем с тем, что НЕ система - не состоит из связанных объектов и существует бесцельно.

Именно поэтому, приступая к очередному проекту, важно убедиться, без шуток, что вашему объекту автоматизации присущи хоть некоторые черты системы - и вы понимаете его структуру, внутренние и внешние связи, и даже готовы назвать или сформулировать целевые показатели его деятельности. Ведь только так можно рассчитывать на вероятный хэппи-энд.

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

"Не отрекаются любя" только в поэзии - нам с вами придётся грешить регулярно: отрисованная в деталях и получившая одобрение всех мыслимых стейкхолдеров бизнес-модель TO-BE, на основе которой вы уже подготовили функциональные требования, вдруг утратит актуальность как инструмент и артефакт, поскольку видение целей проекта трансформируется по ходу дела, сроки сгорят вместе с нервами, и вам не останется ничего, кроме как фиксировать задачи в постановках при участии разработчиков.

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

Да, у нас отнюдь не поэзия, но тоже своего рода творчество, где системное мышление должно дружить с гибкостью и пониманием того простого факта, что, как и в любви, важны не проявления и даже не конкретные дела, а взаимное удовольствие участников.