использовала еще вариант через таблицы. В них указываешь номера подпунктов в первом столбце, во втором - поле в json, а дальше столбцы по желанию - тип, пример, источник.

Нет json, есть только sql запрос. =)

Иначе проще написать отдельно логику заполнения полей (тогда не понадобится добавлять столбцы и выйгаем в месте).

+ менять будете в одном месте всё

Таблица со ссылками на алгоритмы заполнения.

Стоит иметь в виду, что у разработчиков может быть ORM и им описание в терминах таблиц реляционной БД может быть даже не совсем понятным )).

Ну, я делаю схему, в которой описываю например get-запрос (ссылка ведёт как на request, так и response в одной таблице), алгоритм присвоения (ссылка на алгоритм), ответ на get-запрос (без ссылки).

Да, ORM им взрывает мозг

Приходится использовать некоторый объект контекста (как объект this в java или что-то вроде того).

Понятно, выходит только в таком описании работать и можно. Лио выползать на уровень бизнес-описаний, чтобы разраб сам искал данные.

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

Что она собой представляет:
- Саморевью своей же документации с точки зрения потребителя документации через 2-3 года, доработка документации.
- Проверка качества записи ограничений (все важные ограничения должны найти отображение в общем списке ограничений, все ошибки должны иметь ссылки на ограничения).
- Проверка качества связки системных требований с бизнес-требованиями, проставляем ссылки, если надо и забыли.
- Проверка качество ссылок между задачами и документацией.

- Поиск хвостов (незакрытых активностей, непонятных моментов). Здесь мы разгружаем голову от контекста задачи и переносим их на внешние хранители, возможно передавая управления другим людям. Что делаем:
  1. Ищем то, что ещё требуется сделать по проекту.
  2. Создаём задачи на доработку, указываем крайних (иногда это мы сами, но задача позволит выгрузить нужный кусок контекста, чтобы к нему можно было бы вернуться впоследствии).
  3. Производим поиск хотелок заказчиков (не задачи, а именно хотелки, которые не заапрувлены или которые можно сделать по-ходу дела), записываем их в отдельном месте (у меня это вкладка Future Ideas в карточке проекта).
  4. Ищем несформированные задачи (у Дорофеева это задачи, по которым следует "Подумать потом"). Пытаемся их сформироваться во вменяемые задачи и паркуем во внешнем хранилище. Создаём митинги при необходимости.

- Участие в приёмке очень рекомендуется.
- Производим сбор по своей работе фидбека от внутренней команды и заинтересованных сторон.
- Производим поиск затруднений/инцидентов в процессе работы, вместе с заинтересованными людьми ищем варианты, чтобы это не повторилось больше (это может породить ветку дополнительных активностей, митингов и задач).
- Заполняем примеры best practice, если есть куда.
- Перемещение документации из драфта в основную, закрепление в общем списке проектов (чтобы его удобно было найти. продумать путь поиска).

При этом менеджер обычно её вообще никак не видит и не ощущает. У него фаза аналитики заканчивается как только вы передали задачу в сказали. что можно разрабатывать. Вообще кажется, что вообще не касается остальная работа. Качественная документация, хвосты? Нафиг она нужна? Он будет стараться сразу ваш ресурс кинуть на следующую задачу.

[10:00] - Ну что. следующая задача?
[10:03] - Нет.
[13:00] - А теперь?
[13:10] - Нет!
[16:30] - А теперь у точно новая задача!??
[17:00] - НЕТ!

ты не хочешь книгу написать?

Учитесь парковаться, иначе если вы пропустите эту стадию, то не выгрузите контекст задачи во внешние источники и не передадите в ответственность другим людям.
Это карается:
1. Детали задачи забываются.
2. Забывается, что что-то надо сделать и когда это сделать.
3. Вы не грузите людей их проблемами и оставляете и на себе. Делаете себя крайними.
4. Голова продолжает пассивно работать на задачей, "вспоминать" детали, чтобы не забыть, тратить мыслетопливо.
5. Сильно усложняете себе процесс погружения в задачу в будущем.
6. Добавляете возможность запуска этого проекта в параллель с другими (некоторые задачи фазы парковаиня проекта вам придётся выполнить всё равно, просто в момент, когда вы работаете с другим проектом).

И так далее.

В конце надо получить ощущение, что по проекту у вас НЕТ вопросов, активнсотей, чего-то, что вы забыли. Голова пуста.

что ни пост так опус

Я в аналитике 3.5 года, рано ещё.

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

Вот будешь перечитывать свои посты лет так через 5 и....

Но пока времени очень мало. При хреновом планировании работ и спешке в компании очень сложно что-то делать дополнительно. Даже дома.

Я уже на 1.5 недели задержал вебинар. =(