анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
Таблица — Фрагмент описание варианта использования «Запросить химикат» 2) Существует еще один прием — описать процесс средствами таблицы из двух столбцов. Действия лица показаны в левом столбце, а реакция системы — в правом. Цифры указывают на последовательность этапов диалога. Эта схема отлично работает, когда с системой взаимодействует только один пользователь. Таблица — Описание этапов варианта использования в двухстолбцовом формате
Чтобы сделать эту таблицу более понятной, вы можете записать каждое действие или реакцию системы в отдельной строке, чтобы альтернативная последовательность стала очевидной. Таблица — Альтернативный макет для описания этапов варианта использования в двухстолбцовом формате
Часто варианты использования содержат дополнительную информацию или требования, которые не годятся ни для одного из разделов шаблона. Для таких данных предусмотрен раздел «Специальные требования»: сюда записывают соответствующие атрибуты качества, требования к производительности и др. Также зафиксируйте любую информацию, которая может быть неочевидна пользователям, например, необходимое для завершения варианта использования неявное взаимодействие одной системы с другой. Вам не всегда необходимо полное описание варианта использования. Alistair Cockburn (2001) описывает рабочий (casual) и полный (fully dressed) шаблоны вариантов использования. Рабочий вариант использования — это просто текстовое изложение целей пользователя и взаимодействий с системой. Рассказы пользователей, которые рассматриваются как требования в экстремальном программировании, представляют собой, по существу, рабочие версии варианта использования, как правило, написанные на учетных карточках (Jeffries, Anderson и Hendrickson, 2001). Полные описания вариантов использования необходимы, если: — в работе над проектом представители пользователей действуют не в тесной связи с разработчиками; — приложение сложное, и высок риск сбоев системы; — описания вариантов использования — это самый низкий уровень детализации требований, предназначенный для разработчиков; — вы планируете разработать подробные варианты тестирования на основании пользовательских требований; — для совместной работы территориально удаленных друг от друга команд необходимо детальные общие данные. Ловушка. Не пытайтесь догматически определять количество деталей, которые необходимо включить в вариант использования; помните, что ваша задача — достаточно хорошо разобраться, для чего система нужна пользователям, чтобы разработчики могли заняться приложением, не опасаясь необходимости будущих переделок. На рисунке «Последовательность этапов разработки вариантов использования» показано, что после каждого семинара аналитики Chemical Tracking System выявляли функциональные требования к ПО на основе описаний вариантов использования. Они также создали модели анализа для некоторых сложных вариантов использования, например диаграмму перехода состояний, показывающую все возможные состояния запроса химиката и все допустимые изменения состояний. Спустя день или два после семинара аналитик раздал описания вариантов использования и функциональных требования участникам, чтобы те просмотрели их до начала следующего семинара. Эти неофициальные просмотры выявили множество ошибок: ранее не выявленные альтернативные направления, новые исключения, некорректные функциональные требования и пропущенные этапы диалога. Оставьте между семинарами хотя бы один день. Умственное расслабление, которое наступает, когда минует день или два после мозгового штурма, позволяет людям взглянуть на проделанную работу с новой точки зрения. Один аналитик, проводивший семинары каждый день, заметил, что участникам стало трудно находить ошибки в просматриваемых документах, потому что информация была еще слишком свежа в памяти. Они прокручивали в уме дискуссии, которые только что завершились, и не замечали ошибок. Ловушка. Не ждите окончания сбора информации по требованиям, чтобы просить пользователей заняться просмотром собранного материала. На ранних стадиях разработки Chemical Tracking System руководитель тестирования создал концептуальные варианты тестирования, не зависящие от специфики реализации, на основе вариантов использования (Collard, 1999). Эти варианты тестирования помогли прийти команде к общему четкому пониманию того, как система должна функционировать при реализации определенных сценариев использования. Эти варианты тестирования позволили аналитикам проверить, действительно ли выявлены все функциональные требования, необходимые для выполнения пользователями каждого варианта использования. На заключительном семинаре, участники вместе провели критический анализ вариантов тестирования, чтобы убедиться, что одинаково понимают, как должны работать варианты использования. Как и при любом контроле качества, они нашли ошибки и в требованиях, и в вариантах тестирования. Варианты использования продукта и функциональные требования Разработчики ПО не реализуют бизнес-требования или варианты использования. Они реализуют функциональные требования, определенные фрагменты поведения системы, позволяющие клиентам выполнять варианты использования и выполнять свои задачи. Варианты использования описывают поведение системы с точки зрения действующего лица, при этом упускается множество деталей. Чтобы разработать и реализовать систему должным образом разработчику необходимо ознакомиться с множеством точек зрения. Некоторые практики считают, что варианты использования это и есть функциональные требования. Однако иногда возникают проблемы из-за того, что варианты использования просто передавались разработчикам для реализации. Варианты использования описывают точку зрения пользователя, его взгляд на внешнее, видимое поведение системы. В них не содержится всей информации, которая необходима разработчику для написания ПО. Так, человеку, использующему банковский автомат, не важно, какие неочевидные действия этот автомат должен выполнить, например взаимодействовать с компьютером банка. Эти детали невидимы для пользователя, однако разработчик должен о них знать. Естественно, в описания вариантов использования могут входить такие детали подобных неочевидных процессов, однако, как правило, в ходе дискуссий с пользователями такие вопросы не поднимаются. Даже у разработчиков, которым передали полные варианты использования, часто возникает много вопросов. Совет. Чтобы уменьшить эту неопределенность, аналитикам требований следует ясно расписывать детали функциональных требований, необходимых для реализации каждого варианта использования (Arlow, 1998). Многие функциональные требования не записаны в последовательности диалогов действующего лица и системы. Некоторые из них очевидны, например: «Система назначит уникальный порядковый номер каждому запросу». Нет смысла повторять эти детали в спецификации требований к ПО, если они совершенно ясно указаны в варианте использования. Другие функциональные требования не входят в описание варианта использования. Их выявляет аналитик на основании общего представления о варианте использования и операционной среды системы. Преобразование требований, как их видит пользователь, в форму, полезную разработчикам, — задача аналитика, один из многих способов, позволяющих ему обогатить проект. В Chemical Tracking System варианты использования в основном применялись в качестве механизма для определения необходимых функциональных требований. Аналитики составляли только рабочие описания наименее сложных вариантов использования. Затем они выявляли все функциональные требования, которые после реализации позволяли выполнять все варианты использования, в том числе альтернативные направления и обработчики исключений. И далее документировали эти функциональные требования в спецификации требований к ПО, сформированной с учетом особенностей продукта. Задокументировать функциональные требования, связанные с вариантом использованием, можно несколькими способами. Выбор способа зависит от того, как ваша команда будет выполнять дизайн, сборку и тестирование — на основе документации о вариантах использования, спецификации требований к ПО или применяя оба этих документа. Ни один из этих методов нельзя назвать идеальным, поэтому выберите тот, что лучше позволит вам документировать и управлять требования к ПО вашего проекта. Только варианты использования Вы можете включить функциональные требования непосредственно в описание каждого варианта использования. Независимо от этого вам понадобится отдельная дополнительная спецификация для фиксирования нефункциональных и всех функциональных требований, которые не связаны с конкретными вариантами использования. Несколько вариантов использования могут нуждаться в одном и том же функциональном требовании. Если для пяти вариантов использования потребуется аутентификация пользователя, вам вряд ли захочется писать пять разных блоков кода. Вместо их повторения, установите перекрестные ссылки на функциональные требования, присутствующие в нескольких вариантах использования. Варианты использования и спецификация требований к ПО Другая возможность — в довольно простой форме описать варианты использования и задокументировать функциональные требования, выявленные из каждого варианта использования в спецификации требований к ПО. В этом случае вам придется установить трассируемость между вариантами использования и связанными с ними функциональными требованиями. Лучше всего управлять трассируемостью, если вы сохраните все варианты использования и функциональные требования в средстве управления требованиями. Только спецификация требований к ПО Третий способ — упорядочить спецификацию требований к ПО по вариантам использования или функциям и включить последние в спецификацию. Именно его и применяли специалисты, работавшие над Chemical Tracking System. В этой схеме нет отдельных документов для вариантов использования. Вы определяете повторяющиеся функциональные требования или указываете каждое функциональное требование только один раз и ссылаетесь на него при каждом появлении его в другом варианте использования. Преимущества способа с применением вариантов использования Преимущества применения вариантов использования в том, что каждый вариант сосредоточен на поставленной задаче и пользователе. Пользователи будут более четко представлять, что же им даст новая система, если вы выберете способ, который фокусируется на функциях системы. При разработке нескольких Интернет-проектов представители клиентов заявили, что варианты использования позволили им более четко представить, какие возможности должны получить посетители их Web-сайтов. А аналитики и разработчики смогли разобраться и в бизнесе-процессах пользователей, и в предметной области. Тщательное изучение этапов взаимодействия лица и системы помогает еще на ранних стадиях разработки выявить неясности и неточности, а также позволяет составить варианты тестирования на основе вариантов использования. Очень расточительно и болезненно для разработчиков писать код, которым никогда не удастся воспользоваться. Если вы будете заблаговременно определять требования и включать в них все мыслимые функции, то рискуете создать избыточные требования. Способ с применением вариантов использования позволяет выявить функциональные требования, с помощью которых пользователи будут выполнять конкретные задачи. Так вы предотвратите появление «функций-сирот», тех, что в ходе сбора информации казались весьма полезными, однако которыми никто че будет пользоваться из-за того, что они не связаны напрямую с решением рабочих задач. Способ с применением вариантов использования облегчает расстановку приоритетов требований. Высшим приоритетом обладают те функциональные требования, которые созданы на основе вариантов использования с высшим приоритетом. Высший приоритет назначается по следующим причинам: — варианты использования описывают один из основных бизнес-процессов, активизируемых системой; — многие пользователи часто обращаются к ним; — их запросил привилегированный класс пользователей; — они предоставляют возможности, необходимые для соответствия требованиям; — функции других систем зависят от их наличия. Ловушка. Не тратьте много времени на обсуждение деталей вариантов использования, которые не будут реализованы в ближайшие месяцы или годы. Вероятнее всего, они изменятся еще до начала сборки. Существуют также и преимущества технического характера. С помощью варианта использования можно выявить некоторые важные объекты предметной области и их взаимоотношения. Разработчики, использующие объектно-ориентированные методы дизайна, могут преобразовать варианты использования в объектные модели, такие, как диаграммы классов и диаграммы последовательностей. (Однако следует помнить, что варианты использования ни в коем случае не ограничиваются разработкой объектно-ориентированных проектов). По мере того как с течением времени изменяются бизнес-процессы, задачи, реализуемые посредством определенных вариантов использования, также изменяются. Если вы проследите функциональные требования, дизайн, код и тесты вплоть до их истоков — пожеланий клиента — вам будет легче внести эти изменения бизнес-процессов во всю систему. Каких ловушек следует опасаться при способе с применением вариантов использования Как и любой другой способ разработки ПО, применение вариантов использования чревато возникновением множества проблем: — Слишком много вариантов использования. Если вас захлестнул вал вариантов использования, вам, возможно, не удастся записать каждый из них на соответствующем уровне абстракции. Не создавайте отдельный вариант использования для каждого возможного сценария. Лучше включите нормальное направление развития, альтернативные направления и исключения в виде сценариев в один вариант использования. Как правило, количество вариантов использования превышает количество бизнес-требований и функций, однако функциональных требований обычно бывает намного больше, чем вариантов использования. — Очень сложные варианты использования. Однажды я изучал вариант использования объемом в четыре страницы, плотно заполненных описанием этапов взаимодействия, встроенной логики и условий ответвления. Документ казался весьма невразумительным. Вам не дано контролировать сложность бизнес-задач, но вы можете выбрать способ их представления в вариантах использования. Выберите один успешный способ выполнения варианта использования, с одной комбинацией значений правильных и ложных значении для различных логических решений и назовите его нормальным на правлением. Другие успешные логические ответвления определите как альтернативные направления и назначьте исключения для обработки неудачных ответвлений. Альтернативных направлений может быть множество, однако каждое должно быть кратким и понятным. Чтобы не усложнять эту схему, записывайте варианты использования в терминах, основных для взаимодействий пользователя и системы, без особой детализации. — Включение пользовательского интерфейса в варианты использования. Варианты использования должны описывать то, что пользователям необходимо выполнить с помощью системы, а не на то, как это будет выглядеть на экране. Сосредоточьтесь на концептуальном взаимодействии пользователя и системы, отложите работу над пользовательским интерфейсом до стадии дизайна. Например, правильная формулировка на этой стадии — «система предоставляет выбор», а не «система отображает раскрывающийся список». Не допускайте, чтобы дизайн пользовательского интерфейса диктовал направление разработки требований. Применяйте наброски экрана и карты диалогов (диаграммы архитектуры интерфейса), чтобы в визуальной форме представить взаимодействия исполнителя и системы, а не утвердить дизайн. — Включения определения данных в варианты использования. Мне приходилось видеть варианты использования, которые включали в себя определения элементов данных и структур, которыми манипулируют в варианте использования. Участникам проекта было трудно отыскать в них необходимые определения, поскольку неясно, в каком именно варианте использования оно содержится. В таких случаях возможен повтор определений, а значит, и их рассинхронизация, когда один экземпляр изменяется, а остальные нет. Вместо того чтобы «разбрызгивать» определения по вариантам использования, соберите их данных в словарь данных, созданный для всего проекта. |