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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • В Тип выберите тип требования.

     Значение по умолчанию Функциональный.

3. На вкладке описание опишите требование и условие, которому рабочая группа будет использовать для проверки ли оно было выполнено.

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

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

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

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

5. На вкладке ПРОЧЕЕ укажите сведения следующих типов.

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

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

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

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

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

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

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

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

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

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

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

7. Выберите Сохранить рабочий элемент.

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

   • Задача (CMMI)

   • Ошибка (CMMI)

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

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

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

   • Риск (CMMI)

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

7. Выберите Сохранить рабочий элемент.

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

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

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

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

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

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

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

   

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

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

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

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

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

3. Выберите Обзор.

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Выберите Сохранить рабочий элемент.

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

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

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

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

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

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

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

2. Выберите Сохранить рабочий элемент.

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

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

   

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

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

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

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

5. Выберите ОК, а затем выберите Сохранить рабочий элемент.

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

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

• Предложено

• Активно

• Разрешено

• Закрыто

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

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

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

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

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

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

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

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

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

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

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

3. Выберите Сохранить рабочий элемент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Активно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разрешено

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

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

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

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

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

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

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

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

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

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

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

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

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

Закрыто

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

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

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

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

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

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

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

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

См. также

Основные понятия

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

Раскадровка элемент невыполненной работы с помощью PowerPoint

Отзывы и предложения заинтересованного лица запроса и процессов с помощью Team Web Access

Справочник по полям рабочих элементов для Visual Studio ALM

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

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