Каждый раз, когда приходится стартовать проект с нуля, не перестаю удивляться количеству вещей, про которые нужно подумать и принять решение. В первый раз, помню, поразился, когда понял, что разные виды обеспечения из ГОСТ 34.602 — это не "вода", как многие считают, а реально нужные и полезные разделы. Например, правовое обеспечение системы, или лингвистическое (за казенными формулировками не всегда понятно, что "лингвистическое обеспечение" — это, в том числе, тот самый ubiquitous language из DDD, а вовсе не "подписи в интерфейсе системы должны быть выполнены на русском языке").

Второй раз я был шокирован, когда понял, что у меня в проекте разворачиваются все 43 процесса из ISO 12207, и все их мне нужно контролировать! Все вот эти процессы приобретения, поставки, менеджмента решений, и даже менеджмента повторного применения активов! Ну, я-то, как нормальный программист, читал только группу технических процессов (11 штук) и группу процессов реализации программных средств (7), а вот эту всю управленческую лабуду...

И вот опять понадобилось выписать набор вопросов, по которым нужно принять решение и зафиксировать его: 1. Что нужно сделать? Какую возможность эксплуатируем / проблему решаем, почему сейчас, почему разработка программ поможет, какие есть ограничения? (первоначальное ТЗ) 2. О чем вообще мы говорим? (Глоссарий) 3. Что происходит? (Верхнеуровневая схема процесса, перечисление основных шагов) 4. Кому это нужно и зачем? (Реестр стейкхолдеров, их интересов и уровня влияния) 5. Как мы организуем работу? (Модель SDLC, подход к управлению задачами и релизами, выбор технических решений по ведению списка задач, хранению знаний проекта, фиксации решений, коммуникации. То есть, буквально: работаем недельными спринтами, релиз в конце каждого спринта, задачи записываем в Jira в виде юзер-сторей, а потом бьем на задачи для фронта и бэка, исходники храним в Gitlab, еженедельно созваниваемся по следующим вопросам, текущая переписка в таком-то мессенджере) 6. Как мы принимаем решения? (Регламент по приему различных решений: бизнесовых, организационных, по ахитектуре и функциям системы) 7. Что нужно сделать? (Описание функций системы) 8. Как это должно работать и изменяться? (Нефункциональные требования и характеристики) 9. Что из готового мы можем использовать / купить? (Политика использования готовых компонентов и сервисов) 10. С чем нам нужно будет интегрироваться или обмениваться данными? (Внешнее окружение) 11. Как это будет выглядеть снаружи? (Функциональная архитектура) 12. Как это будет устроено внутри? (Техническая архитектура) 13. Как мы это будем развертывать и обновлять? (Описание процессов развертывания) 14. Как мы будем предъявлять результаты работы? 15. Как мы докажем, что сделали то, что нужно и хорошо? (ПМИ в каком-то виде)

15 пунктов, я уже устал писать, а мы ведь не коснулись основного содержания работы аналитика — все эти спецификации требований, данных, экранов, API — и очень далеки от программирования. Каждый из пунктов раскрывается глубже и глубже: ок, мы выбрали, как будем фиксировать задачи, а какие поля должны быть у каждой записи о задаче? Какая у неё статусная модель? Какие условия переходов между статусами и кто должен быть информирован о них?.. Фактически, речь идёт о проработке требований к нескольким обеспечивающим системам. Да, скорее всего мы не будем их самостоятельно разрабатывать, но требования (решения) в их отношении мы должны принять. Хорошо тем, у кого эти решения уже приняты раз и навсегда, и новый проект стартует по готовым шаблонам. Но и проекты бывают разные — они же уникальные, и что подходит для одного проекта, может быть неудобным в другом. Начинай с начала!

А так как это решения, здесь должен быть выбор — ну хотя бы из двух вариантов (а в реальности их обычно больше). И каждый выбор должен быть обоснован — почему выбрали это решение и отвергли альтернативы? Если написать хотя бы 2-7 страниц по каждому пункту, это уже документ под сотню листов! А мы ещё не начали толком ничего делать. И работа по проработке требований к обеспечивающим системам проекта обычно остается невидимой.