Столкнувшись с необходимостью сбора требований, возможно, вам захочется спросить потенциального пользователя:.
Что вы хотите, чтобы эта система делала ?.
Часть потенциальных пользователей этот вопрос поставит в тупик, а у другой части пользователей найдется мало что ответить.
Если ваши потенциальные пользователи уже используют какие-либо системы, то у них обычно существуют идеи на тему как их улучшить. В случае если никаких систем у потенциальных пользователей сейчас нет, то и почвы для подобных идей у них тоже нет.
В любом случае, в качестве ответа на свой вопрос вы получите описание того или иного решения, потому что ваш вопрос уже предусматривал в качестве ответа описание функциональности рассматриваемой системы.
Для того чтобы в самом начале избежать подобных прыжков в область решений, необходимо задать другой вопрос:.
Зачем вам нужна эта система? или.
Какие задачи должна решать необходимая вам система?.
Как только речь заходит о задачах, которые должна будет решать рассматриваемая система, люди сразу же начинают думать о том, что они будут делать с помощью системы, вместо того чтобы думать о том, как они это будут делать.
Однако все то, что люди хотят получить с помощью системы, может быть сформулировано даже без описания возможных решений. И это весьма важный момент, потому как, избегая уклона в сторону решения, мы оставляем пространство для работы архитекторов и системных инженеров.
Вот почему некоторые специалисты даже настаивают на том, что слово «система» должно быть полностью исключено из предыдущего вопроса, а сам вопрос должен звучать следующим образом:.
Что вы хотите, чтобы вы могли делать?.
Ответ на этот вопрос должен начинаться фразой:.
Я хотел бы иметь возможность ...
Именно такой ответ является требованием типа «возможность» (описывающим возможность). И именно этот тип требований является ключевым в области проблем.
Таким образом, установив, что при разработке требований в области проблем первичной задачей является выявление возможностей, мы формулируем для самих себя следующий вопрос:.
А кого, собственно, нужно опрашивать?.
Поиск ответа на этот вопрос приводит нас к необходимости идентифицировать некую группу людей, которую мы будем называть «заинтересованные стороны» (stakeholders). Под термином «заинтересованные стороны» могут пониматься либо непосредственно люди, либо организации, прямо или косвенно заинтересованные в существовании системы.
Наконец, мы должны задуматься над тем, какие типы моделей могут быть пригодны для моделирования проблемной области. Необходимо отметить, что любые модели, которые используются для описания проблемной области, должны быть, в первую очередь, понятны именно заинтересованным сторонам, поскольку они будут отвечать за их анализ, оценку и утверждение (принятие). А поскольку специалисты заинтересованных сторон отбираются по принципу их набольшей компетентности и опыта в проблемной области, то, зачастую, они не желают или не могут работать с моделями, которые кажутся им хоть немного «техническими».
К примеру, если вы собираетесь посетить автосалон для того, чтобы ознакомиться с новыми автомобилями, их внешним видом, убранством салона и т.д., то вас вряд ли заинтересуют графики, поясняющие очередность впрыска топлива в цилиндры двигателя, или рассуждения на тему принципов построения системы управления двигателем. Вероятнее всего вас будут интересовать мощность двигателя, время разгона до скорости 100 км/ч, расход горючего на 100 км, комфортабельность и комплектация автомобиля. Другими словами, вы захотите представить себе - какой машина будет в управлении, как бы хорошо вы смотрелись в ней, отправляясь в поездку с подругой или другом. Представляя себе эту поездку, вы начнете думать обо всех тех особенностях и преимуществах автомобиля, которые были бы полезны вам в поездке. Вот это и есть простой пример сценария использования.
Давно было подмечено, что сценарии использования - это очень хороший способ моделирования того, что люди делают, или того, что они хотели бы иметь возможность делать. Сценарии во многом соответствует тому, как люди думают о своей работе и о своих проблемах. Сценарий может быть разработан совместно с заинтересованной стороной и в дальнейшем использоваться как основа для обсуждения требуемых возможностей.
Заключительным аспектом разработки требований в проблемной области является выявление имеющихся ограничений. Например, при покупке автомобиля, вы будете иметь лишь определенную сумму денег на покупку, или захотите, чтобы автомобиль был в вашем распоряжении уже к конкретной дате.
После того, как выше мы определили все ключевые моменты, у нас появляется возможность проиллюстрировать основной (общий) процесс разработки требований из области проблем.
5.2 Определение основного процесса.
На рис. 5.1 представлен основной (общий) процесс разработки пользовательских требований (stakeholder requirements).
Рис. 5.1 Процесс разработки пользовательских требований.
Начальной точкой, инициирующей процесс, является описание потребностей.
Это может быть даже что-то совсем небольшое по содержанию, например, короткая служебная записка руководителя компании техническому директору, в которой говориться о том, что компании необходим новый продукт для того, чтобы быть на шаг впереди конкурентов. Или же, наоборот, - представьте, что компания уже проводила исследования для определения возможных альтернативных решений существующих проблем и полученные результаты сформулированы в виде документа, из которого уже даже можно получить часть сценариев использования.
На рис. 5.1 показано, что процесс анализа и моделирования создает набор сценариев использования и формирует список заинтересованных сторон. Пользовательские требования при этом будут производными от требований заинтересованных сторон.
Анализ и моделирование, получение пользовательских требований, стратегии проверки для них будут рассмотрены более подробно в последующих разделах.
5.3 Согласование требований с заказчиком.
Зачастую процесс согласования пользовательских требований в начале проекта носит неформальный характер. Обычно документ, содержащий потребности, пишется в простой свободной форме и совершенно не похож на требования.
Другими словами, этот документ обычно содержит достаточно размытое описание потребностей вперемешку с некоторым пояснительным текстом. Он не содержит четко выписанных детальных требований, к которым могли бы впоследствии приходить входящие связи типа «удовлетворяет».
Поэтому процесс получения пользовательских требований отличается от процесса конструирования требований на следующих уровнях, так как первый начинается с весьма нечетких и бесформенных формулировок (вплоть до «сделайте мне красиво»).
Одним из ключевых аспектов формирования пользовательских требований является определение границ будущей системы (границ ответственности). Обычно эти границы фиксируются с самого начала при определении наборов сценариев использования.
5.4 Анализ и моделирование.
На рис. 5.2 показано, что процесс анализа и моделирования для разработки требований является «инициативным» для области проблем.
В начале определяются все заинтересованные лица, а затем вместе с ними создаются сценарии использования.
5.4.1 Определение заинтересованных сторон.
Ранее мы становили, что заинтересованными сторонами могут быть люди или организации, которые имеют определенное отношение к разрабатываемой системе, например, либо влияют на нее и взаимодействуют с ней, либо система влияет и воздействует на них.
При этом типы заинтересованных сторон могут различаться в зависимости от характера и предназначения системы, сравните, например, две системы - одну, используемую как товар широкого потребления, и другую - для управления воздушным транспортом или железной дороги.
Люди, имеющие свое мнение относительно создаваемой системы, включают и тех, кто будет самым непосредственным образом использовать систему (работать с ней).
Заметим при этом, что этими людьми могут быть не только непосредственные пользователи системы, например, пассажиры самолета или поезда, но и люди, которые не являются пассажирами, но могут, например, пострадать в случае аварии самолета или поезда. А группа лиц, которая несет ответственность за систему, может включать и руководящий (управляющий) персонал, и персонал, отвечающий за безопасность.
Рис. 5.2 Процесс анализа и моделирования для разработки пользовательских требований.
В качестве примера, ниже приводится список возможных категорий заинтересованных сторон, который может использоваться как основа при разработке вашего собственного списка с целью проверки его полноты. Этот список категорий не претендует на абсолютную полноту, однако может помочь при мозговом штурме для определения всех заинтересованных сторон.
• Руководство: люди, отвечающие либо за бюджет разработки, либо за бюджет организации (департамента), в которой система будет функционировать. Хорошей идеей является также привлечение людей, ответственных за стратегию развития компании, для того чтобы получить и их мнение о том, насколько разрабатываемая система соответствует задачам, стоящим пред компанией.
• Инвесторы: люди, приглашенные к финансированию или уже вложившие деньги в разработку системы или организацию, разрабатывающую систему, или же в организацию, в которой система должна внедряться.
• Пользователи системы: естественно, что эта группа людей является очень важной. Они непосредственно заинтересованы в тех возможностях или сервисах, которые должна предоставлять новая система. Необходимо также отметить, что при этом весьма возможно существование таких пользователей, которые не будут взаимодействовать с системой напрямую. Например, пользователями телескопа Хаббла являются астрономы. Они направляют запросы на фотоснимки определенных районов и получают их, как только снимки готовы, но они сами непосредственно не управляют телескопом. Пользователи существующих систем являются очень полезным источником знаний о проблемах, присутствующих в этих системах. Они могут дать бесценные советы относительно того, каким образом может быть улучшена разрабатываемая система.
• Обслуживающий персонал: не смотря на то, что их прямой обязанностью является поддержка системы уже после ее запуска, обслуживающий персонал имеет важные требования к системе, которые необходимо учитывать для того, чтобы облегчить обсуживающему персоналу поддержку и обслуживание будущей системы.
• Утилизаторы: эта сторона играет важную роль в соблюдении требований законодательства по защите окружающей среды. Требования этой стороны могут существенным образом повлиять на проект системы, особенно на выбор предполагаемых к использованию материалов.
• Обучающий персонал: так же как и обслуживающий персонал, эти люди заинтересованы в том, чтобы система была простой в использовании, а, соответственно, и легкой для обучения. Эти люди могут требовать, чтобы система обеспечивала такой режим функционирования, при котором одновременная работа с реальными данными и данными, предназначенными для обучения, не нарушала бы работоспособность и безопасность всей системы.
• Покупатели: для больших систем, особенно широко используемых в промышленности и транспорте, весьма характерно, что люди, которые платят за систему (покупателизаказчики), не участвуют в ее разработке и последующей эксплуатации. Однако они играют большую роль в определении объема требований к системе с точки зрения отношения затрат к получаемым преимуществам. Хотя при разработке оборудования, покупатель может также являться и непосредственными его пользователем, например, сотового телефона или автомобиля.
• Маркетинг и продавцы: эти люди играют ключевую роль в определении возможностей системы; особенно при разработке продуктов (оборудования) массового потребления, когда узнать мнение всех потенциальных пользователей просто невозможно.
• Эксперты по эргономике и эффективности: эти люди знают, как оптимизировать систему, для того чтобы сделать ее использование более эффективным. Ими учитываются факторы эргономики, легкости изучения и освоения, возможности надежного использования в экстренных ситуациях или условиях интенсивной эксплуатации (например, для систем управления воздушным транспортом).
• Эксперты по области применения: обычно новая система разрабатывается для работы не в «чистом поле» и уже существуют системы, с которыми она должна взаимодействовать. При этом возможно также существование косвенно влияющих аспектов внешнего окружения, таких как контроль за загрязнением окружающей среды (ваша система не должна загрязнять окружающую среду), или когда необходимо обеспечить устойчивость системы к действиям окружающей среды (например, сложные погодные условие, или погружение на глубину).
• Правительство: законы, правила, инструкции и многие другие официальные документы органов власти регулируют и определяют то, что система может делать, а что ей категорически запрещено.
• Стандартизирующие органы: на разрабатываемую систему могут влиять существующие или разрабатываемые стандарты, которые могут быть международными (например, стандарт сотовой связи GSM), национальными или внутри корпоративными.
• Общественное мнение: в разных странах мира существуют различные мнения по одному и тому же вопросу. Поэтому при разработке продуктов, предназначенных для поставки на экспорт, необходимо принимать во внимание географический и национальный факторы.
• Регулирующие органы: для того, чтобы получить необходимый сертификат соответствия, эти организации могут настаивать на том, чтобы создаваемая система (продукт) имела определенную прозрачность (открытость). В качестве примера можно привести Министерство железнодорожного транспорта Великобритании (Rail Regulator) и Управление по контролю за продуктами и лекарствами (FDA) в Соединенных Штатах.
Получив как можно более полный список категорий потенциальных заинтересованных сторон, следует принять решение о том, какие именно из этих категорий должны участвовать в постановке требований и как их вовлечь в этот процесс.
В некоторых случаях возможен прямой контакт с представителями одной из заинтересованных сторон (категорий), например, с потенциальными пользователями системы. Тогда стоит определить конкретных представителей, с которыми вы будете общаться.
В других случаях прямой контакт в принципе невозможен, например, если заинтересованная сторона - общество. Тогда представляется вполне возможным назначить на эту роль кого-то из вашей команды и прислушаться к его мнению.
В конце концов, на выходе этого процесса мы получаем список представителей заинтересованных сторон (см. рис. 5.2).
5.4.2 Разработка сценариев использования.
В любой дискуссии большинство разговоров ведется вокруг определенных предположений и допущений, с которыми собеседники согласны. Совокупность этих предположений и допущений может рассматриваться как модель их взаимопонимания. Любая попытка начать обсуждение требований в отсутствие хотя бы минимального понимания будет весьма непродуктивной.
Одним из основных организующих механизмов, помогающих обсуждению пользовательских требований (возможностей), является работа со сценариями функционирования или использования. Такой подход синтезирует структуру, которая упорядочена временем. При этом применение сценариев при разработке пользовательских требований дает возможность использовать их нотацию для установления общей системы взглядов, в рамках и контексте которой последующий диалог с пользователем становится более продуктивным.
Сценарии стимулируют человека (представителя заинтересованной стороны) задумываться не только о том, как он в данный момент выполняет свою работу, но и о том, как бы он хотел ее делать в будущем. Это ведет к тому, что люди многократно «проигрывают» (репетируют) в уме разные сценарии того, как они хотели бы это делать. После того, как сценарий в какой-то степени согласован (проговорен), можно приступать к формулировке индивидуальных первичных требований с тем, чтобы уже более точно определить, что же каждый из пользователей хотел бы иметь возможность делать в каждой отдельной точке сценария.
Сценарии являются великолепным механизмом для выявления пользовательских требований - они заставляют сосредоточиться именно на тех целях, которых хотят достичь заинтересованные стороны. Любой проработанный сценарий представляет собой совокупность последовательных результатов (или достигнутых состояний), полученных в хронологическом порядке.
Как показано на рис. 5.3, сценарий может быть представлен последовательностью целей и демонстрировать возможности, которые обеспечивает система заинтересованной стороне, но без расшифровки того, каким образом эти цели могут быть достигнуты. Другим словами, сценарий представляет собой иерархию возможностей.
Рис. 5.3 Сценарий использования как иерархия целей.
Хронологическая последовательность получения сценария позволяет в дальнейшем неоднократно проигрывать возможные варианты функционирования системы. Заинтересованные стороны могут шаг за шагом проверять этот функционал и искать недостающие или дублирующие элементы. Такой подход позволяет избежать принятия преждевременных соглашений о конкретных решениях для достижения поставленных целей, а сосредоточиться только на определении проблем.
Существует вполне определенный подход, которому можно следовать при разработке сценариев использования. Основной вопрос, который нужно задавать представителю заинтересованной стороны это: «Чего вы хотите достичь?» или «В каком состоянии вы хотите находиться?». Ответом на этот вопрос будет характеристика конечного состояния, которого необходимо достичь.
Далее, задавая уточняющие вопросы, необходимо получить описание промежуточных целей (состояний) или шагов, следование по которым и приводит к достижению конечной цели. Совокупность этих промежуточных состояний и рассматривается затем как иерархия (дерево) целей.
Таким образом, вырисовывается следующий порядок действий для получения сценария использования:.
• Начать с получения характеристики конечной цели (состояния).
• Установить необходимые возможности (пользовательские требования) для достижения конечной цели.
• Разбить крупные шаги на более мелкие (промежуточные).
• Строго соблюдать иерархическую структуру.
• Перепроверять информацию на каждом этапе.
• Избегать описания конкретных решений.
Если представитель заинтересованной стороны затрудняется описать промежуточные шаги, то необходимо попросить его описать типичную ситуацию, чтобы узнать что будет делать человек в этой ситуации, и такими образом получить требуемый результат. Если же разрабатывается совершенно новая система, то ему придется напрячь все свое воображение. Таким образом, мы можем получить полное представление того, что по ожиданиям человека будет происходить или что человек ожидает получить на каждом из промежуточных шагов. На этом пути важно выявлять такие этапы, которые могут быть необязательными или повторяющимися. При этом следует постоянно искать ответ на вопрос - будут ли отличающиеся внешние условия влиять на последовательность шагов.
Необходимо определить последовательность шагов, а также постоянна (фиксирована) эта последовательность или она может изменяться; при этом - если она может изменяться необходимо определить те факторы или условия, под действием которых это происходит. Например, если вы задумаете нарисовать картину, вам понадобятся бумага или холст, краски, кисти и т. д., но совершенно неважно, что именно появится у вас в первую очередь. Это дает возможность выполнять некоторые действия в произвольной последовательности или делать что-то параллельно.
Как на любом этапе получения требований очень важно воспринимать (и фиксировать) все, что говорит представитель заинтересованной стороны. В дальнейшем все это может быть пересмотрено и уточнено. Рекомендуется почаще просить более подробно объяснить, что именно в данном конкретном случае имеется в виду.
Сценарии отражают возможности (в терминах из области проблем), которые должна обеспечивать система и которые выстроены иерархическим образом, однако они не объясняют каким образом система должна обеспечивать эти возможности.
Можно отметить следующие преимущества использования сценариев:.
• позволяют представителям заинтересованных сторон пошагово проигрывать сценарии функционирования;.
• позволяют находить пропущенные шаги;.
• различные заинтересованные стороны могут предлагать различные сценарии;.
• позволяют строить хронологические последовательности.
Характеристики сценариев использования.
На рис. 5.4 приведен пример сценария, описывающего проведение выходного дня на парусной лодке, которую можно транспортировать на легковом автомобиле.
Рис. 5.4 Пример сценария использования.
Этот сценарий покрывает все моменты путешествия, начиная от погрузки лодки на автомобиль, подготовку к отплытию, хождение на лодке под парусом и возвращение домой. Сценарий также иллюстрирует и другие аспекты:.
• временную последовательность действий в общих чертах;.
• узловые элементы сценария являются возможностями верхнего уровня;.
• альтернативы;.
• периодически повторяющееся поведение;.
• моменты, когда последовательность действий не имеет значения (параллельные ветви);.
• исключения.
Использование временных последовательностей играет важную роль. Это помогает заинтересованным сторонам не только понять сценарий использования вообще, но и помогает формулировать пользовательские требования в правильном контексте.
Очень важно, что описания всех узловых элементов сформулированы как возможности соответствующего уровня. Использование слова «возможность ...» в имени узлового элемента помогает избежать тенденции описывать возможность как функцию (а, следовательно, избежать описывать далее ее детальную реализацию).
Сценарии обеспечивают весьма мощную поддержку при выявлении исключений. Как известно, во многих системах функциональность по обработке исключений бывает гораздо более сложной, чем та функциональность, которая обеспечивает их обычные возможности, необходимые заинтересованным сторонам. Можно попытаться попросить заинтересованные стороны самим сформулировать такие исключения, задавая им вопросы, типа: «какое развитие событий может считаться ошибочным при выходе из данного состоянии7» или «какое развитие событий может считаться ошибочным при входе в данное состояние?». Естественно, что описание действий по исправлению ошибок (возвращению в нормальное состояние) может быть получено с помощью вопроса: «что должно произойти (быть сделано), если события начнут развиваться по «неправильному» сценарию7».
Как видно из рис. 5.4, сценарий отражает возможность связи со службой береговой охраны в том случае, если лодка опрокинется. В отсутствии сценария это требование могло бы быть запросто пропущено.
Данный пример прекрасно иллюстрирует также и то, как сценарий может облегчить задачу выявления пропущенных областей требований. В данном случае из сценария следует, что были пропущены возможность транспортировать погруженную лодку (до места спуска на воду) и возможность спустить лодку на воду.
Целью создания сценариев является облегчение общения и взаимопонимания между людьми. Сценарий сам по себе не является требованием; в большей степени это просто упорядоченная структура для получения требований. Сценарии лишь помогают получить полный набор требований путем подробного рассмотрения всех функциональных аспектов использования будущей системы.
При этом следует заметить, что никакая из методик моделирования - и данная не исключение - не может отражать все возможно существующие концепции. Не существует единственно правильного пути, и разные специалисты предпочитают использовать различные методы и модели.
5.4.3 Определение границ системы.
На начальном этапе разработки сценариев использования очень полезно слегка раздвинуть границы предполагаемой системы по сравнению с теми пределами, в рамках которых она будет функционировать. Это поможет убедиться, что система будет правильно вписана в окружающий контекст и что ничего не будет пропущено. Но на определенном этапе очень важно все-таки четко определить границы системы, а, следовательно, и объемы работ по проекту.
Такой точкой определения полного объема проекта и рамок системы может являться подборка и компоновка полного набора сценариев использования. Разумеется, в дальнейшем это решение может быть пересмотрено, например, после предварительной оценки общей стоимости проекта (бюджета). Такая оценка обычно дается специалистами, имеющими опыт разработки систем в той же предметной области, что и разрабатываемая система. Конечно же, эти оценки, данные только на основе разработанных сценариев, являются весьма приблизительными, однако они дают достаточно хорошую возможность представить является ли адекватным бюджет предполагаемого проекта.
5.5 Получение требований.
Для наилучшего восприятия изложения мы разделили процесс получения требований и процесс формирования стратегии проверки. Процесс получения требований мы опишем в этом разделе, а процесс формирования стратегии проверки в следующем.
Рис. 5.5 отражает процесс получения требований для области проблем.
Рис. 5.5 Получение требований для области проблем.
Ключевыми аспектами этого процесса являются фиксирование требований и определение (формирование) структуры, в которой их следует размещать. После того, как определена структура для требований и сформулированы требования-кандидаты, становится возможным размещать требования в рамках структуры. На самом деле, конечно же, эти два процесса протекают параллельно и более того, - процесс получения требований-кандидатов вносит свою лепту в формирование структуры.
Следовательно, вместо того, чтобы иметь разнесенные процессы формирования структуры и получения требований-кандидатов, рис. 5.5 иллюстрирует, как оба эти процесса вносят каждый свой вклад в создание структурированных требований.
После получения структурированных требований желательно провести их последующее рецензирование, анализ и утонение.
5.5.1 Определение структуры.
Наличие хорошо организованной структуры играет исключительно важную роль в обеспечении управления и координации работ на всем протяжении жизненного цикла проекта. Сбор пользовательских требований обычно является итеративным процессом требования одно за другим фиксируются, уточняются, «очищаются» и затем помещаются в общую структуру.
При этом некоторые авторы думают по-другому и утверждают, что:.
• пользовательские требования не поддаются структурированию по своей природе;.
• вполне достаточно лишь установить связи между пользовательскими требованиями и спецификациями;.
• мы никогда не видели законченной структуры, поэтому достаточно просто поочередно работать с каждым отдельным требованием (без какой-либо привязки к структуре).
Такие подходы не имеют ничего общего с качеством разработок, а являются всего лишь отражением временных интересов разработчиков.
Мы утверждаем, что требования обязательно должны быть организованы и должна обязательно существовать хорошая структура для управления каждым индивидуальным требованием по мере его появления и внесения в эту структуру. Что характерно, аргументы в пользу необходимости структурирования уже описаны в Г лаве 4, поскольку являются теми же, на которые уже обращалось внимание при обсуждении проблем работы с требованиями, как в области проблем, так и в области решений. Лишний раз подчеркивая особую важность построения хорошей, понятной структуры, эта глава большее внимание уделяет именно тому, как получить такую структуру для пользовательских требований.
Основной концепцией построения структуры требований является сценарий использования. Однако для сложных систем может существовать достаточно большое количество сценариев использования. В таком случае рекомендуется все-таки потратить время и усилия на то, чтобы попытаться соединить все имеющиеся сценарии в один всеобъемлющий, если такое возможно. Конечно же, это не всегда может удаться, но попробовать в любом случае стоит. Помимо достижения своей прямой цели этот процесс даст многим возможность задуматься о системе, как о некоем целом, представить ее общий функционал, и, возможно, выявить очень много проблем.
Чтобы проиллюстрировать каким образом сценарии могут иногда объединяться, приведем пример из области ресторанного бизнеса. Для описания ресторана могут быть использованы три следующих сценария, которые отображены на рис. 5.6 - 5.8.
• жизнь ресторана от начала до конца - сценарий владельца;.
• рабочий день в ресторане - сценарий управляющего;.
• посещение ресторана клиентом - сценарий клиента.
Первый сценарий описывает жизнь ресторана - вначале ресторан приобретается владельцем, затем следует период владения рестораном и, в заключении, наступает момент его продажи.
— 1 Покупка
Рис. 5.7 Сценарий рабочего дня в ресторане.
Первой целью (состоянием) является пополнение запасов продуктов и напитков. В данном случае подразумевается, что у ресторана несколько поставщиков, но порядок доставки продуктов и напитков не имеет значения. Конечно, можно поспорить на тему, что пополнение запасов обязательно должно заканчиваться до момента открытия ресторана, но в нашем примере мы упростили себе жизнь, чтобы сделать пример более наглядным, и будем считать, что вся доставка осуществляется до момента открытия ресторана.
В сценарии рабочего дня ресторана затем идут периоды, когда ресторан бывает открыт для посетителей и когда ресторан закрыт - завершен рабочий день, производится уборка и составляется список для пополнения запасов на следующий день.
Сценарий посещения ресторана клиентом представляет собой просто последовательность состояний.
Если теперь мы попытаемся представить себе, каким образом можно объединить все эти отдельные сценарии в один общий, то можем заметить, что:.
• сценарий «рабочий день в ресторане» является повторяющимся сценарием для состояния «владение» в сценарии «жизнь ресторана», и.
• сценарий «посещение ресторана клиентом» может быть параллельно повторяющимся сценарием для состояния «открыт» в сценарии «рабочий день в ресторане».
На рис. 5.9 показана общая структура, объединяющая все три сценария.
Рис. 5.9 Объединенный сценарий и структура для получения требований для ресторана.
Этот объединенный сценарий может теперь рассматриваться как структура заголовков (структура разделов) для документа, содержащего требования.
Конечно же, не всегда есть возможность объединить все сценарии в один. Тут не существует универсального подхода, который мог бы всегда срабатывать. Если объединение не удается, то нужно просто рассматривать один сценарий за другим. И тогда структура документа с требованиями будет повторять последовательность сценариев, в каждый из которых «встроены» свои собственные требования.
По сути, структура в большой степени формируется в зависимости от списка заинтересованных сторон, участвующих в проекте. И хотя многие сценарии использования могут иметь различные ключевые цели (состояния), все равно следует предпринимать попытки включения сценариев один в другой.
В тоже время необходимо внимательно следить за тем, чтобы в структуре (документе, сценарии) не было повторений. Если же повторяющиеся части все же встречаются, то необходимо сделать так, чтобы этот элемент присутствовал только в одном месте.
Для этого можно использовать два подхода. Первый подход заключается в том, чтобы вообще исключить повторяющиеся разделы изо всех тех мест, где они присутствуют, и оформить (вынести) это в виде независимой секции. А уж потом изо всех тех мест, где этот элемент встречался ранее, сделать ссылки на новую секцию. Другой подход, заключается в том, чтобы оставить этот раздел в том месте, где он встречается впервые, а вместо всех последующих повторений использовать ссылки на это место в структуре.
5.5.2 Сбор требований Источники пользовательских требований.
Пользовательские требования могут быть сформированы из большого количества источников, например:.
• интервью с представителями заинтересованных сторон;.
• сценарии использования (обычно получаемые в результате интервью);.
• описательная документация (напр., различные отчеты, анализ рынка);.
• действующие системы, которые необходимо модернизировать;.
• проблемы, обнаруженные в существующих системах, и идеи как их исправить;.
• опыт работы с аналогичными системами;.
• разного рода прототипы, макеты, эскизы, т.д. продукта или самих требований;.
• возможности новых технологий (согласованные с заинтересованными сторонами);.
• результаты исследований;.
• опросы;.
• наблюдение за работой персонала или изучение видеозаписей их работы. Интервью.
Интервью это очень непростая задача. Для того чтобы суметь «вытянуть» из представителей заинтересованных сторон реальные требования, специалист, проводящий интервью, должен, в первую очередь, быть коммуникабельным и уметь правильно общаться. Интервью это исключительно психологическая задача, не имеющая ничего общего с организационными или техническими аспектами разработки систем. Необходимо помнить, что получение пользовательских требований от заинтересованных сторон это человеческая, а не техническая проблема. Однако несмотря на это, специалист, проводящий интервью, должен хорошо разбираться и в проблемной (предметной) области, чтобы не испытывать трудности при общении, и понимать все, что ему будут говорить представители заинтересованных сторон.
Очень важно разговаривать с людьми на их «языке», об их «мире» и не заводить разговор в область конкретных решений или обсуждения технических проблем. В течение интервью желательно попросить человека описать по шагам процесс его работы. Все беспорядочные заметки, сделанные в процессе интервью, должны быть затем аккуратно структурированы в наборы требований и переданы представителю заинтересованной стороны для рецензирования. Интервью это интерактивный (диалоговый) процесс и очень важно, чтобы специалист, проводящий интервью, не выполнял свою работу поверхностно, а как можно чаще задавал вопрос «Почему?», докапываясь до сути (при этом не выступая в роли судьи, сразу оценивая, что важно, а что нет).
Существует множество способов сформулировать этот простой вопрос по-разному, например: «С какой целью вы делаете... ?» или «Расскажите мне немного подробнее о...». Несмотря на предварительную подготовку, интервьюер может не быть экспертом в предметной области и, следовательно, в ходе интервью всегда будут необходимы дальнейшие уточнения и подробные разъяснения. Поэтому не бойтесь задавать «глупые» (на первый взгляд) вопросы. Существует только единственный глупый вопрос - это тот, который не задан!!! Поэтому важно осознавать, что, в конечном итоге, именно пользователь (представитель заинтересованной стороны) несет ответственность за пользовательские требования - вы лишь помогаете им формулировать требования.
Не забывайте, что обсуждение сценариев использования с будущими пользователями системы является ключом к успеху.
Ниже мы приводим некоторые советы, которые помогут вам при проведении интервью:.
• проводите интервью с представителями каждой категории заинтересованных сторон;.
• обращайте серьезное внимание на мнение каждого из интервьюируемых;.
• старайтесь документировать интервью и предлагайте собеседникам завизировать его (в некоторых случаях даже можно вести формальный протокол интервью и просить представителей заинтересованной стороны подписать его);.
• выявляйте те сценарии, которые являются наиболее значимыми для данных собеседников, и «проговаривайте» с ними каждый шаг, выявляя, что же собеседник должен иметь возможность делать в каждом из состояний сценария (требования типа «возможность»);.
• при необходимости создавайте новые сценарии использования, если они выявляются в ходе интервью, а затем формируйте пользовательские требования из этих новых сценариев;.
• пытайтесь выяснить степень важности для интервьюируемого каждого из требований;.
• если собеседник не может четко сформулировать какое-либо требование, то помогите ему - спросите о конечной цели этого требования, попросите проиллюстрировать предлагаемое требование на примере;.
• выявляйте любые ограничения, которые могут быть известны собеседникам;.
• давайте понять собеседникам, что именно их требования формируют систему;.
• стимулируйте и «провоцируйте» собеседника активно включаться в обсуждение;.
• никогда не высказывайте своего мнения относительно пользовательских требований;.
• не будьте поверхностными во время интервью, старайтесь докопаться до сути;.
• примите за правило такую последовательность действий - сразу же фиксируйте требование - как бы оно не звучало, - а потом постепенно, шаг за шагом его уточняйте.
Лучше всего обсуждение строить на принципе «от общего к частному». Очень важно быть уверенным в том, что все, что намечалось обсудить, было проговорено, и что при этом четко выделены области, не относящееся к делу.
Опыт проведения интервью подсказывает, что конкретные формы и содержание вопросов должны всегда зависеть от собеседников и ситуации.
Получение требований из неформальных документов.
Неформальные документы, к которым могут относиться результаты исследований, служебные распоряжения, переписка, и т.д. могут также содержать требования, которые просто скрыты от первого взгляда. Задача и состоит в том, чтобы эти требования оттуда извлечь и сделать их «видимыми».
Однако, решая эту задачу, необходимо всегда фиксировать первичный источник, из которого они получены.
Более того, соответствующая заинтересованная сторона должна завизировать эти требования и «взять на себя ответственность» за них (стать их «владельцем»).
Получение требований из сценариев использования.
После того, как был создан объединенный сценарий, становится возможным извлекать пользовательские требования непосредственно из него.
В некоторых случаях это делается простым перефразированием состояний (или целей) сценария использования. Например, состояние готовность к отплытию можно перефразировать и сформулировать «возможность» следующим образом: пользователь должен иметь возможность подготовить парусную лодку к отплытию.
В других случаях для этого требуется гораздо больше усилий.
Рис. 5.10 поможет нам продемонстрировать вышесказанное.
Рис. 5.10 Получение из сценария пользовательских требований типа «возможности».
Давайте рассмотрим следующее требование:.
Два человека должны иметь возможность погрузить лодку на крышу легкового автомобиля среднего размера.
Такая формулировка вызывает, как минимум, следующие вопросы:.
• Насколько сильными должны быть люди?.
• Что такое «легковой автомобиль среднего размера»?.
Эти моменты должны быть в последствии обязательно прояснены. Однако сейчас - и это очень важно - даже такое требование должно быть зафиксировано. Совершенно неважно пока, что формулировка требования далека от совершенства и содержит неясные моменты. Все эти нечеткости формулировки будут устранены позднее. Самое важное - не упустить идею!.
Перефразируя известное выражение, можно подвести черту под этим рассуждениями:.
Если работа заслуживает того, чтобы ее делали, то она заслуживает того, чтобы ее делали хорошо!.
Более подробную информацию о том, как правильно формулировать требования можно найти в главе 4.
Семинар по сбору требований (requirements workshop).
Одним из путей сбора пользовательских требований является проведение семинаров.
Это достаточно эффективный способ быстрого сбора требований. Очень важно собрать заинтересованные стороны в благоприятной обстановке и добиться понимания ими того, что семинар по сбору требований не будет тяжелым и не займет у них много времени. Необходимо придерживаться определенной структуры проведения семинара, но, тем не менее, семинар должен носить характер свободного диспута.
Как показано на рис. 5.11, участники семинара должны быть подготовлены к семинару и осознавать, что от них требуется.
Например, они должны понимать суть концепций:.
• заинтересованная сторона;.
• сценарий использования;.
• требование типа «возможность».
В зависимости от того, на каком этапе работ над проектом проводиться такой семинар, вполне вероятно, что уже существует предварительная версия набора требований, над которой вы будете работать. В противном случае, необходимо начать с того, что разделить всех участников на группы и попросить каждую группу разработать для будущей системы собственные сценарии использования. Затем необходимо попытаться объединить эти сценарии (по возможности) в один. Проверку отдельных и объединенного сценария желательно осуществлять уже при полном составе участников семинара. После обсуждения.
сценариев и внесения в них необходимых изменений можно уже переходить к извлечению требований из сценариев.
Рис. 5.11 Процесс получения пользовательских требований.
Как только будет получен предварительный набор требований, его нужно тут же выносить на обсуждение всех участников семинара. Необходимо поощрять критику и дискуссии. Возможность общения между различными группами заинтересованных сторон привносит весьма ощутимую пользу в процессе формирования требований. Часто случается, что эти люди, даже работая в одной компании, впервые видят друг друга на вашем семинаре. Поэтому и вам и им самим будет всегда интересно наблюдать, как взаимодействие между различными группами порождает требования, которые находятся на стыке интересов, - как желание иметь возможность делать что-то для одной группы пересекается с соответствующими желаниями и потребностями других групп.
При наличии проектора анализ и рецензирование полученных требований можно осуществлять в режиме on-line с привлечением всех участников семинара. Однако процесс идет более продуктивно, если весь коллектив собравшихся разделить на небольшие подгруппы и дать каждой из них собственный набор требований для независимого рецензирования и доработки, а затем уточненный полный набор требований просматривать еще раз уже всем коллективам. При таком подходе к организации семинара работа над требованиями к типичному проекту может продолжаться 3 - 4 дня.
Ключевыми элементами семинара являются формирование позитивного рабочего настроя, достижение нужного темпа работы и последующее поддержание его на протяжении всего семинара.
Следует заметить, что организация такого семинара потребует определенных усилий, однако полученный результат перекроет все затраты на его проведение.
Очень важно также, чтобы представители всех категорий заинтересованных сторон, присутствующих на семинаре, были уполномочены принимать решения.
Требования из опыта.
Проблемы, обнаруженные непосредственными пользователями системы, - это просто «золотая жила» для дальнейшей работы, - однако очень часто эта информация даже не принимается к рассмотрению. Складывается некое негативное отношение к информации такого рода, поскольку она ассоциируется с проблемами, однако эта информация может принести очень большую пользу.
Несомненно, что чем раньше обнаружена проблема, тем дешевле стоит ее устранение иногда для этого достаточно просто изменить формулировку требования или требований. Но с другой стороны, - если позволить легко, бесконтрольно и постоянно вносить изменения в проект, любой проект будет «похоронен» в самом начале. Поэтому если разработка системы предусматривает ее пошаговую реализацию (функционал внедряется не весь сразу, а постепенно), то становится возможным отложить внесение изменений до следующих версий.
Требования из прототипов.
Если вы разрабатываете совершенно новую систему, аналогов которой не существует, в этом случае прототипы, макеты просто незаменимы. Прототипы дают представление о том, как система будет выглядеть. Так в области разработки программного обеспечения прототипы очень часто применяются для моделирования пользовательского интерфейса, поскольку будущим пользователям системы без наглядного примера бывает очень трудно представить себе как будет выглядеть этот интерфейс.
Главная проблема при разработке прототипов это то, что разработчики очень часто увлекаются и тратят на разработку макета очень много времени и сил. Разработка прототипов должна каждый раз позиционироваться как выделенный подпроект со своими собственными требованиями. Цель разработки прототипа должна быть четко определена, поскольку она нужна не только для разработки прототипа как такового, но она может оказать неоценимую помощь в формировании самих пользовательских требований.
Можно отметить три проблемы, которые чаще всего встречаются при разработке прототипов:.
Избежать двух первых проблем вполне возможно с помощью хорошо сформулированных требований для прототипа. Для того же, чтобы исключить третью проблему, необходимо постараться раскрыть иллюзорную сущность такого прототипа, убедить заинтересованные стороны в том, что то, что они видят, является всего лишь макетом, который не может полноценно эксплуатироваться. При этом желательно использовать для прототипа средства и материалы, которые дают наглядное представление о временной сущности прототипа.
Ограничения в пользовательских требованиях.
Ограничение это такой тип требования, который не добавляет возможности системе. Вместо этого, такой тип накладывает определенные обязательства на то, каким образом может быть достигнуто наличие той или иной возможности в системе.
Возьмем для примера следующее утверждение:.
Клиент должен быть обслужен в течение 15 минут после размещения заказа.
Данное требование не меняет возможности системы, а всего лишь определяет характеристики предоставляемого сервиса.
Тем не менее, работая с ограничениями, необходимо соблюдать определенную осторожность. Совокупность ограничений, каждое из которых будет вполне оправдано, может сделать разработку в целом невозможной. Поэтому после анализа правомерности каждого конкретного ограничения необходимо провести анализ всей совокупности собранных ограничений, как единого целого.
И даже более - после того, как разработаны спецификации конкретных решений (определен дизайн), каждое ограничение должно быть проанализировано с точки зрения его влияния на стоимостные характеристики системы. В некоторых случаях наличие определенного ограничения может привести к необходимости введения дополнительных системных функций, что может увеличивать стоимость системы (например, реализация функции обеспечения безопасности, аварийной сигнализации или резервного копирования). До разработки спецификаций конкретных решений, можно только лишь догадываться о стоимости реализации ограничения. К сожалению, эта стоимость достаточно сильно зависит именно от выбранного варианта решения, но, даже несмотря на этот факт, предварительная оценка может быть сделана уже и сейчас - слишком большое количество ограничений может разрушить ваш проект (в том числе и с финансовой точки зрения).
Принято считать, что если ограничение накладывается на требование верхнего уровня, то действие ограничения наследуется также и всеми дочерними требованиями (нижнего уровня). Поэтому ограничение, по возможности, должна накладываться на как можно более высокий уровень иерархии возможностей, чтобы сократить применимость этого ограничения на каждом шаге, а, следовательно, и уменьшить его стоимость (см. рис. 5.12). Если же ограничение касается только одного требования, то оно может быть описано даже как часть самого требования.
Интересно отметить разницу между ограничениями на уровне пользовательских и системных требований. Ограничения на уровне пользовательских требований скорее относятся к результату, который должен быть получен. Системные же ограничения носят в большей степени «профессиональный» (более технический) характер и затрагивают скорее качество конечного продукта. Все пользовательские ограничения должны быть отражены в системных ограничениях. Иногда для этого необходимо изменить формулировку.
ограничения, а иногда и делать ничего не нужно - пользовательское ограничение без изменений переходит в системное.
Ограничения Возможности
Уточнение требований.
Анализируйте каждое требование с точки зрения его контекста и каждый раз убеждайтесь в том, что:.
• требование находиться на своем месте;.
• требование удовлетворяет качественным критериям, которые описывались в главе 4. Определение стратегии проверки.
Формирование стратегии проверки проходит по двум параллельным направлениям (см. рис. 5.13). Эта тема обсуждается подробнее в последующих разделах.
5.5.3 Определение критериев приемки.
Понимание того, как заинтересованные стороны собираются удостовериться в том, что их требования удовлетворены, является очень важным аспектом разработки требований.
Ответ на вопрос:.
Что убедит вас в том, что данное требование удовлетворено?.
может помочь даже более точно сформулировать само требование. Вот почему этот вопрос очень часто используется во время интервью представителей заинтересованных сторон.
Рис. 5.13 Процессы определения стратегии проверки.
Обычно на этот вопрос отвечают двумя разными способами:.
• в качестве примера может быть описана функциональная ситуация, в которой может быть продемонстрировано реализация требования, и/или.
• может быть зафиксировано некое числовое значение, достижение которого должно быть продемонстрировано системой.
Первый способ ответа на вопрос ведет непосредственно к процессу создания наборов тестов, испытаний и демонстраций возможностей, которые могут являться как раз частью стратегии проверки.
Во втором случае мы получаем значения показателей, которые должны быть достигнуты в результате успешного прохождения тестов или испытаний. Другими словами, мы формулируем критерий приемки требования или отметку о выполнении теста («пройден» «не пройден»).
Критерий приемки определяет - для каждого требования - показатель, достижение которого будет характеризовать «успешное» завершение теста. Критерий приемки обычно записывается в виде значения атрибута, ассоциированного с данным требованием. Другими словами, в большинстве случаев между требованием и критерием его приемки должна существовать связь типа «один к одному».
В случае с рестораном можно предположить, например, что критерий приемки, оценивающий деятельность ресторана, скорей всего будет иметь значение «успешно». Успех может измеряться по целому ряду показателей:.
• насколько вперед требуется зарезервировать место в ресторан, чтобы в него попасть.
(т. е. на какое время вперед ресторан уже полностью зарезервирован).
При этом разные заинтересованные стороны могут иметь различные мнения по поводу того, что является мерилом успеха. Например, управляющий банком, клиентом которого является владелец ресторана, будет больше заинтересован в двух первых показателях, а шеф-повар ресторана будет скорее заинтересован в двух последних показателях.
Следовательно, очень важно для каждого требования определить показатели критериев приемки, формулируемые каждой из заинтересованных сторон.
5.5.4 Определение стратегии проверки.
Способы, с помощью которых осуществляется приемка системы, зависят от характера системы.
Для больших систем имеющих только одно внедрение, например, таких как система управления воздушным транспортом страны, стратегия проверки должна строиться на том, что необходимо убедиться, что вся требуемая функциональность реализована; что авиадиспетчеры вполне довольны простотой использования системы; что система имеет достаточное быстродействие в периоды высокой нагрузки и т.д.
Это может потребовать проведения многосторонних тестов и испытаний. В первую очередь необходимо продемонстрировать все возможности системы при невысокой нагрузке. В том случае, если обнаружатся проблемы при невысокой нагрузке, то уже не будет никакого смысла переходить к дорогостоящим испытаниям при более высокой нагрузке.
Необходимо всегда учитывать стоимость конкретно разрабатываемой стратегии проверки.
Организация всесторонних интенсивных испытаний всегда очень дорогое удовольствие, поэтому к выбору типа испытаний нужно подходить очень аккуратно и здесь лучше всетаки следовать принципу «последовательности», так, например, прежде чем приступать к испытаниям корабля в открытом, да еще и в штормовом море, лучше вначале посмотреть на его поведение в спокойной бухте.
Немаловажно также не упускать из виду и общую стоимость всех совокупных проверок и испытаний. Суммарная стоимость проверок всегда должна быть соотнесена со стоимостью последствий от «необнаружения» недостатков в готовом продукте.
Так, например, если эксплуатация системы связана с риском для жизни людей, возможностью нанести непоправимый вред окружающей среде, или большими финансовыми потерями, то стратегия проверки должна быть очень подробной и выверенной (пусть и дорогой), чтобы иметь возможность убедиться в высочайшем качестве и безопасности системы. В случае же, когда риски и потери, связанные с ненахождением дефектов в конечном продукте, относительно невелики, то, может быть, стоит подумать о том, как разработать более дешевую стратегию проверки.
Практический вывод, вытекающий из формирования стратегии, следующий.
Если требование нельзя проверить тем или иным путем, то это требование не может называться требованием. Правильно разработанное требование это такое требование, которое легко понять и выполнение которого может быть легко продемонстрировано.
5.6 Заключение.
Пользовательские требования должны быть краткими и понятными насколько это возможно.
Пользовательские требования не должны быть техническими, но в то же время они должны быть реалистическими (реализуемыми).
В пользовательских требованиях больше внимания должно быть уделено ролям и ответственности, которые должны быть правильно распределены между категориями заинтересованных сторон.
При разработке пользовательских требований наиболее часто встречаются следующие проблемы:.
• чрезмерный уклон в сторону решений;.
• недостаточное внимание к идентификации реальных проблем, которые нужно решить;.
• отсутствие у заинтересованных сторон понимания того, что именно они должны нести ответственность за требования (владеть требованиями).
Пользовательские требования следует разрабатывать как можно раньше, потому что именно они определяют возможности, необходимые заинтересованным сторонам, при этом выраженные удобным и понятным для них языком.
Таким образом, необходимо сосредоточивать усилия именно на проблемной области, а не на области решений.
Пользовательские требования должны быть хорошо структурированы и (там, где возможно) должны быть «увязаны» с первоисточником информации, из которого они были получены. Необходимо четко определить границы ответственности сторон при разработке пользовательских требований. Заинтересованные стороны должны нести ответственность за содержание требований. Требования должны быть ограничены рамками бюджета, соблюдение которого должно контролироваться финансистами. За сбор и оформление требований должны отвечать обученные специалисты-аналитики.