анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
|
часть контекстной диаграммы для Chemical Tracking System. Вся система изображена кружком; на контекстной диаграмме намеренно не показывают внутренние объекты системы, процессы и данные. «Система» внутри кружка может иметь любую комбинацию ПО, оборудования или людских ресурсов. Оконечные элементы в прямоугольниках представляют классы пользователей («Химик» или «Покупатель»), отделы («Отдел охраны труда и техники безопасности»), другие системы («База данных по обучению») или аппаратные устройства («Считывающее устройство штрих-кода»). Стрелками показаны потоки данных («запрос химиката») или физические элементы («контейнер с химикатом») между системой и оконечными элементами. Вы можете ожидать, что поставщики химикатов должны быть показаны на диаграмме в виде оконечных элементов. Ведь компания направляет заказы для выполнения поставщикам, а те отправляют контейнеры с химикатами и счета в Contoso Pharmaceuticals, отдел же закупок пересылает чеки продавцам. Однако эти процессы происходят вне Chemical Tracking System, как часть операций отделов закупок и приобретений. Глядя на контекстную диаграмму, становится совершенно ясно, что система не участвует напрямую в размещении заказов у поставщиков, в получении продуктов или оплате счетов. Назначение таких средств, как контекстная диаграмма, заключается в стимулировании ясного и точного взаимодействия между заинтересованными в проекте лицами. Эта ясность гораздо важнее слепого следования правилам создания «правильной» контекстной диаграммы. Однако я горячо рекомендую использование схему, показанную на рисунке, в качестве стандарта, когда вы возьметесь рисовать контекстные диаграммы. Предположим, вы решите использовать треугольник вместо кружка для изображения системы и эллипсы вместо прямоугольников для изображения оконечных элементов. Вашим коллегам будет трудно читать диаграмму, нарисованную в соответствии с вашими личным предпочтениями, а не с общепринятым стандартом.  Основные источники получения информации о потребностях клиентов Способы и источники получения информации от клиентов зависят от специфики продукта и среды разработки. Необходимо выслушивать разные точки зрения и выбирать различные источники информации, а это лишний раз подтверждает, что работа по сбору требований тесно связана с общением. Вот несколько типичных источников получения информации при сборе требований к ПО. Опросы потенциальных пользователей и дискуссии с ними. Самый очевидный способ выяснить потребности потенциальных пользователей нового программного продукта — опросить их. В этой главе рассказывается, как выбрать толковых представителей пользователей, а в главе 7 — как выяснить, что же им действительно необходимо. Документы, где описан уже работающий или конкурирующий продукт. Эти документы могут также содержать корпоративные или отраслевые стандарты, которых необходимо придерживаться, а также постановления и законы, которым должен соответствовать продукт. Пригодятся и описания уже реализованных и будущих бизнес-процессов. Опубликованные сравнительные обзоры позволяют выявить недостатки других аналогичных продуктов, на которые стоит вовремя обратить внимание, чтобы получить конкурентное преимущество. Спецификации требований к системе. Для продукта, включающего программные и аппаратные компоненты, создается спецификация требований ксистеме, описывающая продукт в целом. Отдельные требования к системе в целом касаются каждой подсистемы (Nelsen, 1990). Аналитик может вычленить дополнительные, более мелкие функциональные требования из требований к конкретной подсистеме. Отчеты об ошибках и претензии к возможностям работающей системы. Персонал внутрикорпоративной и выездной службы поддержки — ценный источник информации. Они в курсе проблем, с которыми сталкиваются пользователи работающей системы, и постоянно выслушивают идеи клиентов по совершенствованию ее следующей версии. Маркетинговые исследования и опросы пользователей. Опросив массу потенциальных пользователей продукта, вы получите кучу информации. Проконсультируйтесь с экспертом по планированию и управлению опросами, дабы убедиться, что задаете нужные вопросы нужным людям (Fowler, 1995). Опрос позволяет проверить, насколько четко вы понимаете требования, которые собираете или, как вы думаете, уже выявили, однако это не лучший способ стимулировать творческое мышление. Прежде чем начать опрос, необходимо критически изучить предполагаемые вопросы. Велико же будет ваше разочарование, когда вы поздно обнаружите, что один из вопросов сформулирован неоднозначно или что важного вопроса в списке не оказалось. Наблюдение за пользователями на рабочих местах. Наблюдая «один рабочий день из жизни пользователя», аналитик выявляет особенности работы действующей системы, а также потребности потенциальных пользователей будущей системы. Такое исследование позволяет проверить информацию, собранную в ходе интервью, определить темы новых опросов, выявить проблемы действующей системы и понять, какие функции новой системы необходимы для автоматизации операций (McGraw и Harbison, 1997; Beyer и Holtzblatt, 1998). Наблюдая за работой пользователей, вы лучше и полнее поймете суть рабочего процесса, чем если просто попросите их описать все этапы их работы. Излагая и обобщая данные, аналитик должен абстрагироваться от ситуации и рассматривать ее несколько «сверху; это гарантирует, что собранные требования будут представлять интересы класса пользователей в целом, а не отдельных лиц. Кстати, опытные аналитики зачастую способны предложить что-то весьма дельное для совершенствования текущих бизнес-процессов. Сценарий анализа задач пользователей. Определив, какие задачи пользователю требуется выполнять средствами системы, аналитик должен выработать необходимые функциональные требования к системе. Это — суть подхода, основанного на применении вариантов использования, описанного в главе 8. Не забудьте указать, какие данные необходимы и генерируются входе выполнения задачи, а также источники этих данных. События и реакция на них. Перечислите внешние события и соответствующую реакцию системы на них. Данный способ особенно хорош для систем реального времени, которые считывают и обрабатывают потоки данных, коды ошибок, управляющие сигналы и сигналы прерывания от внешних устройств. Классы пользователей Помимо всего прочего, пользователей продукта можно подразделять по таким признакам: — по частоте использования продукта; — по опыту в предметной области и опыту работы с компьютерными системами; — по требуемой им функциональности; — по задачам, которые им приходится выполнять; — по правам доступа к системе (например, обычный пользователь, гость или администратор). На их основе формируются классы пользователей. Некоторых сотрудников можно отнести к нескольким классам. Так, администратор иногда работает с системой, как рядовой пользователь. Конечные пользователи ПО вне системы, показанные на контекстной диаграмме (предыдущий рисунок), представляют собой потенциальных кандидатов на отдельные классы пользователей. Это часть непосредственных пользователей продукта из большой группы клиентов, которых можно выделить из всех заинтересованных в проекте лиц. Иерархия клиентов, пользователей и заинтересованных лиц:  Очень заманчиво поделить пользователей на классы по их географическому положению, виду бизнеса, которым занимается компания, или занимаемой должности, а не на основании того, как они взаимодействуют с системой. Например, компания — производитель банковского ПО первоначально предполагала разделить пользователей по типам финансовых учреждений, в которых те работают: крупный коммерческий банк, небольшой коммерческий банк, ссудо-сберегательная общество или кредитный союз. В действительности же таким образом выделяются потенциальные сегменты рынка, а не различные классы пользователей. Во всех этих финансовых учреждениях у людей, занимающихся ссудами, формируются более или менее аналогичные функциональные требования к системе, поэтому логично выделить их в отдельный класс пользователей, назвав его, скажем, сотрудники, принимающие заявки. Это может быть специалист по кредитованию, вице-президент, менеджер по работе с клиентами и даже банковский кассир — при условии, что все они используют систему, чтобы помочь кому-либо подать заявку на получение займа. Одни классы пользователей для вас важнее других. Когда вы принимаете решения о приоритетах или пытаетесь найти компромисс требований, выдвигаемых различными классами пользователей, мнение привилегированных классов имеет первостепенное значение. К последним относятся группы пользователей, работа которых с продуктом определяет, способствует ли он достижению заявленных бизнес-целей или нет. Это не означает, что заинтересованных лиц, оплачивающих разработку системы (они, вполне вероятно, вообще не являются ее пользователями), или тех, кто имеет большое политическое влияние, следует обязательно включать в привилегированные классы. Непривилегированные классы составляют те пользователи, которые по причинам безопасности, конфиденциальности или правовым причинам не работают с продуктом (Cause и Lawrence, 1999). Остальные классы пользователей можно проигнорировать. Они получат то, что получится, то есть при разработке системы вам не надо учитывать их интересы. Мнение прочих классов пользователей при определении требований к продукту имеют примерно одинаковое значение. У каждого класса пользователей есть свой набор требований, сформировавшийся в ходе выполнения задач. Кроме того, появляются различные нефункциональные требования, например удобство применения, которые влияют на проектирование пользовательского интерфейса. Новичков волнует, насколько легко научиться работать (или вспомнить принципы работы) с продуктом. Такие клиенты предпочитают графические интерфейсы, упорядоченное представление информации на экране, подробные подсказки, мастеров и согласованность с другими приложениями, с которыми они уже знакомы. Тех, кто поопытнее, волнует легкость использования и эффективность работы. Они ценят клавиатурные сокращения, макросы, возможности настройки, панели инструментов, возможности создания сценариев и в некоторых случаях даже предпочитают интерфейс командной строки графическому интерфейсу пользователя. Ловушка. Не упустите из виду классы косвенных или вторичных пользователей, Они могут обращаться к вашему приложению не напрямую, а работать с его данными и сервисами через другие приложения или отчеты. Однако даже опосредованный клиент все равно остается вашим клиентом. Это может показаться странным, однако классы пользователей не обязательно состоят из людей, В качестве дополнительных классов пользователей можно рассматривать сторонние приложения и аппаратные компоненты, с которыми взаимодействует ваша система. Например, система впрыска топлива в автомобиле представляет собой пользовательский класс ПО, встроенного в систему управления двигателем. Система впрыска топлива не может говорить сама за себя, поэтому аналитику придется выяснить у инженера, разработавшего систему впрыска, требования к ПО, которое управляет процессом. В самом начале работы над проектом необходимо определить и охарактеризовать различные классы пользователей, чтобы узнать у представителей всех важных классов их требования. Один из полезных способов определения классов называется «от расширения — к сжатию» («Expand Then Contract») (Gottesdiener, 2002). Для начала придумайте как можно больше классов пользователей: столько, сколько сможете. Не бойтесь, если их окажется несколько дюжин — позже вы объедините их и классифицируете. Важно не пропустить какой-либо класс, иначе это аукнется вам позже. Следующий этап —выявить группы с похожими потребностями: их можно объединить в один класс или рассматривать как несколько подклассов одного крупного класса пользователей. Постарайтесь, чтобы список отдельных классов не превышал пятнадцати. Одна компания, разрабатывавшая ПО для примерно 65 корпоративных клиентов, рассматривала каждого из них как отдельного пользователя со своими потребностями. Классификация клиентов по шести классам значительно упростило работу с требованиями для будущих версий продукта. Помните: не все заинтересованные в проекте лица на самом деле будут работать с продуктом, поэтому класс пользователей — это лишь группа людей, которым следует предоставить возможность выразить свое мнение о создаваемом продукте. Задокументируйте классы пользователей и их отличительные черты, меру ответственности и физическое расположение в спецификации требований к ПО. Менеджер проекта по разработке системы контроля химикатов, о которой шла речь в предыдущих главах, выявил следующие классы пользователей и их характеристики:
Включите в спецификацию требований к ПО всю существенную информацию о каждом классе пользователей, например относительный или абсолютный размер и привилегированность класса. Это поможет команде разработчиков определить, какие запросы об изменениях наиболее важны, и в дальнейшем оценить ценность изменений. Примерная оценка объема и типа системных транзакций позволит специалисту по тестированию разработать алгоритм использования системы и в последующем планировать действия по проверке системы. Чтобы было легче внедрить идею с классами пользователей в жизнь, стоит описать типичного представителя каждого класса (Cooper, 1999), например, вот так: Фред, 41 год, работает химиком в Contoso Pharmaceuticals уже 14 лет, с тех пор как получил степень кандидата наук. Нетерпелив с компьютерами. Обычно Фред одновременно работает над двумя проектами в смежных областях химии. В его лаборатории хранится около 400 контейнеров и баллонов с химикатами. Ежедневно ему требуется в среднем 4 новых химиката со склада. Два из них — промышленные химикаты из имеющихся на складе, один необходимо заказать и еще один придется взять из химических образцов компании. Иногда Фреду требуются опасные химикаты, для работы с которыми необходима специальная подготовки. Приобретая какой-либо химикат впервые, Фред хочет, чтобы ему по электронной почте автоматически поступали соответствующие материалы по технике безопасности. Ежегодно Фред создает около 10 новых химикатов, которые отправляет на склад. Он хочет получать по электронной почте автоматически сгенерированный отчет о заказанных им в прошлом месяце химикатах; это позволит ему контролировать расход химических веществ. Изучая требования химиков, рассматривайте Фреда как архетип данного класса пользователей и задайте себе вопрос: «Что Фреду нужнее всего?» Разработка требований. Подход с применением вариантов использования Вариант использования (use case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица. Действующим лицом (actor) может быть человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для доптижения некой цели (Cockburn, 2001). Еще одно название действующего лица — роль пользователя, поскольку это роль, которую члены одного или нескольких классов пользователей могут выполнять по отношению к системе (Constantine и Lockwood, 1999). Например, в варианте использования Chemical Tracking System «Запрос химиката» участвует действующее лицо — Сотрудник, разместивший заказ на химикат. Класса пользователей Chemical Tracking System с таким именем не существует. И химики, и специалисты, работающие на складе химикатов, могут запрашивать химикаты, поэтому члены любого из этих классов могут играть роль Сотрудника, разместившего заказ на химикат. Понятие «вариант использования» пришло из мира объектно-ориентированного программирования. Тем не менее они годятся и для проектов, где применяются любые приемы разработки, поскольку пользователям безразлично, как именно создается ПО. Варианты использования лежат в основе широко применяемого Унифицированного процесса разработки ПО (Jacobson, Booch и Rumbaugh, 1999). Варианты использования меняют традиционный подход к сбору информации; пользователей не спрашивают, как прежде, что, с их точки зрения, должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь. Цель такого подхода — описать все подобные задачи. До включения каждого варианта использования в утвержденную версию требований, заинтересованные в проекте лица проверяют, не выходит ли он за границы проекта. Теоретически в конечный набор вариантов использования должна входить вся желаемая функциональность системы. На практике же вам вряд ли удастся добиться стопроцентного результата, однако варианты использования помогут вам выполнить эту задачу полнее, чем какой-либо другой прием сбора информации, которым я когда-либо пользовался. |