Описание процесса ввода требований как рабочих элементов для каждой роли и типа рабочих элементов.
Руководство в отношении спецификации требований варьирует в зависимости от вашего процесса разработки программного обеспечения. Например, при использовании традиционных процессов, таких как водопад, требует более формальный процесс спецификации требований и управления ими, чем для гибкого процесса. Поскольку существуют различные гибкие процессы, мы попытаемся подойти к спецификации требований в гибких методологиях с точки зрения Scrum с учетом некоторых исключений.
Требования определяют, что продукт должен делать, чтобы решить проблему клиента. Некоторые из видов требований: сценарий, качество обслуживания, требования безопасности, функциональные требования, операционные требования и требования к интерфейсу. Требование должно начинаться с состояния Предложено, а затем, когда будет принято, оно переходит в состояние Активно, из которого после выполнения и тестирования поставленных задач, оно переходит в состояние Решено, и в конце переходит в Закрыто после проверки. Такой жизненный цикл имеет рабочий элемент требования в шаблоне процесса MSF. Вы можете определить свой жизненный цикл, который подходит Вашему процессу и последовательности работ.
В зависимости от вашего процесса, вы можете создать рабочий элемент для требования как сценарий (функциональные требования для MSF Agile), качество обслуживания (нефункциональные требования для MSF Agile), как история (XP), сценарий использования (RUP) или как требование (MSF для CMMI или Традиционный). Рабочие элементы используются для определения и отслеживания требования. Это позволяет отображать их в вашем журнале, ранжировать, проверять, назначать и формировать отчетность.
Однако независимо от используемой методологии требование проходит развитие от бизнес уровня к системному уровню, а затем к уровню реализации. В модели водопада каждый уровень полностью определяется до перехода в следующий уровень. В итерационной или гибкой модели каждое отдельное требование может пройти свое развитие независимо от других требований. Данное руководство демонстрирует, как определить требования для каждого уровня с определением дополнительной информации или деталей, которые должны быть указаны в дополнение к рабочим элементам.
Примечание: руководство для спецификации требований в этом разделе полагает, что требование на бизнес уровне определяется рабочим элементом "Возможность" (Feature) в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента "Возможность" для достижения этой цели и признают, что это добавляет элемент формальности, который можно не использовать для небольшой и более гибкой команды.
Определение требований (Основы)
Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки.
Создание рабочих элементов для удовлетворения потребностей
Для создания рабочих элементов можно использовать Microsoft Project, Microsoft Excel, клиент Team Foundation, Web Access или ваш собственный инструмент с использованием объектной модели Team Foundation. Шаги по созданию рабочих элементов помощью клиента Team Foundation и регистрации вашего требования заключаются в следующем:
- Выберите проект в клиенте Team Foundation.
- В меню выберите Team / Add Work Item
- Выберите тип рабочего элемента - История пользователя, Качество обслуживания, Требование, и т.д. …
В зависимости от вашего процесса эта задача будет выполнена ролью Владелец продукта или группы Управления продуктом (например, Бизнес-аналитик, Менеджер по продукту, Предметный эксперта или Спонсор).
Например, для MSF CMMI рабочий элемент требования может определяться как на рисунке ниже (см. Рисунок 1).
Рисунок 1. Регистрация рабочего элемента Требование
Тип рабочего элемента Тестовый сценарий является новым свойством в Visual Studio2010. Этот тип рабочего элемента (РЭ) может быть связан с типом РЭ Требование следующим образом:
Связывание Тестового сценария с Рабочим элементом
Как только вы связали свои требования с РЭ, Вы можете добавить ссылку на сценарий тестирования. Чтобы связать Тестовый сценарий : откройте рабочий элемент требования, перейдите на вкладку тестирования, нажмите кнопку "Добавить".
Рисунок 2. Добавление ссылки на тестовый сценарий для РЭ требования
Выберите тип ссылки Тестируется (см. Рисунок 2) и перейдите к ID рабочего элемента. Можно добавить комментарий для обеспечения прозрачности. Ниже в диалоговом окне отображается рабочий элемент и его связь с Тестовым сценарием. После указания всех деталей, нажмите кнопку ОК. Результат должен быть как на рисунке ниже (см. Рисунок 3).
Рисунок 3. Добавление тестового сценария для рабочего элемента требование
Эта процедура показывает определение рабочего элемента требования и рабочего элемента тестового сценария для проверки требования. Такая же процедура применяется независимо от типа рабочего элемента или типа связи. Основы определения и отслеживания рабочих элементов работает для каждого уровня иерархии развития.
Границы Спецификации
В разделе "Анализ требований и декомпозиция" мы описали процесс по выявлению бизнес требования как тип рабочего элемента Возможность. Данное руководство описывает механизмы определения Возможностей и их связь с требованиями системного уровня, тестовыми сценариями Пользовательская приемка, а также определение дополнительной информации в документации, хранимой в SharePoint Portal.
Независимо от методологии, масштаб проекта диктуется новыми или расширяющими возможностями, их уровнем детализации и оценки. Возможность описывается как рабочий элемент, его детали в виде отдельных документов Word, диаграммы Visio, презентации PowerPoint и других файлов. Валидация возможности описывается в виде рабочего элемента тестовый сценарий, а системные требования определяются как Требования (MSF для CMMI) или Пользовательская история (MSF для Agile).
Для шаблона MSF CMMI тип рабочего элемента Возможность был добавлен как часть релиза Team Foundation Server 2010. При использовании шаблона MSF для Agile, Возможность не существует, поэтому наша рекомендация следующая: используйте бизнес требования как тип рабочего элемента Возможность в целях отслеживания трассировки от бизнес границ до системных границ.
Примечание: Опять же, добавление рабочего элемента Возможность не обязательно. Это лишь мера для крупных организаций, которая используется командой. В нашем случае гибкая команда более тесно связана с бизнесом и органами управления IT в организации. Гибкая команда может успешно выполнить проект разработки приложений без Возможность или явного обращения к бизнес требованиям.
Процедура:
- Выбрать пункт меню Team->Add Work Item->Feature
- Введите все необходимые поля. Для того чтобы требование было хорошо описано используйте контрольные списки, которые определяют процедуры выявления. (Обратитесь к разделу руководства Выявление для более детальной информации). Затем сохраните рабочий элемент.
- С целью проверки этой возможности можно создать, по крайней мере, один пользовательский приемочный тест, выбрав вкладку связи под детализацией возможности и добавив новый связанный рабочий элемент. На следующем диалоговом окне введите "Тестовый сценарий" в качестве типа ссылки и "Тестовый сценарий" как тип рабочего элемента. Затем задайте тесту соответствующие название и комментарии по поводу пользовательской приемки и сохраните.
- После окончания рабочие элементы (Возможность и Тестовый сценарий) будут иметь ссылки друг на друга.
Детальная информация тестового сценария определяется в Microsoft Test and Lab Manager
Спецификация системных требований
Системные требования представляют собой те требования, для которых команда будет выполнять разработку и реализацию. В MSF для CMMI они представлены рабочим элементом Требование (Requirement), который представляет собой функциональные и нефункциональные требования. Их разграничение определяется путем выбора конкретного атрибута типа требования рабочего элемента. В MSF для Agile, рабочий элемент Пользовательская история (User Story) представляет собой функциональные требования, а также нефункциональные требования. В предыдущем выпуске шаблонов процессов рабочий элемент "Качество обслуживания" (Quality of Service) представлял нефункциональные требования. Причиной консолидации является согласованное более тесное взаимодействие метафоры пользовательской истории многих гибких методов. Пользовательская история представляет собой "нечто, что должно быть выполнено".
Поэтому при определении системных требований для определения рабочих элементов, которые их представляют, используют следующую процедуру.
- В ходе анализа каждой возможности, определите каждое из системных требований, которые должны быть реализованы и опишите их. Выберите Возможность, для которого вы выполняете анализ. Выберите вкладку "Связи", затем выберите значок инструмента "Добавить новый связанный рабочий элемент …". Откроется диалоговое окно для создания связанного рабочего элемента. Выберите "Дочерний" как тип ссылки и Пользовательская история (при использовании MSF для Agile) или Требование (при использовании MSF для CMMI) как тип рабочего элемента. Обратите внимание на визуализацию связей представленных в нижней части диалогового окна. Тип связь реализации отличается от связи тестового сценария, показанной ранее. Для дополнительной информации о новых типах связей представленных в Team Foundation Server 2010 смотрите раздел Трассировка и Отчетность.
Заметьте также, что на этом рисунке требование к системе (в данном случае пользовательская история) показано как дочерняя ссылка. Тест, который мы создали для этой возможности, показан как тип Тестируется. Эта новая таксономия обеспечивает более эффективное анализ и представление выполнения работ.
- Следующий шаг заключается в определении системных тестовых сценариев для каждого из выявленных системных требований. Эта процедура ничем не отличается от той, что указанна выше для раздела Границы спецификации, поэтому смотрите раздел выше.
Спецификация реализации
Реализация выполняется командой набором задач, которые направлены на разработку исходного кода и юнит-тестов, тестовых сценариев и скриптов, документации или других поставок, которые направлены на достижение цели и завершения проекта. Тип связи Реализация - это типа связи, который используется для описания результатов анализа реализации; анализ направлен на определение задач и их оценки. Мы использовали связь реализации выше, когда указывали системные требования для возможности системы. Это отображается как "дочерние". На самом деле, есть две части для типа связи реализации: дочерний для рабочего элемента, что будет реализовываться, и родительский для требования, что представляет реализацию. Независимо от определений, типы связей позволяют визуализировать иерархию требования как родительский <- -> дочерний <- -> дочерний <- -> т.д. рабочий элемент в преставлении выборки рабочих элементов в виде дерева иерархии.
В ходе анализа требований к системе, укажите рабочие элементы Задача как дочерние всех системных требований с использованием процедуры, описанной выше в Спецификации системных требований. Для задач не обязательно связывать тесты, т.к. разработка исходного кода будет связана с задачами для обеспечения трассировки. И естественно, что разработка кода будет также включать модульные тесты, которые проверяют разработанный код.
Другая часть спецификации реализации - это детализация системных требований. В Team Foundation Server есть несколько способов для этого.
- Опишите детали для каждого системного требования в поле "Описание" в виде текста. Иногда этого достаточно для ясности, но зачастую наши требования могут стать настолько сложными, что для их ясности нужно будет формировать графики, длинные описания и сценарии. По этой причине, следующий пункт описывает более эффективный механизм для подробного описания.
- Опишите подробные требования к системе в виде отдельного файла. Если детализация выполнена в UML, то UML проект в Visual Studio будет полезен для этих целей. Посмотрите раздел Анализа и декомпозиции для более детальной информации для создания UML конструкций к конкретным требованиям. Visual Studio для архитектора обеспечивает механизмы для создания диаграмм сценариев использования, диаграмм деятельности и диаграмм последовательности. Возможности Sketchflow обеспечивают механизм для проектирования структурной раскадровки и веб-реализаций. Затем с помощью Word, Excel, PowerPoint можно обеспечить более подробное описание системных требований. Один из наиболее популярных видов являются Пользовательская история или Сценарий использования, которые добавляют подробное описание "потока событий". Сохраните документ в библиотеку документов для командного проекта и затем свяжите его SharePoint URL с требованием, используя тип связи "гиперссылку".
Заключительные размышления о спецификации
Спецификация требований является очень тесно связанным с выполнением выявления, анализом и проектированием, управлением изменениями. Из-за этого, некоторые области темы спецификации глубже охватывается и в других разделах руководства управления требованиями. Подумайте о спецификации как о концептуальной технике деятельности процесса и в других областях процесса. Техника, показанная здесь, одна из нескольких техник, которые могут использоваться для определения требований в проектах на основе Team Foundation Server 2010.