Учёт в Требованиях — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
 
(не показано 9 промежуточных версий 2 участников)
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Учёт в Требованиях</strong></p><p>Хорошие требования хорошо задокументированы. Хорошая документация позволяет:</p><ol type="a"><li>Разделять требования к продукту и требования к его разработке в разные документы и отслеживать связь между ними,</li><li>Собирать требования относящиеся к одному и тому же объекту,</li><li>Прослеживать источники требований и причины их разработок,</li><li>Работать с требованиями, прежде всего, приоритизировать их.</li></ol><p>Матрица прослеживаемости требований (requirements traceability matrix) -- это один из самых популярных инструментов для отслеживания связей между элементами требований. Она создана в форме таблицы, каждый ряд которой относится к одному и тому же требованию, а колонки представляют различные элементы требования.</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>Колонки матрицы прослеживаемости требований варьируются в зависимости от условий проекта. Для технических требований, эти колонки могут включать:</p><ol type="a"><li>Идентификационный номер технического требования,</li><li>Объект разработки,</li><li>Исходное пользовательское требование,</li><li>Первичное существенное требование,</li><li>Требование к процессу разработки.</li></ol>
 
+
<p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, матрица прослеживаемости требований:</p>
ы которой ая с. Большинство
 
обычно бизнес-аналитики используют матрицы прослеживаемости для отслеживания требований обратно к функциям и
 
бизнес-целей или вперед к коду или другим артефактам разработки или тестовым случаям. Однако во время создания
 
и процесса анализа моделей, бизнес-аналитик может перепрофилировать матрицу прослеживаемости для анализа моделей, чтобы
 
убедитесь, что они заполнены.
 
Общие сравнения моделей и элементов моделей включают:
 
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. Разработка моделирования с использованием формата образца прослеживаемости </p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, требования нужны, чтобы:</p>
 
  
 
===Варианты===
 
===Варианты===
:разработчики создали верное изделие, а администраторы могли проверить его верность. / координаторы информационных проектов могли разработать пользовательские истории (user story). / открыть процесс разработок широкой публике. / установить единый источник истины (single source of truth).
+
:создана в виде диаграммы./ отслеживает связи между документацией./ создается в форме таблицы, а ее ряды варьируются в зависимости от условий проекта./ создается в форме таблицы, а ее колонки варьируются в зависимости от условий проекта.
  
:Следующее лектио -- '''[Определяется]]'''
+
:Следующее лектио -- '''[[Разметки в Кодах]]'''
  
 
===Термины===
 
===Термины===
:[[Требования]], [[Эпические продукты]], [[SSOT]]
+
:[[Требования]], [[Технические требования]], [[Пользовательские требования]], [[Высшие требования|Существенные требования]]
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 12:48, 2 октября 2022

Учёт в Требованиях (здесь и далее по тексту -- Лектио) -- это часть урока Суть Создания Заданий. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.


Материалы

Предшественник этого Лектио -- Конфликты Требований.

Иллюстрации

Текст (HTML)

Учёт в Требованиях

Хорошие требования хорошо задокументированы. Хорошая документация позволяет:

  1. Собирать вместе те требования, которые относятся к одному и тому же объекту,
  2. Прослеживать источники требований и причины их разработок,
  3. Расставлять требования по приоритету их реализации,
  4. Отслеживать связь между техническими, пользовательскими и существенными требованиями, а также между требованиями к продукту и его разработке.

Матрица прослеживаемости требований (requirements traceability matrix) -- это один из самых популярных инструментов для отслеживания связей между элементами требований. Она создана в форме таблицы, каждый ряд которой относится к одному и тому же требованию, а колонки представляют его элементы и даже отсылки на другие требования.

Колонки матрицы прослеживаемости требований варьируются в зависимости от условий проекта. Для технических требований, эти колонки могут включать:

  1. Идентификационный номер технического требования,
  2. Объект разработки,
  3. Исходное пользовательское требование,
  4. Первичное существенное требование,
  5. Требование к процессу разработки.

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

Варианты

создана в виде диаграммы./ отслеживает связи между документацией./ создается в форме таблицы, а ее ряды варьируются в зависимости от условий проекта./ создается в форме таблицы, а ее колонки варьируются в зависимости от условий проекта.
Следующее лектио -- Разметки в Кодах

Термины

Требования, Технические требования, Пользовательские требования, Существенные требования

Экзамен

Определения

Вопросы экзамена