Требование (CMMI)

В этом разделе рассказывается, как заполнять сведения рабочего элемента "требование". Требование передает функциональность, имеющую значение для пользователя продукта или системы. Каждое требование должно кратко формулировать, что пользователю нужно делать с помощью функции программного обеспечения, и описывать это с точки зрения пользователя. Дополнительные сведения см. в разделе Планирование проекта (CMMI).

Сведения о создании этого типа рабочего элемента см. в разделе Рабочие элементы и рабочий процесс (CMMI).

В этом разделе

Связанные разделы

Определение требования Связывание требования с другими рабочими элементами Добавление сведений, вложений и гиперссылок в требование Изменение состояния требования

Руководство по процессам Планирование проекта (CMMI) Структурирование требований в виде плана продукта Проверка требований Книги Книга "Рассмотрение" (CMMI) Панели мониторинга и отчеты Панель мониторинга хода выполнения (CMMI) Отчет "Обзор требований" (CMMI) Отчет "Ход реализации требований" (CMMI) Ссылка на поле Заголовки, идентификаторы, описание и журнал (CMMI) Назначения, рабочий процесс и планирование (CMMI) Области и итерации Связывание рабочих элементов (CMMI) Вложения

Необходимые разрешения

Для просмотра требования необходимо быть членом группы Читатели или иметь разрешение Просмотр рабочих элементов на этом узле со значением Разрешить. Для создания или изменения требования необходимо быть членом группы Участники или иметь разрешение Просмотр рабочих элементов на этом узле со значением Разрешить. Дополнительные сведения см. в разделе Управление разрешениями.

Определение требования

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

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

   

При определении требования необходимо указать Название. Все остальные поля можно оставить пустыми или принять значения по умолчанию.

Определение требования

1. В верхнем разделе формы рабочего элемента укажите сведения одного или нескольких следующих типов.

   • В поле Название (обязательное) введите краткое описание.

     Хорошие названия требований отражают значение для клиента или функциональность, которую должна реализовать команда.

   • В списке Тип требования выберите тип определяемого требования.

     Значение по умолчанию — Функция.

   • В списке Кому назначено щелкните имя участника команды, который владеет требованием.

     Примечание

     Рабочие элементы можно назначать только членам группы Участники.

     Если владелец требования не назначен, им автоматически становится создатель.

   • В списке Состояние оставьте значение по умолчанию — Предложено. В списке Причина оставьте значение по умолчанию — Новый.

     Дополнительные сведения о поле Состояние и о его использовании для отслеживания рабочего процесса см. раздел Изменение состояния требования далее в этой статье.

   • В списках Область и Итерация выберите соответствующие область и итерацию.

     Примечание

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

   • В списке Приоритет выберите степень важности требования по шкале от 1 (наибольшая важность) до 4 (наименьшая важность).

   • В списке Рассмотрение выберите подсостояние рассмотрения.

     Допустимые значения: Ожидание (по умолчанию), Подробнее, Сведения получены и Рассмотрено. Это поле определяет уровень рассмотрения требований, которые имеют состояние Предложено.

   • В списке Блокировано выберите значение Да, если какая-либо проблема мешает реализации требования.

   • В списке Зафиксировано выберите значение Да, если была выполнена фиксация для реализации требования.

2. На вкладке Сведение опишите требование и критерии, по которым команда будет определять, выполнено ли оно.

   Следует указывать как можно больше подробностей, чтобы разработчик смог реализовать требование, а тест-инженер — протестировать его.

   Ваша команда будет использовать эту информацию для создания рабочих элементов задач и тестовых случаев. Дополнительные сведения см. в разделах Задача (гибкая разработка) и Тестовый случай (гибкая разработка).

3. На вкладке Анализ опишите последствия для клиента, если требование не будет реализовано.

   Возможно, вы захотите включить сведения в рамках модели Кано касательно того, относится ли требование к категории "Неожиданное", "Обязательное" или "Очевидное".

4. На вкладке Другое укажите сведения следующих типов.

   • В разделе Эксперты выберите имена не более трех участников команды, которые знакомы с областью проблемы, а также с ожиданиями клиента касательно этого требования.

   • В поле Исходная оценка введите число, представляющее количество рабочих часов для реализации требования.

     Примечание

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

   • В списке Встроено в выберите имя или номер построения, в которое командой разработчиков встраивается требование.

   • В списке Тест выберите состояние тестирования реакции пользователя для этого требования.

     Допустимые значения: Успешно, Неудачно, Не готово, Готово или Пропущено. Следует указать значение Не готово, если требование имеет состояние Активно, и значение Готово, если требование имеет состояние Разрешено.

5. На вкладках Реализация, Запросы на изменение, Тестовые случаи и Все ссылки можно создавать связи требования с другими рабочими элементами, такими как задачи, запросы на изменение, тестовые случаи, ошибки и проблемы.

   На вкладке Вложения можно прикрепить спецификации, изображения или другие файлы, которые содержат дополнительные сведения о реализуемом требовании.

   Дополнительные сведения см. в следующих подразделах далее в этом разделе:

   • Связывание требования с другими рабочими элементами

   • Добавление сведений, вложений и гиперссылок в требование

6. Нажмите кнопку Сохранить рабочий элемент.

   Примечание

   После сохранения требования в заголовке на панели инструментов рабочего элемента отобразится идентификатор.

Связывание требования с другими рабочими элементами

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

С помощью вкладок Реализация, Запросы на изменение, Тестовые случаи и Все ссылки можно создать связи для определенных типов рабочих элементов и определенные типы связей. Дополнительные сведения об ограничениях для каждой вкладки см. в разделе Связывание рабочих элементов (CMMI).

Примечание

Для отчетов "Обзор требований" и "Ход реализации требований" необходимо создавать ссылки между требованиями и задачами, а также между требованиями и тестовыми случаями.

Создание задачи, ошибки, запроса на изменение, тестового случая или другого рабочего элемента и связывание их с требованием

1. Откройте форму рабочего элемента для требования и выполните одно из следующих действий.

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

   • Чтобы создать связанный запрос на изменение, перейдите на вкладку Запросы на изменение и нажмите кнопку Создать.

   • Чтобы создать связанный тестовый случай, перейдите на вкладку Тестовые случаи и нажмите кнопку Создать.

   • Чтобы создать связанный рабочий элемент любого другого типа, перейдите на вкладку Все ссылки и нажмите кнопку Создать.

   Откроется диалоговое окно Добавить новый связанный рабочий элемент.

   

2. В списке Тип ссылки оставьте значение по умолчанию или выберите один из следующих вариантов:

   • Чтобы создать связь с задачей, ошибкой или вложенным требованием, выберите Дочерний элемент.

   • Чтобы создать связь с запросом на изменение, выберите Чем затронут.

   • Чтобы создать связь с тестовым случаем, выберите Тест выполнил.

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

3. В списке Тип рабочего элемента выберите тип создаваемого рабочего элемента.

4. В поле Название введите краткое, но точное описание выполняемой работы.

5. (Необязательно) Введите дополнительные сведения в поле Комментарий и нажмите кнопку ОК.

   Откроется форма рабочего элемента для указанного типа рабочего элемента, которая содержит предоставленные сведения.

6. Укажите остальные поля согласно описанию, которое приводится в следующих разделах.

   • Задача (CMMI)

   • Ошибка (CMMI)

   • Запрос на изменение (CMMI)

   • Тестовый случай (гибкая разработка)

   • Проблема (CMMI)

   • Риск (CMMI)

   • Рецензирование (CMMI)

7. Нажмите кнопку Сохранить рабочий элемент.

Связывание нескольких существующих рабочих элементов с требованием

1. Откройте форму рабочего элемента для требования и выполните одно из следующих действий.

   • Чтобы создать связь с одним или несколькими задачами, ошибками или вложенными требованиями, перейдите на вкладку Реализация и нажмите кнопку Добавить ссылку на.

   • Чтобы создать связь с одним или несколькими запросами на изменение, перейдите на вкладку Запросы на изменение и нажмите кнопку Добавить ссылку на.

   • Чтобы создать связь с одним или несколькими тестовыми случаями, перейдите на вкладку Тестовые случаи и нажмите кнопку Добавить ссылку на.

   • Чтобы создать связь с одним или несколькими рабочими элементами других типов, перейдите на вкладку Все ссылки и нажмите кнопку Добавить ссылку на.

   Откроется диалоговое окно Добавить ссылку на требование.

   

2. В списке Тип ссылки оставьте значение по умолчанию или выберите один из следующих вариантов:

   • Чтобы создать связь с задачей, ошибкой или вложенным требованием, выберите Дочерний элемент или Родительский элемент.

   • Чтобы создать связь с запросом на изменение, выберите Чем затронут.

   • Чтобы создать связь с тестовым случаем, выберите Тест выполнил.

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

3. Нажмите кнопку Обзор.

   Появится диалоговое окно Выбор связанных рабочих элементов.

   

4. Введите элементы в поле Идентификаторы рабочих элементов или перейдите к элементам, с которыми необходимо создать связь.

   Кроме того, для поиска рабочих элементов, на которые необходимо сослаться, можно выполнить командный запрос. Это может быть запрос "Активные ошибки", "Запросы на изменение", "Открытые задачи" и "Открытые тестовые случаи".

5. Установите флажок рядом с каждым рабочим элементом, который необходимо связать с требованием.

   Дополнительные сведения см. в разделе Поиск рабочих элементов для связывания или импорта.

6. (Необязательно) Введите описание связываемых рабочих элементов.

7. Нажмите кнопку ОК, затем Сохранить рабочий элемент.

   Примечание

   Требование и связанные рабочие элементы будут обновлены.

Добавление сведений, файлов и гиперссылок в требования

Добавить в требование дополнительные сведения можно следующими способами.

• Ввести сведения в поле Описание или в поле Журнал на вкладке Сведения.

• Вложить файл.

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

• Добавить гиперссылку на веб-сайт или файл, хранящийся на сервере или веб-сайте.

Добавление в требование сведений

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

   При каждом изменении рабочего элемента участником команды в журнал рабочего элемента заносится дата изменения, имя участника команды, внесшего изменения, и сведения об измененных полях.

   Можно использовать средства форматирования для выделения важных фрагментов текста или для формирования маркированного списка. Дополнительные сведения см. в разделе Заголовки, идентификаторы, описание и журнал (CMMI).

2. Нажмите кнопку Сохранить рабочий элемент.

Прикрепление файла к требованию

1. На вкладке Вложения выполните одно из следующих действий.

   • Перетащите файл в область вложений.

   • Скопируйте файл и щелкните или нажмите сочетание клавиш CTRL+V, чтобы вставить его.

   • Нажмите кнопку Добавить, а затем Обзор. В диалоговом окне Вложение введите имя или укажите расположение добавляемого файла.

     (Необязательно.) Введите дополнительные сведения о вложении в поле Примечание.

     Чтобы закрыть диалоговое окно Вложение, нажмите кнопку ОК.

2. Нажмите кнопку Сохранить рабочий элемент.

Добавление в требование гиперссылки

1. На вкладке Все ссылки щелкните Добавить ссылку на.

   

2. В списке Тип связи выберите Гиперссылка.

3. В поле Адрес укажите адрес целевого объекта ссылки.

   Если целевым объектом является веб-сайт, введите URL-адрес (или скопируйте его из интернет-браузера и вставьте) в поле Адрес. Если целевым объектом является расположение на сервере, введите адрес в формате UNC.

4. (Необязательно) Введите дополнительные сведения о гиперссылке в поле Примечание.

5. Нажмите кнопку ОК, затем Сохранить рабочий элемент.

Изменение состояния требования

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

• Предложено

• Активно

• Разрешено

• Закрыто

При создании требования ему автоматически присваивается состояние Предложено. Принимая требование для текущей итерации, команда переводит его в состояние Активно и создает задачи для его реализации. Когда команда выполняет задачи и системные тесты показывают, что требование успешно реализовано, оно переводится в состояние Разрешено. Наконец, после проверки командой требования оно переводится в состояние Закрыто.

Состояние требования может изменить любой участник команды.

Дополнительные сведения о полях данных, с помощью которых можно отслеживать состояния рабочих элементов, см. в разделе Назначения, рабочий процесс и планирование (CMMI).

Изменение состояния требования

1. Откройте форму рабочего элемента для требования.

2. В списке Состояние выберите вариант Активно, Разрешено или Закрыто.

   • При изменении состояния с Предложено на Активно поле Причина автоматически примет значение Принято.

   • При изменении состояния с Активно на Разрешено поле Причина автоматически примет значение Кодирование завершено, и системный тест пройден.

   • При изменении состояния с Разрешено на Закрыто поле Причина изменится на Проверка пройдена.

   • Если изменить состояние с Активно на Закрыто, в списке Причина следует выбрать параметр, который соответствует вашим намерениям.

     Допустимые параметры: Разделено (по умолчанию), Отброшено и Вне области.

3. Нажмите кнопку Сохранить рабочий элемент.

Типовая последовательность рабочего процесса Участник команды создает требование в состоянии по умолчанию Предложено с причиной по умолчанию Новые. Член команды изменяет состояние Предложено на состояние Активно, используя причину по умолчанию — Принято. После завершения кодирования и прохождения системных тестов участник команды изменяет состояние требования с Активно на Разрешено. После проверки соответствия ожиданиям клиента участник команды изменяет состояние требования с Разрешено на Закрыто. Переходы вне стандартного процесса Участник команды изменяет состояние Предложено на состояние Закрыто, используя причину по умолчанию — Отклонено. Участник команды изменяет состояние Активно на состояние Предложено, используя причину по умолчанию — Исследовать. Участник команды устанавливает, что требование не актуально или находится вне области проекта, и изменяет состояние с Активно на Закрыто. Требование не проходит проверочный тест. Следовательно, участник команды изменяет состояние с Разрешено на Активно. Участник команды устанавливает, что требование было закрыто по ошибке или теперь попадает в область проекта, и изменяет состояние с Закрыто на Активно.

Схема состояний требования

"Предложено" (новые)

Следующие поля данных регистрируются автоматически при создании требования.

• Кем создано: имя участника команды, создавшего требование.

• Дата создания: дата и время создания требования в соответствии с часами сервера.

С "Предложено" на "Активно"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Принято	Если комиссия по рассмотрению утвердила требование для реализации в текущей итерации.	Назначьте требование участнику команды, который будет его реализовывать.
Исследовать	Если комиссия по рассмотрению установила, что команда должна изучить последствия для клиента, прежде чем принимать решение о необходимости реализации требования.	По завершении исследования верните требование в состояние Предложено.

Следующие поля данных регистрируются при изменении состояния требования на Активно.

• Активировал: имя участника команды, который активировал требование.

• Дата активации: дата и время активации требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

С "Предложено" на "Закрыто"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Отклонено	Если комиссия по рассмотрению установила, что команда не может реализовать требование или что клиенту это уже не нужно.	Нет.

Следующие поля данных регистрируются автоматически при закрытии участником команды требования.

• Кем закрыто: имя участника команды, закрывшего требование.

• Дата закрытия: дата и время закрытия требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

Активно

Команда должна реализовывать только требования, находящиеся в состоянии Активно. Для активных требований участники команды должны создавать задачи по написанию кода, тестированию и документированию требования. После выполнения всех задач требование переходит в состояние на Разрешено. Участник команды может также закрыть требование, если оно разделено, отброшено или выходит за пределы области.

С "Активно" на "Разрешено"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Кодирование завершено, и системный тест выполнен	Команда вернула код для реализации требования, и все системные тесты пройдены.	Назначьте требование участнику команды, который будет его тестировать.

Следующие поля данных регистрируются при разрешении активного требования.

• Кем разрешено: имя участника команды, разрешившего требование.

• Дата разрешения: дата и время разрешения требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

С "Активно" на "Закрыто"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Разделено (по умолчанию)	Если требование слишком велико или его необходимо определить более точно.	Создайте одно или несколько дополнительных требований и свяжите их с исходным требованием. Новые требования должны приниматься с состоянием Активно.
Отброшены	Если команда больше не должна реализовывать требование.	Нет.
Вне области	Если у команды не хватает времени для реализации требования в текущей итерации или были выявлены проблемы, препятствующие реализации.	Укажите, в какой итерации требование может быть реализовано. Если требование будет отложено до следующего выпуска программы, оставьте поле "Итерация" пустым, но опишите подробно, почему требование было отложено и когда команда должна его реализовать.

Следующие поля данных регистрируются при закрытии активного требования.

• Кем закрыто: имя участника команды, закрывшего требование.

• Дата закрытия: дата и время закрытия требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

С "Активно" на "Предложено"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Отложено	Если команда не будет реализовывать требование в текущей итерации, но может сделать это в будущих итерациях.	Нет.
Исследование завершено (по умолчанию)	Если команда исследовала требование и отправляет его на повторное рассмотрение.	Нет.

Следующие поля данных регистрируются при закрытии активного требования.

• Кем изменено: имя участника команды, изменившего состояние требования.

• Дата изменения состояния: дата и время изменения состояния требования.

Разрешено

После реализации требования в коде и прохождения системных тестов ведущий разработчик устанавливает состояние Разрешено и назначает требование тест-инженеру. Тест-инженер проверяет, соответствует ли его реализация ожиданиям клиента. Если да, тест-инженер закрывает требование. Если нет, тест-инженер повторно активирует его для дальнейшей работы.

С "Разрешено" на "Закрыто"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Проверка пройдена	Если требование прошло все связанные с ним проверочные тесты.	Назначьте требование владельцу продукта.

Следующие поля данных регистрируются автоматически при закрытии разрешенного требования.

• Кем закрыто: имя участника команды, закрывшего требование.

• Дата закрытия: дата и время закрытия требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

С "Разрешено" на "Активно"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Сбой проверочного теста	Если проверочный тест показывает, что требование не соответствует одному или нескольким ожиданиям клиента.	Зарегистрируйте проблемы как ошибки и назначьте требование ведущему разработчику.

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

• Активировал: имя участника команды, который повторно активировал требование.

• Дата активации: дата и время повторной активации требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния требования.

Закрыто

Команда не должна работать над закрытым требованием, так как оно было отклонено или успешно реализовано, проверено и подтверждено.

Команда может повторно активировать закрытое требование, если оно вновь попадает в область текущей работы. Обычно закрытое требование повторно активирует бизнес-аналитик или менеджер программы.

Из состояния "Закрыто" в состояние "Активно"

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

Причина	Условия использования	Дополнительные действия, которые следует предпринять
Возврат в область действия	Если имеются ресурсы для реализации требования.	Убедитесь, что задачи по реализации, тестовые случаи и сведения, определенные для требования, определены полностью и актуальны.
Закрыто по ошибке	Если требование было закрыто случайно.	Убедитесь, что задачи по реализации, тестовые случаи и сведения, определенные для требования, определены полностью и актуальны.

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

• Активировал: имя участника команды, который повторно активировал требование.

• Дата активации: дата и время повторной активации требования в соответствии с часами сервера.

• Дата изменения состояния: дата и время изменения состояния рабочего элемента требования.

См. также

Другие ресурсы

Артефакты (CMMI)

Рабочие элементы и рабочий процесс (CMMI)