Поделиться через

Разработка требований

  • Статья

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

Создавая требования в Team Foundation Server, можно получить следующие преимущества:

  • проверка выполнения требований путем связывания их с тестовыми случаями;

  • отслеживание хода реализации требований путем связывания их с рабочими элементами задач;

  • упорядочивание требований путем разделения их на общие и более подробные требования для упрощения управления и создания сводных отчетов о ходе выполнения;

  • моделирование требований в Visual Studio Ultimate, связывание элементов модели с требованиями в Team Foundation Server.

В этом разделе мы не пытаемся воспроизвести очень большой объем информации, доступной в различных источниках, посвященных определению требований. Целью этого раздела является рассмотрение важных аспектов в отношении использования средств Visual Studio в соответствии с положениями CMMI. Дополнительные сведения о CMMI см. в разделе Сведения о CMMI.

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

Когда приступать к разработке требований

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

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

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

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

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

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

Управление изменениями требований

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

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

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

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

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

  • Обновляйте тесты в соответствии с внесенными в требования изменениями.

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

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

Составление концепции

Концепцию следует обсудить с рабочей группой и представить ее на веб-портале проекта Team Foundation Server.

Концепция — это краткое изложение преимуществ, которые принесет продукт. Какие новые возможности станут доступны для пользователей? Концепция помогает прояснить сферу применения продукта.

Если продукт уже существует, составляется концепция для данной версии. Какие новые возможности продукта станут доступны для пользователей?

Написание сценариев

В сотрудничестве с клиентами и другими заинтересованными лицам разработайте сценарии и введите их в качестве рабочих элементов требований (в поле "Тип требования" выберите "Сценарий").

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

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

Клиент покупает обед.

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

  • Одно или два предложения в описании рабочего элемента:

    Клиент заказывает обед на веб-сайте и оплачивает заказ кредитной картой. Заказ передается в ресторан, который готовит и доставляет обед.

  • Пронумерованные шаги в описании рабочего элемента:

    1. Клиент посещает веб-сайт и оформляет заказ на обед.

    2. Веб-сайт перенаправляет клиента на сайт обработки платежей для оплаты заказа.

    3. Заказ добавляется в список заказов ресторана.

    4. Ресторан готовит и доставляет обед.

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

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

  • Документы требований. Документы требований позволяют предоставить должный уровень детализации для каждого требования. Если вы решили использовать документы, создайте документ Word для каждого требования и прикрепите его к рабочему элементу требования или загрузите файл на портал командного проекта и добавьте гиперссылку на рабочий элемент.

  • UML-схема последовательностей. Схема последовательностей особенно удобна при взаимодействии нескольких участников. Например, в заказе обеда участвуют клиент, веб-сайт DinnerNow, система платежей и ресторан, взаимодействующие в определенной последовательности. Создайте схему последовательностей в модели UML, верните ее в Team Foundation Server, а затем включите ссылку в рабочий элемент требования. Подробнее см. в разделе UML-схемы последовательностей: правила работы.

Конкретные сценарии

Начнем с создания конкретных сценариев, в которых определенный набор субъектов будет выполнять определенную последовательность действий. Например: "Алексей заказывает пиццу и чесночный хлеб на сайте компании DinnerNow. Веб-сайт перенаправляет Алексея в службу платежей банка Woodgrove. Ресторан Fourth Coffee готовит пиццу и доставляет ее".

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

Кроме того, в сценариях, описывающих предысторию и другие действия людей и организаций, удобно использовать для их обозначения реальные имена. Алексей спит под открытым небом и пользуется интернет-кафе; Анна живет в охраняемом коттеджном поселке; Дмитрий заказывает обеды жене в офис; Contoso владеет сетью из 2000 ресторанов по всему миру; Fourth Coffee принадлежит семейной паре, и доставка осуществляется на велосипедах.

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

Уровень детализации

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

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

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

Организация сценариев

Организовать сценарии можно следующим образом.

  • Нарисуйте схемы вариантов использования, которые демонстрируют каждый сценарий как вариант использования. Этот метод рекомендуется, поскольку он упрощает представление и обсуждение сценариев. Подробнее см. в разделе UML-схемы вариантов использования: правила работы.

    • Свяжите варианты использования с рабочими элементами, которые определяют сценарии. Дополнительные сведения см. в разделе Связывание элементов модели и рабочих элементов.

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

    • Нарисуйте отношения включения для отделения таких процедур, как "Клиент входит в систему", которые являются общими для нескольких вариантов использования.

    • Нарисуйте отношения обобщения между общими сценариями, например "Клиент оплачивает покупку", и конкретными вариантами, например "Клиент оплачивает покупку картой".

  • Создайте связи типа "родитель-потомок" между рабочими элементами сценария. Иерархию можно просмотреть в Team Explorer. Дополнительные сведения см. в разделе Структурирование требований в виде плана продукта.

Моделирование бизнес-среды

Создайте модель UML, которая описывает основные действия и понятия, связанные с использованием продукта. Используйте термины, которые определены в этой модели, как "единый язык" в сценариях, в обсуждениях с заинтересованными лицами, в пользовательском интерфейсе и руководствах для пользователей и в самом коде.

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

Сохраните модель в системе управления версиями.

Дополнительные сведения см. в разделе Моделирование требований пользователей.

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

Нарисуйте схемы деятельности для обобщения сценариев. Используйте дорожки для группирования действий, выполняемых разными субъектами. Дополнительные сведения см. в разделе UML-схемы деятельности: рекомендации.

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

На рисунке ниже представлен простой пример схемы деятельности.

Активность с тремя действиями и циклом.

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

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

На рисунке ниже представлен простой пример схемы вариантов использования.

Варианты использования для предыдущих действий

Моделирование концепций

Нарисуйте схему класса предметной области для описания важных сущностей и их отношений, которые упоминаются в сценариях. Например, модель DinnerNow будет содержать элементы "Ресторан", "Меню", "Заказ", "Пункт меню" и т. д. Подробнее см. в разделе UML-схемы классов: правила работы.

Создайте метки ролей (концов) отношений, используя имена и количество элементов.

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

На рисунке ниже представлен простой пример схемы классов.

Правило в комментарии, вложенном в класс Order.

Статические ограничения

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

Согласованность модели

Убедитесь в согласованности модели и сценариев. Одним из важнейших применений модели является устранение неоднозначности.

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

  • Каждый сценарий описывает последовательность шагов, которые допускает схема деятельности.

  • Сценарии и действия описывают, как создается и уничтожается каждый класс и каждое отношение в схеме классов. Например, в каких сценариях создается пункт меню? Когда уничтожается заказ?

Разработка требований к качеству обслуживания

Создайте рабочие элементы, определяющие требования к качеству обслуживания. Задайте для поля "Тип требования" значение "Качество обслуживания".

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

Рассмотрим каждую из этих категорий для каждого сценария.

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

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

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

Проверка требований

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

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

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

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

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

  • Определены все важные этапы взаимодействия пользователя с продуктом.

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

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

  • Сценарий имеет единственную интерпретацию, легкую для восприятия.

  • Сценарий не конфликтует с другим сценарием.

  • Сценарий можно протестировать.

Проверка

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

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

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

Проверка требований и внесение изменений

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

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

Дополнительные ресурсы

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