С требования. 6. Описание С-требований (требований заказчика) (2). 2 Описание стребований (требований
 Скачать 308.39 Kb.
|
|
2.1. Описание С-требований (требований заказчика) Перед проектированием ПП необходимо четко сформулировать, что хотят заказчики и что они ожидают получить. Заказчики разрабатывают концепцию — часто подсознательную и непонятную полностью в том, как их приложение будет работать. Эту концепцию иногда называют моделью приложения, или концепцией работы. Разные люди обычно имеют различные представления о программном продукте. Например, возможное представление о работе бюро погоды может быть следующим: • средство для преобразования необработанных материалов метеоцентра в графическое представление; • система реального времени для предсказания погоды; • приложение, предупреждающее пользователей о погодных аномалиях. Эти различные представления о работе программного продукта приведут к совершенно разным программным приложениям. Менеджер проекта или разработчик требований помогает заказчику четко сформулировать его концепцию работы. Поскольку обычно заказчики не владеют технологией выражения таких концепций, инженеры могут предложить подходящие технологии, такие, как варианты использования, потоки данных или переходы состояний. Ведущую роль в разработке концепции ведет бизнесаналитик (или Program/Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка на весь срок разработки концепции проводится интенсивная работа с инвестором проекта. Цель — выработка единого видения будущего продукта. Если это заказной продукт, то инвестором является конечный заказчик. Если продукт предназначен для открытого рынка, то ответственными за него являются учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создает образ будущего продукта. В заключение аналитик с экспертной командой определяют границы проекта, которые должны содержать ориентировочные сроки и бюджет продукта. На рисунке 2.2 показаны этапы разработки концепции продукта. Рис. 2.2 Этапы разработки концепции продукта Результатом разработки концепции является PVD (Product Vision Document — документ образа продукта, если продукт разрабатывается под заказ) или MRD (Marketing Requirement Document — документ рыночных требований, если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различием между PVD и MRD является то, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов. По окончании разработки концепции продукта делается вывод о целесообразности разработки ПП. Сбор и анализ бизнестребований Первым и самым важным этапом в разработке продукта является сбор бизнестребований. Цель этой работы — определить основные требования бизнеса (исходные данные, истинные цели, которым должен служить продукт, и проблемы, которые нужно преодолеть). Для продуктов под заказ и продуктов для открытого рынка процесс сбора бизнестребований существенно различается. Продукт под заказ — заказчик определен с самого начала, ему известны начальные предпосылки (стимулы) для инициации проекта и проблемы, которые продукт должен решать. В связи с этим сбор требований начинается с определения исходных предпосылок, целей продукта и описания сценариев рабо ты пользователей с будущим продуктом. Анализ конкурентных продуктов, которые могут удовлетворять схожие сценарии, делается в самом конце (табли ца 2.2). Таблица 2.2 Последовательность задач, выполняемых на этапе сбора бизнестребований Продукт под заказ Продукт для открытого рынка Определение исходных стимулов Определение исходных стимулов Определение целей продукта и критериев успеха Обзор конкурентов Определение потребностей клиента Определение целевого сегмента рынка Обзор конкурентов Определение потребностей клиента Определение целей продукта и критериев успеха Продукт для открытого рынка — сектор рынка с самого начала может быть не определен, а цели продукта основываются на конкурентном анализе. В результате сразу за определением исходных предпосылок (стимулов) идет обзор конкурентов, далее идет определение целевого сегмента рынка и потребностей его заказчиков и только после этого определяются цели продукта и критерии его успеха. Причиной создания программного продукта может быть следующее: • потребность рынка; • производственная необходимость; • потребность заказчика; • технический прогресс; • юридические ограничения или нормы. Одной из задач является определение одной или нескольких целей, которые преследуют заинтересованные стороны при разработке продукта. Необходимо описать основные преимущества, которые предоставит продукт для бизнеса. Сделать это надо в измеряемом виде. Также нужно определить механизм, используя который, заинтересованные люди будут измерять успех продукта в конечном итоге. Например, финансовые: • освоить Х% рынка за Y месяцев; • увеличить сектор рынка в стране X на Y% за Z месяцев; • достигнуть объема продаж X единиц или дохода, равного $Y, за Z ме сяцев; • получить Х% прибыли или дохода по инвестициям в течение Y меся цев; • достигнуть положительного баланса по этому продукту в течение Y месяцев; • сэкономить $Х в год, которые в настоящий момент расходуются на об служивание системы; • уменьшить затраты на поддержку на Х% за Z месяцев; • увеличить валовую прибыль для существующего бизнеса с Х до Y%; • и др. Нефинансовые: • достигнуть показателя удовлетворения покупателей, равного X, в те чение Y месяцев со времени выпуска товара; • увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%; • достигнуть определенного времени для достижения доминирующего положения на рынке; • разработать надежную платформу для «семьи» связанных продуктов; • разработать специальную базовую технологическую основу для орга низации; • получить X положительных отзывов в отраслевых журналах к опреде ленной дате; • добиться признания продукта лучшим по надежности в опубликован ных обзорах продуктов к определенной дате; • соответствовать определенным федеральным и государственным по становлениям; • и др. Определение целевого сегмента рынка требуется только для продуктов, ориентированных на широкий рынок. Принято сегментировать рынок следующим образом. Рынок домашних пользователей (может быть также разделен на обычных и квалифицированных пользователей). Рынок корпоративных пользователей 1. SMB (Small and Medium Business) — компании, насчитывающие от 1 до 250 сотрудников. Также может быть разделен на Micro (или Soho) — 1–10 со трудников, Small — 10–25 и Medium — 25–250. 2. Large — компании, насчитывающие 250–2500 сотрудников. 3. Corporation — корпорации с числом сотрудников более 2500. Это разделение принято использовать в связи с тем, что требования, налагаемые пользователями, которые принадлежат к разным сегментам рынка, кардинально отличаются. Это касается как функциональности, способов администрирования, так и вопросов лицензирования и поддержки продукта. Практически невозможно создать продукт, который бы подошел одновременно домашним пользователям и мог бы эксплуатироваться в крупной компании. Для того чтобы правильно выбрать сегмент рынка, необходимо определить требования, налагаемые каждым из сегментов рынка с учетом предметной области продукта. При выборе сегмента рынка следует определить требования, продиктованные каждым из сегментов к продукту. Выбор целевого сегмента должен основываться на возможностях: бюджете проекта, квалификации аналитиков и разработчиков, наличии возможностей для продвижения продукта. После определения целевого сегмента определяются проблемы, которые будут решаться при помощи будущего ПП. Создание сценариев Наиболее эффективным способом получения ответа на многие вопросы является определение сценариев работы пользователей с будущим продуктом. Сценарий — это совокупность всех процессов, в которых будет участвовать продукт, а также описание окружения, в котором его планируется использовать. Сценарий не должен являться описанием работы отдельного пользователя для достижения конкретной цели. Его ценность состоит в том, что он описывает способы взаимодействия с продуктом всех его пользователей одновременно на протяжении всего цикла эксплуатации продукта. Таким образом, сценарий гарантирует отсутствие взаимоисключающих требований к продукту и дает возможность убедиться, что ничто не забыто. Для проверки сценария надо всего лишь проанализировать его выполнение всеми заинтересованными лицами (проиграть его). Для продуктов под заказ сценарии использования продукта формируются самим заказчиком. Как правило, сколько заказчиков, столько и сценариев. Наи более эффективным методом является живой диалог с заказчиком, в котором аналитик задает наводящие вопросы, а заказчик отвечает на них. Если личный контакт невозможен, то используют вопросники, содержащие «нужные» вопросы, по которым заказчику легче будет написать сценарий. Для открытого рынка сначала определяются профили будущих клиентов продукта, а затем для каждого из них создается подробный сценарий его использования. Аналитик может описывать сценарии самостоятельно, используя информацию из личного опыта или открытых источников. Другой вариант — найти клиентов или компании, подходящие под ранее определенные профили и получить сценарии непосредственно от них. Важно не путать понятие клиента и пользователя. Клиентом может являться компания, в которой множество сотрудников будут являться пользователями системы. В таком случае профиль клиента описывает характерные черты и проблемы компании, а профиль пользователя (описываемый позднее) — характеристики её сотрудников. Благодаря использованию сценариев основное внимание уделяется реальным потребностям конкретных пользователей системы и лишь потом определяется необходимый функционал продукта. Каждый сценарий содержит все процессы, в которых планируется использовать продукт. Каждый сценарий должен содержать: • имя конкретного заказчика или его профиль (в качестве заголовка); • информацию обо всех типах пользователей, которые будут работать с продуктом; • все процессы, которые будут затрагивать продукт; • операционная среда, в которой будет использоваться продукт; • требования к дизайну: операционная система, приложения, с которыми интегрируется, форматы ввода-вывода; • приоритет. Зависит от того, насколько важен этот заказчик или как много покупателей будут попадать под профиль клиента, описанного в сценарии. Определение функциональных требований и требований к дизайну После сбора всей информации от пользователей необходимо ее систематизировать. Сценарии избыточны. Они содержат большое количество повторений или дополнений. В процессе выделения требований должен быть создан список уникальных требований к продукту, которые не должны повторяться, но могут дополнять друг друга. Необходимо выделить два типа требований: функциональные бизнес требования и требования к дизайну (нефункциональные требования). Функциональные бизнестребования описывают потребность (заказчика/покупателя), которую должен удовлетворить будущий продукт. Основной вопрос, на который должны отвечать бизнестребования — зачем та или иная функциональность. Требования к дизайну описывают операционную среду, в которой будет функционировать продукт, интерфейсы взаимодействия с пользователем или другими системами, форматы хранения и передачи данных, а также требования к надежности, производительности, обслуживанию и доступности системы. Эти требования в значительной степени влияют на средства разработки, архитектуру и используемые технологии при разработке продукта, а значит и на конечный бюджет и сроки разработки ПП. Поэтому крайне важно как можно более точно определить важнейшие требования к дизайну именно на стадии определения концепции. Разбивая требования на отдельные элементы, основным критерием должна быть возможность реализации этих требований отдельно друг от друга. Если требования сильно зависят друг от друга, то они должны быть реализованы вместе. Цель разделения требований на составные части — получение возможности принимать решения о целесообразности реализации каждого требования в отдельности и назначать им различные приоритеты, что в дальнейшем обеспечит гибкость в определении списка требований для первой и всех последующих итераций продукта или исключения из текущей версии продукта. Это критично для ПП, бюджет и сроки которых строго определены и не могут быть пересмотрены. Как только все требования структурированы, следует назначить им приоритет. Обзор конкурентов Для выпуска продукта на рынок требуется придать ему уникальность, определить, чем он лучше других, почему именно его будут покупать. Это может быть большая функциональность, скорость, удобство использования или более низкая цена. Поэтому для определения текущего положения на рынке важно серьезно подойти к обзору конкурентов. Это важно как при создании продукта для открытого рынка, так и для продукта на заказ. Вторая цель обзора конкурентов — рассмотрение идей, реализованных в продукте. Цель проста — использовать наиболее удачные решения, реализованные в конкурирующих продуктах, и исключить неудачные. Структура обзора конкурентов следующая: • конкурентное положение на рынке; • список конкурентов (резюме по каждому конкуренту); • список проблем, которые призваны решать продукты; • список возможностей продуктов. 1. Определить список конкурентов на рынке и выделить лидеров. Работа проводится с лидерами на рынке. Определить лидеров можно, используя различные обзоры, результаты опросов или продаж. В числе лидеров может оказаться не только продукт с отличным функционалом, но и бесплатное приложение, предоставляющее необходимый минимум возможностей. Если предметная область продуктов достаточно популярна, то в сети можно найти уже готовый обзор, который будет содержать необходимую ин формацию. Обзор конкурентов, как правило, самый продолжительный этап определения концепции продукта. 2. Узнать цену и способ доставки ПП у конкурентов. Нужно посмотреть демонстрационную версию продукта или маркетинговые материалы, содержащие список возможностей и руководство пользователя. 3. Составить список проблем конкурентов. Это особенно актуально при проектировании продукта для открытого рынка, так как благодаря ему аналитик сможет определить причины приобретения пользователями будущего продукта. Составить список проблем можно, исследовав продукт самостоятельно, но более эффективный способ — просмотреть документацию по продукту. Качественные продукты содержат сценарии использования продукта в тех или иных ситуациях, а маркетинговые материалы — выгоды, которые сулит продукт при его использовании. По завершении исследования проблем, которые решают ПП конкурентов, следует провести повторный анализ бизнестребований к будущему продукту. Полученная информация может улучшить бизнестребования к ПП. 4. Составить список возможностей. Здесь нужно описать все важные возможности, которые были реализованы в конкурентных продуктах для удовлетворения проблем, описанных в предыдущем пункте. На основе этого списка можно узнать, как хорошо продукт решает заявленные проблемы, какие у него сильные и слабые стороны. На этом этапе изучается сам продукт либо его документация. Результатом работы будет таблица со списком возможностей, которые предоставляют все продукты. В столбце продукта напротив каждой возможности должно быть указано, предоставляет ли конкретный продукт эту возможность (обычно помечаются как « +» или «−»). 5. Резюме по сильнейшим конкурентам. Следует описать их преимущества и недостатки, выделить интересные идеи. 6. Конкурентное положение на рынке. Если проектируется продукт для открытого рынка, то в заключение необходимо описать его положение на рынке. В нем нужно обозначить зрелость целевого рынка и выделить продукты, с которыми будет вестись наиболее ожесточенная борьба. Далее необходимо перечислить наиболее перспективные пути развития продукта и его шансы на успех. Создание образа и списка возможностей будущего продукта При работе над образом решения аналитики определяют очертания будущего ПП, который бы удовлетворял всем требованиям, описанным выше. На этом этапе определяются все основные характеристики, которыми должен обладать будущий продукт, чтобы достичь ранее поставленные цели. А на основе экспертной оценки уже могут быть определены ожидаемые сроки и бюджет продукта. Образ решения будет служить доказательством того, что разработчики выбрали правильный путь (или напротив), и оказывает наибольшее влияние при выборе команды разработчика для тендерных проектов. Когда известно, кому и зачем нужен продукт, следует определить, какую функциональность он будет предоставлять для удовлетворения потребностей будущих пользователей. Задача упрощается тем, что после обзора конкурентов известны решения, которые уже предлагаются конкурентами, их слабые и сильные стороны. Работу начинают с определения нефункциональных возможностей, которые должны удовлетворять ранее собранным требованиям к дизайну. Эти возможности имеют максимальное влияние на дизайн продукта, а потому должны быть четко определены на стадии создания концепции. Именно от списка не функциональных возможностей будет зависеть сложность реализации основных функций продукта. Следовательно, они будут определять стоимость реализации и тестирования этих функций. Нефункциональные возможности должны содержать: • имя возможности; • приоритет возможности; • наличие этой функции у конкурентов (для каждого конкурента); • краткое описание возможности; • примечание для конкурентов. Затем нужно добавить основные функции, которые требуется реализовать в продукте. Каждый элемент списка возможностей должен содержать: • имя функции, которую требуется реализовать в продукте; • приоритет; • наличие у конкурентов (желательно для каждого из конкурентов); • краткое описание (если требуется); • отметки о конкурентах; • экспертную оценку необходимого времени и затрат, связанных с реа лизацией функциональности. При экспертной оценке считается, что функционал продукта должен удовлетворять все нефункциональные возможности. Если одна или несколько нефункциональных возможностей сильно увеличивает стоимость функции, то следует сделать пометку об этом и позднее обсудить целесообразность поддержки этой нефункциональной возможности продуктом или отдельными его функциями. В результате список возможностей должен содержать все высокоуровневые возможности, которые будут реализованы в продукте, а также уникальные никем не реализованные возможности. На протяжении всего жизненного цикла разработки «Образ продукта» должен являться указателем развития проекта. Его описание должно быть емким и он должен содержать основную информацию. Для достижения этой цели лучше всего подходит следующий шаблон: • «для» — целевая аудитория покупателей; • «который» — положение о потребностях или возможностях; • «этот» — имя продукта; • «является» — категория продукта; • «который» — ключевое преимущество, основная причина для покупки или использования; • «в отличие от» — основной конкурирующий продукт, текущая система или текущий бизнеспроцесс; • «наш продукт» — положение об основном отличии и преимуществе нового продукта. Список возможностей должен полностью соответствовать образу решения. Определение содержания контрольных событий проекта Образ продукта подразумевает список направлений, по которым он дол жен развиваться, а содержание относится к определенному проекту или его итерации, в которых реализуется меньше возможностей продукта, чем это воз можно. Образ продукта будет изменяться относительно медленно. Содержание в свою очередь более динамично, так как менеджер проекта изменяет содержи мое каждой версии в соответствии с графиком, бюджетом, ресурсами и критериями качества. Объем первоначальной версии продукта зависит от целей, которые возлагаются на продукт. Как правило, объем первоначальной версии должен быть минимально необходимым для того, чтобы удовлетворить пользователей. Это делается для того, чтобы как можно раньше занять нишу на рынке или предоставить решение заказчикам. Для продуктов, разрабатываемых под заказ, функционал строго определен заказчиком. Но для того чтобы наладить обратную связь с пользователем на раннем этапе, продукт часто разбивается на несколько версий. Используется итеративный процесс разработки, в котором результатом определенных итераций должен быть продукт, готовый к промышленному внедрению на большом количестве рабочих мест. Определение контрольных событий — это обязательный этап процесса разработки проекта, который тесно переплетен со сбором и детализацией требований к проекту. После определения концепции проекта невозможно точно определить срок его реализации. Бюджет может быть определен лишь на основе экспертной оценки, его точность обычно не превышает 50%. По завершении сбора и анализа требований точность оценки, сделанной на их основе, уже может достигать 60–70%. И только после завершения проектирования опытный менеджер сможет определить бюджет с точностью до 80–90%. Определение основных профилей пользователей Для того чтобы ПП был удобен пользователям, нужно определить, кто им будет пользоваться. На практике даже для домашних продуктов очень сложно определить «среднего пользователя», чтобы на основе его потребностей вести проектирование. Для корпоративных продуктов это еще сложнее, так как директор будет пользоваться одной функциональностью, его секретарь — другой, а бухгалтер — третьей. По этой причине перед началом сбора требований должны быть определены основные профили пользователей (рисунок 2.3). Рис. 2.3 Пример диаграммы профилей пользователей продукта Профили пользователей явно или неявно уже должны содержаться в сценариях, поэтому их нужно только выделить. Для домашних продуктов разделение обычно производится, исходя из уровня подготовленности пользователя и его интересов, для корпоративных продуктов основным критерием является специализация работника и круг его обязанностей. При общении с конечными пользователями необходимо узнать, для достижения каких целей будет использоваться будущий программный продукт. Для этого производится сбор пользовательских историй. Пользовательская история — это вариант использования будущего продукта в конкретной ситуации с целью достижения измеримого результата. Пользовательские истории могут содержать как сложные инструкции с ответвлениями, так и конкретные примеры, при этом используются термины предметной области. Пользовательская история должна содержать пример реальной ситуации, а их систематизацию и оптимизацию можно сделать позже. Если же бизнеспроцессы, которые автоматизирует продукт, строго формализованы, то пользовательская история должна содержать алгоритмы действий ПП или людей, работающих с ней. Ошибка, которую делают при сборе требований к продуктам, — это формирование образа продукта на основе ответов на вопрос «Что должен делать продукт?» или «Как должен работать продукт?». Целью сбора требований является получение ответа на вопрос «Для чего нужен продукт?». А потому, единственный вопрос, который должен задаваться пользователю, — это «Зачем?». Дизайн пользовательского интерфейса входит в фазу проектирования программного обеспечения, но его можно считать и частью фазы требований. Заказчики часто представляют себе приложение в форме графического пользовательского интерфейса. Описать работу ПП можно, используя черновой вариант пользовательского интерфейса. |