анализ требований. Приложение 1. Анализ требований по Вигерсу. Приложение 1 анализ требований (по Вигерсу)
 Скачать 1.62 Mb.
|
|
ПРИЛОЖЕНИЕ 1 АНАЛИЗ ТРЕБОВАНИЙ (по Вигерсу) Цель анализа требований в проектах Цель анализа требований в проектах — получить максимум информации о заказчике и специфике его задач, уточнить рамки проекта, оценить возможные риски, а также сформировать проектную группу, на которую будет возложена значительная часть предстоящих работ. Типы требований. Типы требований:  Документ об образе и границах проекта Документ об образе и границах (vision and scope document) собирает бизнес-требования в единый документ, который подготавливает основу для последующей разработки продукта. В некоторых организациях с этой же целью создают устав проекта или положение о бизнес-задачах. Очень полезен и документ основных рыночных требований (market requirements document, MRD). В нем более детально, чем в документе об образе и границах, рассматриваются целевые сегменты рынка и проблемы, касающиеся коммерческого успеха продукта. Владельцем документа об образе и границах считается тот, кто финансирует проект или несет аналогичную ответственность. Аналитик требований может вместе с этим человеком разрабатывать документ об образе и границах проекта. Информация, касающаяся бизнес-требований, должны поступать от лиц, четко понимающих, почему они взялись за проект. Это может быть клиент или топ-менеджер организации, разрабатывающей продукт, тот, кого привлекают технические новинки, менеджер по продукту, эксперт в данной предметной области или специалисты отдела маркетинга. Далее приведен пример шаблона документа об образе и границах проекта. Шаблоны стандартизируют структуру документов, создаваемых проектными командами каждой организации. Как и в случае с любым шаблоном, измените его в соответствии со спецификой вашего проекта. Может показаться, что части документа об образе и границах повторяются, однако они должны смыкаться. Пример шаблона документа об образе и границах проекта: 1. Бизнес-требования 1.1. Исходные данные 1.2. Возможности бизнеса 1.3. Бизнес-цели и критерии успеха 1.4. Потребности клиента или рынка 1.5. Бизнес-рынки 2. Образ решения 2.1. Положение об образе проекта 2.2. Основные функции 2.3. Предположения и зависимости 3. Масштабы и ограничения проекта 3.1. Объем первоначально запланированной версии 3.2. Объем последующих версий 3.3. Ограничения и исключения 4. Бизнес-контекст 4.1. Профили заинтересованных лиц 4.2. Приоритеты проекта 4.3. Операционная среда Бизнес-шансы. Использовать слабо защищенные документы о конкурирующем продукте. Бизнес-цель. Получить признание в качестве наиболее защищенного продукта на рынке, используя обзоры в отраслевых журналах и опросы потребителей, и захватить 80% рынка. Пожелания потребителей. Более защищенный продукт. Функция. Новый надежный механизм защиты. Бизнес-требования 1. Бизнес-требования Проекты выпускаются с полным убеждением, что новый продукт для кого-то сделает мир лучше. Бизнес-требования описывают основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Для различных типов продуктов — информационных систем, коммерческих пакетов ПО и систем контроля, работающих в режиме реального времени, — выделяются различные преимущества. 1.1 Исходные данные Суммирует обоснование и содержание нового продукта. Здесь помещают общее описание предыстории или ситуации, в результате которых было принято решение о создании продукта. 1.2 Возможности бизнеса Для коммерческого продукта описывают существующие рыночные возможности и рынок, на котором продукту придется конкурировать с другими продуктами. Для корпоративной информационной системы описывают бизнес-проблему, которая разрешается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться. Кроме того, приведите здесь сравнительную оценку существующих продуктов и возможных решений, указав, в чем заключается привлекательность продукта и его преимущества. Опишите проблемы, которые не удается разрешить без продукта. Покажите, насколько он соответствует тенденциям рынка, развитию технологий или корпоративной стратегии. Кратко опишите другие технологии, процессы или ресурсы, необходимые для удовлетворения клиента. 1.3 Бизнес-цели и критерии успеха Суммирует важные преимущества бизнеса, предоставляемые продуктом, в количественном и измеряемом виде. Далее приведены примеры и финансовых и нефинансовых целей (Wiegers, 2002с). Если подобная информация приведена где-то еще, например в документе о бизнес-задачах, сошлитесь на этот документ, а не копируйте информацию. Определите, как заинтересованные лица будут определять и измерять успех проекта (Wiegers, 2002с). Установите факторы, которые максимально влияют на успех проекта — и те, которые организация может контролировать, и те, которые находятся вне сферы ее влияния. Определите меру для оценки того, были ли достигнуты бизнес-цели. Примеры финансовых и нефинансовых бизнес-целей 1. Финансовые бизнес-цели: Освоить Х% рынка за Y месяцев Увеличить сектор рынка в стране X на Y% за Z месяцев Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев Получить Х% прибыли или дохода по инвестициям в течение Y месяцев Достигнуть положительного баланса по этому продукту в течение Y месяцев Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы Уменьшить затраты на поддержку на Х% за Z месяцев Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара Увеличить валовую прибыль для существующего бизнеса с Х до Y% 2. Нефинансовые бизнес-цели: Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y% Достигнуть определенного времени для достижения доминирующего положения на рынке Разработать надежную платформу для семьи связанных продуктов Разработать специальную базовую технологическую основу для организации Получить X положительных отзывов в отраслевых журналах к определенной дате Добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате Соответствовать определенным федеральным и государственным постановлениям Уменьшить время оборота до X часов на Y% звонков покупателей в службу поддержки 1.4 Потребности клиентов или рынка Опишите потребности типичных покупателей или целевых сегментов рынка, включая потребности, которые не удовлетворяют настоящие продукты или информационные системы. Представьте проблемы, с которыми в настоящее время сталкиваются клиенты и которые решит новая система, и предоставьте примеры того, как покупатели будут использовать этот продукт. Определите на высоком уровне все известные важные требования к интерфейсу или производительности, но не касайтесь деталей дизайна или реализации. 1.5 Бизнес-риски Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категории рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес. Оцените возможные потери от каждого фактора риска, вероятность его возникновения и вашу способность контролировать его. Определите все возможные действия по смягчению ситуации. Если вы уже подготовили эту информацию для анализа бизнес-задач или похожего документа, ссылайтесь на этот источник, а не копируйте эту информацию здесь. Образ решения В этом разделе документа определяется стратегический образ системы, позволяющей выполнять бизнес-задачи. Этот образ обеспечивает основу для принятия решений в течение жизненного цикла продукта. В него не надо включать детали функциональных требований или информацию, связанную с планированием проекта. 2.1 Положение об образе проекта Составьте сжатое положение об образе проекта, обобщающее долгосрочные цели и назначение нового продукта. В этом документе следует отразить сбалансированный образ, удовлетворяющий различные заинтересованные лица. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов. Далее показан шаблон, состоящий из ключевых слов, который прекрасно подходят для документа об образе продукта (Moore, 1991); — для [целевая аудитория покупателей]; — который [положение о потребностях или возможностях]; — эта (этот) [имя продукта] — является [категория продукта]; — который(-ая) [ключевое преимущество, основная причина для покупки или использования]; — в отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс]; — наш продукт [положение об основном отличии и преимуществе нового продукта]. Вот как выглядит положение об образе для Chemical Tracking System в Contoso Pharmaceuticals: Для ученых, которым нужно запрашивать контейнеры с химикатом, данная Chemical Tracking System является информационной системой, которая обеспечит единую точку доступа к складу химикатов и к поставщикам. Система будет знать местоположение каждого контейнера с химикатом в компании, количество химиката в контейнерах и полную историю перемещения и использования каждого контейнера. Эта система сэкономит компании 25% затрат на химикаты в первый год работы, позволив полностью использовать уже полученные химикаты, ликвидировать меньшее количество частично истраченных или просроченных химикатов и применять единую стандартную систему приобретения химикатов. В отличие от действующих сейчас механизмов заказов химикатов, которые выполняются вручную, наш продукт будет генерировать все отчеты, необходимые для соответствие федеральным и государственным постановлениям, в которых требуются сведения об использовании, хранении и ликвидации химикатов. 2.2 Основные функции Назовите или пронумеруйте каждую основную функцию нового продукта или возможность, предоставляемую пользователям, уникальным последовательным способом, подчеркивая те из них, которые отличают его от предыдущих или конкурирующих продуктов. Дав каждой функции уникальное имя (в отличие от маркера абзаца), вы сможете отследить каждую функцию до отдельных требований пользователей, функциональных требований и других элементов систем. 2.3 Предположения и зависимости Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ об образе и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, TCI получите возможность обговорить основные положения проекта. Так вы избежите путаницы и ухудшения ситуации в будущем. Например, спонсор Chemical Tracking System предположил, что новая система заменит существующую систему складского учета и будет взаимодействовать с системой закупок компании Contoso. Также задокументируйте важнейшие зависимости проекта от внешних факторов — изменения индустриальных стандартов или правительственных положений, других проектов, поставщиков со стороны или партнеров по разработке. Масштабы и ограничения проекта Когда химик изобретает новую химическую реакцию, которая преобразует один тип химиката в другой, он пишет документ, в который входит раздел «Рамки и ограничения», где описывает, что получится и не получится в результате этой реакции. Точно так же для проекта по разработке ПО следует определить его рамки и ограничения. Вам необходимо указать, что может делать система, а что не может. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц. Иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта. Требования, выходящие за границы продукта, следует отклонять, если только они не настолько ценны, чтобы специально под них расширить проект, естественно, соответствующим образом изменив в бюджет, график и кадровый состав. Документируйте отклоненные требования и причины отказа от них, поскольку они имеют свойство появляться снова. 3.1 Объем первоначальной версии Обобщает основные запланированные функции, включенные в первоначальную версию продукта. Опишите характеристики качества, которые позволят продукту предоставлять предполагаемые выгоды различным классам пользователей. Если ваша задача — сосредоточиться на разработке и уложиться в график, вам следует избегать искушения включить в версию 1.0 каждую функцию, которая когда-нибудь в будущем может понадобиться какому-то потенциальному покупателю. Увеличение сроков и сдвиг графика— типичный исход такого коварного расползания объема. Сосредоточьтесь на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше. Команда, с которой мой коллега Скотт делал последний проект, решила, что пользователи должны иметь возможность запускать собственную службу доставки вместе с первой версии ПО. Версия 1 не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; это основа работы команды. Первая версия системы выполняет лишь базовые задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования, 3.2 Объем последующих версий Если вы представляете поэтапную эволюцию продукта, укажите, какие функции будут отложены и желательные сроки последующих выпусков. В последующих версиях вы сможете реализовать дополнительные варианты использования и функции и расширить возможности первоначальных вариантов использования и функций (Nejmeh и Thomas, 2002). Вы также сможете повысить производительность, надежность и другие характеристики качества по мере совершенствования продукта. Чем дальше вы заглядываете, тем более расплывчатыми будут границы проекта. Вам наверняка придется передвинуть функциональность с одного запланированного выпуска до другого и, возможно, добавлять незапланированные функции. Короткие циклы выпусков часто удобны для сбора отзывов клиентов. 3.3 Ограничения и исключения Определение границы между тем, что входит и выходит за границы проекта, — отличный способ управления расползанием объема и ожиданиями клиентов. Перечислите все возможности или характеристика которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано. Бизнес-контекст В этом разделе обобщаются некоторые бизнес-проблемы проекте, включая профили основных категорий заинтересованных лиц и приоритеты управления. 4.1 Профили заинтересованных лиц Заинтересованными в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могут влиять на этот результат (Project Management Institute, 2000; Smitr,2000). Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. Вам не нужно описывать каждую группу заинтересованных лиц, например юристов, которые проверяют соответствие надлежащим законам. Сферой вашего интереса должны стать различные группы клиентов, целевые рыночные сегменты и различные классы пользователей, входящих в эти сегменты. В профиль каждого заинтересованного в проекте лица включается следующая информация: Основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют: — улучшенная производительность; — меньшее количество переделок; — снижение себестоимости; — ускорение бизнес-процессов; — автоматизация задач, ранее выполнявшихся вручную; — возможность выполнять совершенно новые задачи; — соответствие соответствующим стандартам и правилам; — лучшая, по сравнению с текущими продуктами, легкость и простота использования; — их вероятное отношение к продукту; — наиболее интересные функции и характеристики; — все известные ограничения, которые должны быть соблюдены. 4.2 Приоритеты проекта Чтобы принимать эффективные решения, заинтересованные лица должны договориться о приоритетах проекта. Один из подходов к этому заключается в рассмотрении пяти измеряемых параметров проекта: функции (или объем), качество, график, затраты и кадры (Wiegers. 1996а). В любом проекте каждый из этих параметров относится к одной из трех категорий: — ограничение — лимитирующий фактор, в рамках которого должен оперировать менеджер проекта; — ключевой фактор — важный фактор успеха, ограниченно гибкий при изменениях; — степень свободы — фактор, который менеджер проекта может до определенной степени изменять и балансировать относительно других параметров. Задача менеджера проекта — настроить те факторы, которые представляют собой степени свободы для достижения ключевых факторов успеха проекта е рамках, налагаемых ограничениями. Не все факторы могут быть ключевыми, как и не все — ограничениями. Менеджеру проекта необходима определенная степень свободы для того, чтобы он мог реагировать должным образом на изменение требований к проекту или внешних обстоятельств. Представьте себе, что отдел маркетинга неожиданно требует создать продукт на месяц раньше сроке. Какова будет ваша реакция? — Вы отложите реализацию определенных требований до более поздней версии? — Сократите запланированный цикл тестирования системы? — Оплатите сверхурочную работу вашим специалистам или пригласите специалистов по контракту для ускорения разработки? — Привлечете ресурсы других проектов для разрешения ситуации? Именно от приоритетов проекта зависят ваши действия в подобных ситуациях. 4.3 Операционная среда Опишите среду, в которой будет использоваться система, и определите важнейшие требования к доступности, надежности, производительности и целостности. Эта информация существенно влияет на определение архитектуры системы, что является первым — и часто самым важным — этапом дизайна. Архитектура системы, предназначенной для поддержки пользователей, которые находятся далеко друг от друга и которым необходим круглосуточный доступ, сильно отличается от той, что предназначена для доступа пользователей, находящихся рядом, только в рабочие часы. На нефункциональные требования, такие. как отказоустойчивость и способность обслуживать систему во время ее работы, требуется значительное количество средств, отпущенных на дизайн и реализацию. Чтоб прояснить ситуацию, задайте заинтересованным лицам уточняющие вопросы. — Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи? — Когда пользователям, находящимся в различных географических местоположениях, требуется доступ к системе? — Где данные генерируются и используются? Насколько далеко друг от друга расположены эти местоположения? Нужно ли объединять данные из разных местоположений? — Известно ли максимальное время отклика для получения доступа к данным, которые могут храниться удаленно? — Готовы ли пользователи смириться с прерыванием работы службы или непрерывный доступ к системе крайне важен для работы их компании? — Какие элементы управления безопасностью и требования к защите данных необходимы? Контекстная диаграмма Уточнение рамок определяет границу и связи системы, которую мы разрабатываем, со всем остальным миром. Контекстная диаграмма (context diagram) графически иллюстрирует эту границу. Она определяет оконечные элементы (terminators), расположенные вне системы, которые определенным образом взаимодействуют с ней, а также данные, элементы управления и материальные потоки, протекающие между оконечными элементами и системой. Контекстная диаграмма представляет собой высший уровень абстракции в диаграмме потока данных, разработанной по принципам структурного анализа (Robertson и Robertson, 1994), но эта модель полезна и в случае применения какой-либо другой методики разработки. Вы можете включить контекстную диаграмму в документ об образе и границах, или определить ее как приложение к спецификации требований, или как часть модели потоков данных системы. Ниже, на рисунке, показана |