Разработка сценариев использования

из "Разработка и управление требованиями "

В любой дискуссии большинство разговоров ведется вокруг определенных предположений и допущений, с которыми собеседники согласны. Совокупность этих предположений и допущений может рассматриваться как модель их взаимопонимания. Любая попытка начать обсуждение требований в отсутствие хотя бы минимального понимания будет весьма непродуктивной. [c.109]
Одним из основных организующих механизмов, помогающих обсуждению пользовательских требований (возможностей), является работа со сценариями функционирования или использования. Такой подход синтезирует структуру, которая упорядочена временем. При этом применение сценариев при разработке пользовательских требований дает возможность использовать их нотацию для установления общей системы взглядов, в рамках и контексте которой последующий диалог с пользователем становится более продуктивным. [c.109]
Сценарии стимулируют человека (представителя заинтересованной стороны) задумываться не только о том, как он в данный момент выполняет свою работу, но и о том, как бы он хотел ее делать в будущем. Это ведет к тому, что люди многократно проигрывают (репетируют) в уме разные сценарии того, как они хотели бы это делать. После того, как сценарий в какой-то степени согласован (проговорен), можно приступать к формулировке индивидуальных первичных требований с тем, чтобы уже более точно определить, что же каждый из пользователей хотел бы иметь возможность делать в каждой отдельной точке сценария. [c.109]
Сценарии являются великолепным механизмом для выявления пользовательских требований - они заставляют сосредоточиться именно на тех целях, которых хотят достичь заинтересованные стороны. Любой проработанный сценарий представляет собой совокупность последовательных результатов (или достигнутых состояний), полученных в хронологическом порядке. [c.110]
Как показано на рис. 5.3, сценарий может быть представлен последовательностью целей и демонстрировать возможности, которые обеспечивает система заинтересованной стороне, но без расшифровки того, каким образом эти цели могут быть достигнуты. Другим словами, сценарий представляет собой иерархию возможностей. [c.110]
Хронологическая последовательность получения сценария позволяет в дальнейшем неоднократно проигрывать возможные варианты функционирования системы. Заинтересованные стороны могут шаг за шагом проверять этот функционал и искать недостающие или дублирующие элементы. Такой подход позволяет избежать принятия преждевременных соглашений о конкретных решениях для достижения поставленных целей, а сосредоточиться только на определении проблем. [c.110]
Существует вполне определенный подход, которому можно следовать при разработке сценариев использования. Основной вопрос, который нужно задавать представителю заинтересованной стороны это Чего вы хотите достичь или В каком состоянии вы хотите находиться . Ответом на этот вопрос будет характеристика конечного состояния, которого необходимо достичь. [c.110]
задавая уточняющие вопросы, необходимо получить описание промежуточных целей (состояний) или шагов, следование по которым и приводит к достижению конечной цели. Совокупность этих промежуточных состояний и рассматривается затем как иерархия (дерево) целей. [c.111]
Если представитель заинтересованной стороны затрудняется описать промежуточные шаги, то необходимо попросить его описать типичную ситуацию, чтобы узнать что будет делать человек в этой ситуации, и такими образом получить требуемый результат. Если же разрабатывается совершенно новая система, то ему придется напрячь все свое воображение. Таким образом, мы можем получить полное представление того, что по ожиданиям человека будет происходить или что человек ожидает получить на каждом из промежуточных шагов. На этом пути важно выявлять такие этапы, которые могут быть необязательными или повторяющимися. При этом следует постоянно искать ответ на вопрос - будут ли отличающиеся внешние условия влиять на последовательность шагов. [c.111]
Необходимо определить последовательность шагов, а также постоянна (фиксирована) эта последовательность или она может изменяться при этом - если она может изменяться -необходимо определить те факторы или условия, под действием которых это происходит. Например, если вы задумаете нарисовать картину, вам понадобятся бумага или холст, краски, кисти и т.д., но совершенно неважно, что именно появится у вас в первую очередь. Это дает возможность выполнять некоторые действия в произвольной последовательности или делать что-то параллельно. [c.111]
Как на любом этапе получения требований очень важно воспринимать (и фиксировать) все, что говорит представитель заинтересованной стороны. В дальнейшем все это может быть пересмотрено и уточнено. Рекомендуется почаще просить более подробно объяснить, что именно в данном конкретном случае имеется в виду. [c.111]
На рис. 5.4 приведен пример сценария, описывающего проведение выходного дня на парусной лодке, которую можно транспортировать на легковом автомобиле. [c.112]
Использование временных последовательностей играет важную роль. Это помогает заинтересованным сторонам не только понять сценарий использования вообще, но и помогает формулировать пользовательские требования в правильном контексте. [c.113]
Очень важно, что описания всех узловых элементов сформулированы как возможности соответствующего уровня. Использование слова возможность. .. в имени узлового элемента помогает избежать тенденции описывать возможность как функцию (а, следовательно, избежать описывать далее ее детальную реализацию). [c.113]
Сценарии обеспечивают весьма мощную поддержку при выявлении исключений. Как известно, во многих системах функциональность по обработке исключений бывает гораздо более сложной, чем та функциональность, которая обеспечивает их обычные возможности, необходимые заинтересованным сторонам. Можно попытаться попросить заинтересованные стороны самим сформулировать такие исключения, задавая им вопросы, типа какое развитие событий может считаться ошибочным при выходе из данного состоянии или какое развитие событий может считаться ошибочным при входе в данное состояние . Естественно, что описание действий по исправлению ошибок (возвращению в нормальное состояние) может быть получено с помощью вопроса что должно произойти (быть сделано), если события начнут развиваться по неправильному сценарию . [c.113]
Как видно из рис. 5.4, сценарий отражает возможность связи со службой береговой охраны в том случае, если лодка опрокинется. В отсутствии сценария это требование могло бы быть запросто пропущено. [c.113]
Данный пример прекрасно иллюстрирует также и то, как сценарий может облегчить задачу выявления пропущенных областей требований. В данном случае из сценария следует, что были пропущены возможность транспортировать погруженную лодку (до места спуска на воду) и возможность спустить лодку на воду. [c.113]
Целью создания сценариев является облегчение общения и взаимопонимания между людьми. Сценарий сам по себе не является требованием в большей степени это просто упорядоченная структура для получения требований. Сценарии лишь помогают получить полный набор требований путем подробного рассмотрения всех функциональных аспектов использования будущей системы. [c.113]
При этом следует заметить, что никакая из методик моделирования - и данная не исключение - не может отражать все возможно существующие концепции. Не существует единственно правильного пути, и разные специалисты предпочитают использовать различные методы и модели. [c.113]

Вернуться к основной статье