Учёт в Требованиях — различия между версиями
Gary (обсуждение | вклад) (→Текст) |
Gary (обсуждение | вклад) (→Текст) |
||
Строка 10: | Строка 10: | ||
===Текст=== | ===Текст=== | ||
− | :<p><strong>Учёт в Требованиях</strong></p><p> | + | :<p><strong>Учёт в Требованиях</strong></p><p>Хорошие требования хорошо задокументированы. Хорошая документация позволяет:</p><ol type="a"><li>Разделять требования к продукту и требования к его разработке в разные документы и отслеживать связь между ними,</li><li>Собирать требования относящиеся к одному и тому же объекту,</li><li>Прослеживать источники требований и причины их разработок,</li><li>Работать с требованиями, прежде всегом приоритизировать их.</li></ol><p>Матрица прослеживаемости требований (requirements traceability matrix) -- это один из самых популярных инструментов для отслеживания связей между элементами требований. Она создана в форме таблицы, каждый ряд которой относится к одному и тому же требованию, а колонки представляют различные элементы требования.</p><p>Колонки могут варьироваться в зависимости от условий проекта, но обычно они включают: |
+ | |||
+ | ы которой ая с. Большинство | ||
обычно бизнес-аналитики используют матрицы прослеживаемости для отслеживания требований обратно к функциям и | обычно бизнес-аналитики используют матрицы прослеживаемости для отслеживания требований обратно к функциям и | ||
бизнес-целей или вперед к коду или другим артефактам разработки или тестовым случаям. Однако во время создания | бизнес-целей или вперед к коду или другим артефактам разработки или тестовым случаям. Однако во время создания |
Версия 23:08, 9 мая 2021
Учёт в Требованиях (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Конфликты Требований.
Иллюстрации
Текст
Учёт в Требованиях
Хорошие требования хорошо задокументированы. Хорошая документация позволяет:
- Разделять требования к продукту и требования к его разработке в разные документы и отслеживать связь между ними,
- Собирать требования относящиеся к одному и тому же объекту,
- Прослеживать источники требований и причины их разработок,
- Работать с требованиями, прежде всегом приоритизировать их.
Матрица прослеживаемости требований (requirements traceability matrix) -- это один из самых популярных инструментов для отслеживания связей между элементами требований. Она создана в форме таблицы, каждый ряд которой относится к одному и тому же требованию, а колонки представляют различные элементы требования.
Колонки могут варьироваться в зависимости от условий проекта, но обычно они включают:
ы которой ая с. Большинство обычно бизнес-аналитики используют матрицы прослеживаемости для отслеживания требований обратно к функциям и бизнес-целей или вперед к коду или другим артефактам разработки или тестовым случаям. Однако во время создания и процесса анализа моделей, бизнес-аналитик может перепрофилировать матрицу прослеживаемости для анализа моделей, чтобы убедитесь, что они заполнены. Общие сравнения моделей и элементов моделей включают: n Функции в модели функций для функций в модели бизнес-целей, n Процесс переходит к функциям в модели функций, которые обеспечивают функциональность, n модели отображения-действие-реакция на шаги в потоках пользовательского интерфейса или потоках процессов, n Элементы данных на диаграмме потока данных к объектам на диаграмме взаимосвязи сущностей, n Таблицы интерфейса системы с системами на карте экосистемы, и n Переходы в таблицах состояний или диаграммах состояний к потокам процессов. На рис. 7-16 показан пример формата использования матрицы прослеживаемости для сопоставления нескольких объектов требований, которые необходимо выполнить. модельная проработка. Для получения дополнительной информации о матрице прослеживаемости см. Раздел 8.2.2.5. Хотя прослеживаемость матрицы могут использоваться для систематического сравнения некоторых моделей, модели также могут быть сопоставлены с одной другой менее формально, даже вручную, рассматривая модели рядом. L1 Шаг процесса 1 L1 Шаг процесса 1 L1 Шаг процесса 1 L1 Шаг процесса 2 L1 Шаг процесса 2 L2 Процесс Шаг 1 L2 процесс, шаг 2 L2 этап процесса 3 L2 Процесс Шаг 1 L2 процесс, шаг 2 Особенность 1 Особенность 1 Особенность 2 Особенность 3 Особенность 4 REQ001 REQ002 REQ003 REQ004 REQ005 Требование 1 Требование 2 Требование 3 Требование 4 Требование 5 L1 Шаг процесса L2 Шаг процесса Функция Требование REQID
Рисунок 7-16. Разработка моделирования с использованием формата образца прослеживаемости
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, требования нужны, чтобы:
Варианты
- разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
- Следующее лектио -- [Определяется]]