Выявление требований

http://ashamray.wordpress.com/2010/07/02/vsts2010_rm_elicitation/

В 1992 году было опубликовано следующее высказывание, на 17 лет раньше, чем Visual Studio ALM Ranger начали разрабатывать руководство по инжинирингу требований:

1“Многие из проблем в создании и поддержке системы можно связать с проблемами выявления. Тем не менее, большая часть исследований, проводимых по инженерии требований, игнорируют выявление, руководитель Лейте (автор) заявил, ссылаясь на обследование анализа требований в 1987, что состояние дел в области анализа требований не сильно отличается от того, что было в конце 1970-х. Он утверждает, что исследования в этой области сконцентрированы на точность, представление, методы моделирования, верификации и утверждения, а не на улучшение выявления потребностей. Он приходит к выводу, что ‘усилия исследований должны быть направлены на методы и инструменты, необходимые для улучшения процесса анализа требований, и, в частности, на те, которые оказывают большую поддержку выявлению требований’”.

Тем не менее, и в 2009-ом году практики по-прежнему пренебрегают выявлением требований. В этом разделе описываются планирование, методы выявления, а также поддержка для хранения результатов, обеспечивающиеся в Visual Studio и Team Foundation Server для выявления требований по проектам разработки приложений.

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

Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.

Примечание:руководство по выявлению требований этого раздела предполагает, что требование на уровне бизнеса реализовывается с использованием рабочего элемента “Возможность” (Feature) в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента Возможность в этих целях и признают, что это добавляет элемент формальности, который можно легко избежать для небольших и более гибких команд.

Общие темы выявления Планирование выявления

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

Планирование выявления обеспечивается 3-мя основными уровнями: ранний сбор информации, представление требований и анализ, валидация.

Сбор информации включает в себя определение всех соответствующих сторон и сбора инициирующих требований (“списков пожеланий”) от них. Через приоритеты, основанные на политических, экономических, окружающей среды и т.д. факторах, эти требования передаются на следующую итерацию выявления требований.

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

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

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

• Выявление всех соответствующих сторон, которые являются источниками требований. Эта и следующая работа направлены на определение “Персонажей” приложения. Один из ключевых элементов Microsoft Solution Framework (MSF). Участник может быть конечным пользователем, интерфейсом системы или фактором среды. Несмотря на то, какие роли определены в любой нетипичной организации, ниже приведен типовой список возможных ролей:

  • Бизнес – человек или люди, обеспечивающие финансирование проекта

  • Пользователь – человек или люди, которые в конечном итоге будут использовать систему

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

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

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

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

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

Чтобы планировать эти три этапа, можно использовать электронную таблицу или план работ MS Project и синхронизировать с рабочим элементом TFS Задача. Следующие шаги демонстрируют, как сделать это с помощью MS Project:

• Откройте MS Project и установите правильные атрибуты соответствия, выбрав TFS Team Project из пункта меню “Team”:

• Далее выберите сервер TFS и коллекцию проектов по умолчанию, для которых будут планироваться задачи по выявлению:

• Далее введите задачи выявления с оценками, основанными на анализе каждого человека, который представляет собой персонаж для вашего приложения:

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

• Вот как это выглядит в TFS после публикации: