greesha, твое мнение понятно и статья очень интересная. От части то, о чем ты пишешь... ловушки, терминология, уровни абстракции требований и побудило сделать этакое нечто, что помогло бы тем, кто не так долго работает в области бизнес анализа или тем, кто имеет опыт работы только в одной, двух методологии (ях)/стандарте, разобраться пусть не во всех, но многих хитросплетениях различных подходов. Я не надеялась смаппить артефакты 1х1. Мне бы хотелось, чтобы говоря в терминах BABOK ассоциативно возникало понимание в какой из артефактов ГОСТ/RUP это включается или НЕ включается (отсутствует) и каким термином оно в ГОСТе/RUP обозначется. В свое время Юрий Булуй делился своей презентацией под названием "Классификация требований к ПО и ее представление в стандартах и методологиях", в рамках которой, не смотря на то, что упор в ней делается больше на требования, я нашла любопытные для себя материалы. Приведу вырезку (см. вложение). Вот что то подобное хотелось бы сделать.
Я как раз сегодня об этом думал, в связи с работой над одним ТЗ.
И даже хотел бы оформить свои мысли в статью, но они для этого пока недостаточно проработаны.
Если коротко: ТЗ по ГОСТ 34, если положить его на классификацию Вигерса, должно содержать только бизнес-требования, причём довольно высокого уровня. Предполагалось, что их более детальная разработка будет выполняться на этапах эскизного и технического проектов.
Само ТЗ по ГОСТ - это что-то чуть более детальное, чем Vision, но не дотягивающее до уровня спецификации вариантов использования.
То есть на том слайде, который ты привела, связь между FunctionalRequirements и "Требованиями к функциям (задачам)" - это тоже терминологическая ловушка, требующая дополнительных разъяснений.
В ТЗ по ГОСТ должны быть просто перечислены функции и задачи. Там, где возможно, - приведены целевые показатели ("система должна обеспечивать одновременное ведение до 100 целей").
А Functional Requirements должны быть уже детально проработаны на уровне (например) сценариев юскейсов.
И такая ситуация практически со всеми связями между артефактами. Они, вроде бы, логичны и имеют право на существование, но при этом для каждой связи нужно дополнительно объяснять разницу в контекстах с одной и другой стороны. Проблема в том, что эти объяснения либо проигнорируют, либо неправильно поймут.
Голосование
Обзор методологий