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

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

Благодаря тому, что требования изложены в соответствующем рабочем элементе Visual Studio Team Foundation Server, становится возможным:

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

• следить за ходом реализации требований, связывая их ссылками с рабочими элементами для задач;

• формулировать более общие и более детальные требования, тем самым упрощая работу с ними и обобщение информации для отчетов о ходе работ;

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

Этот раздел не следует считать удобной заменой массе литературы о выработке требований.В основном он посвящен освещению важных моментов при использовании инструментов Visual Studio в соответствии с положениями CMMI. Дополнительные сведения о CMMI см. в разделе Сведения о CMMI.

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

В этом разделе

Когда разрабатывать требования

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

Составление сценариев

Моделирование предметной области

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

Вычитка требований

Проверка

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

Когда разрабатывать требования

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

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

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

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

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

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

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

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

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

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

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

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

• С учетом каждого из внесенных изменений необходимо обновить и тесты.

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

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

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

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

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

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

Составление сценариев

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

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

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

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

Ниже приведено несколько вариантов записи сценария.Иногда удобнее использовать более одного варианта.

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

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

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

  Клиент открывает сайт и создает заказ на доставку еды. Сайт перенаправляет клиента на сайт обработки платежей. Заказ заносится в список заказов ресторана. Ресторан готовит и доставляет еду.

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

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

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

• Схемы последовательностей в формате Unified Markup Language (UML).Схемы последовательностей особенно удобно использовать для описания взаимодействия нескольких участников.Примером может служить случай, когда в процессе заказа еды в определенной последовательности взаимодействуют друг с другом клиент, сайт "Обед-Момент", система обработки платежей и ресторан.Схему последовательности строят в виде модели UML, отправляют ее на Team Foundation Server, а ссылку на модель помещают в рабочий элемент требования.Дополнительные сведения см. в разделе UML-схемы последовательностей: правила работы.

Детализированные сценарии

В детализированных сценариях описывают конкретную последовательность действий, которую выполняет группа определенных субъектов.Например, "Вадим заказывает пиццу и чесночный хлеб на сайте "Обед-Момент".Сайт перенаправляет Вадима в систему обработки платежей банка "АБВ"."Черный кофе" готовит пиццу и доставляет ее".

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

Они также могут быть полезны при создании именованных пользователей, которые служат для более подробного представления обстановки или действий людей и организаций.Вадим ночует где придется и пользуется интернет-кафе; Наталья живет в элитном доме; Дмитрий заказывает обеды жене в офис; Руслан владеет цепью из 2 000 ресторанов по всему миру; "Черный кофе" принадлежит супружеской паре, которая развозит еду на велосипедах.

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

Степень детализации

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

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

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

Упорядочение сценариев

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

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

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

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

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

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

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

Моделирование предметной области

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

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

Модель следует сохранить в среде, где предусмотрена возможность управления версиями.

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

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

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

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

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

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

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

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

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

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

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

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

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

Неизменные ограничения

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

Единообразие в рамках модели

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

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

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

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

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

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

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

Все эти критерии следует принимать во внимание при составлении любого сценария.

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

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

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

Вычитка требований

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

Для отслеживания процесса вычитки требований следует создать рабочий элемент вычитки.Такой рабочий элемент служит важным документальным свидетельством при сертификации Standard CMMI Appraisal Method for Process Improvement (SCAMPI), а в будущем может также послужить полезным источником сведений при выявлении основной причины ошибки.

При вычитке сценария внимание уделяют следующим моментам.

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

• В сценарии должна быть очерчена проблема и ясно намечены предполагаемые пути ее решения.

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

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

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

• Сценарий должен быть прост для понимания и однозначен.

• Ни один из сценариев не должен противоречить другому сценарию.

• Ни один из сценариев не должен исключать возможности его тестирования.

Проверка

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

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

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

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

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

Результаты запроса можно просматривать не только непосредственно в Team Explorer или Team Web Access, но также открыть в Office Excel или Office Project.Эти инструменты наиболее удобны при пакетном изменении и создании рабочих элементов.Дополнительные сведения см. в разделах Работа в приложениях Microsoft Excel и Microsoft Project, подключенных к серверу Team Foundation Server и Выполнение планирования сверху вниз при помощи списка дерева рабочих элементов (в программе Excel).

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

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

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

• A Practical Guide to Feature Driven Development, Stephen R.Palmer and Malcolm J.Felsing; Prentice-Hall PTR, 2002.

• Streamlined Object Modeling: Patterns, Rules and Implementation, Jill Nicola, Mark Mayfield, and Mike Abney; Prentice Hall PTR, 2001.

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler; Wiley, 2002.

• Domain Driven Design: Tackling Complexity in the Heart of Software, Eric Evans; Addison Wesley Professional, 2003.

• Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean; Addison Wesley Professional, 2002.