Комментарии 5
Матрица требований - это один из способов ВИЗУАЛИЗАЦИИ СВЯЗЕЙ. Способы визуализации бывают разные. Можно нарисовать на бумаге схему станций метро, но называть ее инструментом управления метро вряд ли можно.
По определению управление требованиями подразумевает несколько иное значение, чем управление станцией метро:
Управление требованиями к программному обеспечению (англ. software requirements management) – процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритизацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц
Управление в данном контексте включает в себя документирование, анализ и отслеживание. Матрица трассировки требований используется для решение данных задач, что делает её инструментом, который используется в управлении требованиями.
Соглашусь, что матрица является способом визуализации связей. Но все же это контекст управления требованиями.
В таком случае я согласен с предыдущим оратором, вы снова про инструмент вместо процесса.
Процесс - это про то, как вы выявляете требования. На старте, в середине, на завершении проекта и в процессе эксплуатации продукта. Процесс - это как вы работаете с требованиями. Стратегически, тактически, календарно и так далее, не в каком инструменте, а как и почему
Ключевой посыл любого требования - это нахера. Нахера оно надо заказчику? а продукту? А команде? Инструмент, который не отражает ответа на этот вопрос - это скорее карта, визуализация, и чек-лист, но это соблюдение опять же, а не выявление и работа с требованием. И как следствие, у вас спутана роль - эта штука про QA и тестирование требований, а не про анализ. От анализа здесь ничего нет, это другой контекст, к сожалению.
Это не плохо, статья была полезна для меня, например, я ее для qa как раз и покажу. Но тяжело будет получить релевантную аудиторию аналитиков, я бы переименовал тогда, и картинка сложится
Так как управление требованиями включает в себя документирование, анализ, отслеживание, то матрица - инструмент управления. Я не называю матрицу процессом, она является средством, которое используется в нём.
Ключевой посыл любого требования - это нахера. Нахера оно надо заказчику? а продукту? А команде?
Не соглашусь. Требования, грубо говоря, описывают ожидаемые конечный результат. Формат пользовательских историй, например, содержит обоснование необходимости. Эту информацию можно включить в требования. Но требования не являются обоснованием необходимости, это не главная их задача. Ответы на перечисленные вопросы скорее содержатся в бизнес-цели, бизнес-задаче, описании доработки или назначении.
И как следствие, у вас спутана роль - эта штука про QA и тестирование требований, а не про анализ. От анализа здесь ничего нет, это другой контекст, к сожалению.
Я описала в статье кейсы, где матрица используется не только для анализа взаимосвязей тестов и требований. Матрицу также можно использовать для отслеживания связей различных видов требования и не только. Инструмент действительно в основном используется для задач QA, но его также можно использовать и в других задачах.
В самом начале. Непонятно, откуда родились НФТ. Про ФТ всё честно: БТ-ФТ.
Вероятно, должно быть (БТ+ФТ)-НФТ
Там же. ФТ-ТК (тест-кейсы). Логичнее (ФТ+UC)-ТК. Потому как ТК это, фактически, UC с результатом из ФТ
функционал реализован, но не соответствует бизнес-требованиям
Всё-таки, "функциональность" звучит приятнее для слуха профессионала :)
Главное, тут непонятно, откуда тогда взялась функциональность (мы же всё страссировали при проектировании, верно?). Тут что-то не то или с мыслью, или с формулировкой.
Контроль полноты реализации требований. Позволяет убедиться, что каждое требование было учтено и реализовано в системе. Здесь можно использовать соответствие функциональных и бизнес-требований
Какое отношение имеет соответствие ФТ и БТ, и что использовано в разработке? Надо проверять через все цепочки БТ с результатом (тестами) разработки. ФТ тут промежуточные
Ну там много чего дальше, нет времени, ссори
Матрица трассировки требований: руководство для системного аналитика