Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Спецификация требований

Содержание

• Спецификация требований 

• Определение требований (Основы) 

• Границы Спецификации 

• Спецификация системных требований 

• Спецификация реализации 

• Заключительные размышления о спецификации 

Спецификация требований

Описание процесса ввода требований как рабочих элементов для каждой роли и типа рабочих элементов.

Руководство в отношении спецификации требований варьирует в зависимости от вашего процесса разработки программного обеспечения. Например, при использовании традиционных процессов, таких как водопад, требует более формальный процесс спецификации требований и управления ими, чем для гибкого процесса. Поскольку существуют различные гибкие процессы, мы попытаемся подойти к спецификации требований в гибких методологиях с точки зрения 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 и регистрации вашего требования заключаются в следующем:

1. Выберите проект в клиенте Team Foundation.
2. В меню выберите Team | Add Work Item
3. Выберите тип рабочего элемента – История пользователя, Качество обслуживания, Требование, и т.д. …

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

Например, для 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 есть несколько способов для этого.

1. Опишите детали для каждого системного требования в поле «Описание» в виде текста. Иногда этого достаточно для ясности, но зачастую наши требования могут стать настолько сложными, что для их ясности нужно будет формировать графики, длинные описания и сценарии. По этой причине, следующий пункт описывает более эффективный механизм для подробного описания.
2. Опишите подробные требования к системе в виде отдельного файла. Если детализация выполнена в UML, то UML проект в Visual Studio будет полезен для этих целей. Посмотрите раздел Анализа и декомпозиции для более детальной информации для создания UML конструкций к конкретным требованиям. Visual Studio для архитектора обеспечивает механизмы для создания диаграмм сценариев использования, диаграмм деятельности и диаграмм последовательности. Возможности Sketchflow обеспечивают механизм для проектирования структурной раскадровки и веб-реализаций. Затем с помощью Word, Excel, PowerPoint можно обеспечить более подробное описание системных требований. Один из наиболее популярных видов являются Пользовательская история или Сценарий использования, которые добавляют подробное описание «потока событий». Сохраните документ в библиотеку документов для командного проекта и затем свяжите его SharePoint URL с требованием, используя тип связи «гиперссылку».

Заключительные размышления о спецификации

Спецификация требований является очень тесно связанным с выполнением выявления, анализом и проектированием, управлением изменениями. Из-за этого, некоторые области темы спецификации глубже охватывается и в других разделах руководства управления требованиями. Подумайте о спецификации как о концептуальной технике деятельности процесса и в других областях процесса. Техника, показанная здесь, одна из нескольких техник, которые могут использоваться для определения требований в проектах на основе Team Foundation Server 2010.

05.07.2010

Комментарии

• QgVxqHlxVPnCsKIGtr
  Автор: Life is short, and this artcile saved valuable time on this Earth.  ·  07.11.2011 07:56:19
  Life is short, and this artcile saved valuable time on this Earth.
• gsKSGpdgidhoI
  Автор: I think you hit a bullseye there fleals!  ·  05.11.2011 11:27:52
  I think you hit a bullseye there fleals!
• upGVwJvtQJo
  Автор: Nothnig I could say would give you undue credit for this story.  ·  20.09.2011 16:12:06
  Nothnig I could say would give you undue credit for this story.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"