Файл: Практические задания.pdf

11 

циональность  будет  нести продукт,  чтобы  удовлетворить  потребности  пользо-

вателей. 

Результатом  этого  этапа  является  законченное  техническое  задание  к 

продукту.  Оно  должно  содержать  полное  описание  поведения  будущего  про-

дукта и не содержать неоднозначностей и вопросов. 

12 

Практическое задание №2. Описание С-требований  

1.  Определить целевой сегмент рынка. 

2.  Определить бизнес роли пользователей и составить сценарии работы. 

Каждый сценарий должен содержать: 

•  Имя конкретного заказчика или его профиль (в качестве заголовка). 

•  Информацию обо всех типах пользователей, которые будут работать с 

программным продуктом (ПП). 

•  Все процессы, которые будут затрагивать продукт. 

•  Операционная среда, в которой будет использоваться продукт. 

•  Требования к дизайну: операционная система, приложения, с которы-

ми интегрируется будущий ПП, форматы ввода вывода. 

•  Приоритет.  Зависит  от  того,  насколько  важен  этот  заказчик  или  как 

много покупателей будут попадать под профиль клиента, описанного в сцена-

рии.  

3.  Определить функциональные требования. 

4.  Определить требования к дизайну (не функциональные требования). 

5.  Создать образ продукта. 

6.  Построить диаграмму потоков данных (использовать средства BPwin). 

Методические рекомендации для выполнения практической работы 

Первым  и  самым  важным  этапом  в  разработке  продукта  является  сбор 

бизнес требований. Цель этой работы – определить основные требования биз-

неса  (исходные  данные,  истинные  цели,  которым  должен  служить  продукт  и 

проблемы, которые нужно преодолеть). 

Для продуктов под заказ и продуктов для открытого рынка процесс сбора 

бизнес требований существенно различается. 

13 

Продукт  под заказ –  заказчик  определен  с самого  начала,  ему  известны 

начальные  предпосылки  (стимулы)  для  инициации  проекта  и  проблемы,  кото-

рые  продукт  должен  решать.  В  связи  с  этим,  сбор  требований  начинается  с 

определения исходных предпосылок, целей продукта и описания сценариев ра-

боты  пользователей  с  будущим  продуктом.  Анализ  конкурентных  продуктов, 

которые могут удовлетворять схожие сценарии, делается в самом конце. 

Продукт для открытого рынка – сектор рынка с самого начала может 

быть не определен, а цели продукта основываются на конкурентном анализе. 

В  результате,  сразу  за  определением  исходных  предпосылок  (стимулов) 

идет обзор конкурентов, далее идет определение целевого сегмента рынка и по-

требностей его заказчиков и только после этого определяются цели продукта и 

критерии его успеха. 

Определение целевого сегмента рынка 

Этот элемент является частью MRD и, как правило, требуется только для 

продуктов, ориентированных на широкий рынок. Принято сегментировать ры-

нок следующим образом: 

Рынок домашних пользователей (может быть также разделен на обычных 

и продвинутых пользователей). 

Рынок корпоративных пользователей. 

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. 

Это разделение принято использовать в связи с тем, что требования, нала-

гаемые пользователями, которые принадлежат к разным сегментам рынка, кар-

динально  отличаются.  Это  касается  как  функциональности,  способов  админи-

стрирования, так и вопросов лицензирования и поддержки продукта. Практиче-

ски  невозможно  создать  продукт,  который  бы  подошел  одновременно  домаш-

14 

ним пользователям и в тоже время мог бы эксплуатироваться в крупной компа-

нии. 

Для  того  чтобы  правильно  выбрать  сегмент  рынка,  необходимо  опреде-

лить требования, налагаемые  каждым из сегментов рынка с учетом предметной 

области продукта. 

Теперь,  когда  определен  целевой  сегмент  для  вашего  продукта,  следует 

определить кто, какие проблемы и в каких условиях будет решать при помощи 

будущего продукта. 

Создание сценариев 

Наиболее эффективным способом получения ответа на эти вопросы явля-

ется определение сценариев работы пользователей с будущим продуктом. Сце-

нарий  –  это  совокупность  всех  процессов,  в  которых  будет  участвовать  про-

дукт,  а  также  описание  окружения,  в  котором  его  планируется  использовать. 

Сценарий не должен являться описанием работы отдельного пользователя для 

достижения  конкретной  цели.  Его  ценность  состоит  в  том,  что  он  описывает 

способы взаимодействия с продуктом всех его пользователей одновременно на 

протяжении всего цикла эксплуатации продукта. Таким образом, сценарий га-

рантирует отсутствие взаимоисключающих требований к продукту и дает воз-

можность легко убедиться, что никто и ничто не забыто. Для проверки сцена-

рия  надо  всего  лишь  проанализировать  его  выполнение  всеми  заинтересован-

ными лицами (проиграть его). 

Для продуктов под заказ сценарии использования продукта формируются 

самим  заказчиком.  Как  правило  –  сколько  заказчиков,  столько  и  сценариев. 

Наиболее эффективным методом является живой диалог с заказчиком, в кото-

ром  аналитик  задает  наводящие  вопросы  (пытается  разговорить  заказчика),  а 

заказчик отвечает на  них.  Если  личный  контакт невозможен,  как правило,  по-

могают  вопросники,  содержащие  «нужные»  вопросы,  по  которым  заказчику 

легче будет написать сценарий. 

15 

Для открытого рынка сначала определяются профили будущих клиентов 

продукта,  а  затем  для  каждого  из  них  создается  подробный  сценарий  его  ис-

пользования. Аналитик  может описывать сценарии самостоятельно, используя 

информацию  из  личного  опыта  или  открытых  источников.  Другой  вариант, 

позволяющий  достичь  явного  преимущества  –  найти  клиентов  или  компании, 

подходящие под ранее определенные профили и получить сценарии непосред-

ственно от них. 

Важно  не  путать  понятие  клиента  и  пользователя.  Клиентом  может  яв-

ляться  компания,  в  которой  множество  сотрудников  будут  являться  пользова-

телями системы. В таком случае, профиль клиента описывает характерные чер-

ты  и  проблемы  компании,  а  профиль  пользователя  (описываемый  позднее)  – 

характеристики еѐ сотрудников. 

Благодаря  использованию  сценариев  акцент  делается  на  реальные  по-

требности конкретных пользователей системы и лишь, потом определяется не-

обходимый функционал продукта. Каждый сценарий содержит все процессы, в 

которых планируется использовать продукт. 

Функциональные  бизнес  требования  описывают  потребность  (заказчи-

ка/покупателя),  которую  должен  удовлетворить  будущий  продукт.  Основной 

вопрос,  на  который  должны  отвечать  бизнес  требования  –  зачем  та  или  иная 

функциональность. 

Требования  к  дизайну  описывают  операционную  среду,  в  которой  будет 

функционировать  продукт,  интерфейсы  взаимодействия  с  пользователем  или 

другими системами, форматы хранения и передачи данных, а также требования 

к надежности, производительности, обслуживанию и доступности системы. Эти 

требования в значительной степени влияют на средства разработки, архитекту-

ру и используемые технологии при  разработке продукта, а значит и на конеч-

ный бюджет и сроки продукта. Поэтому крайне важно как можно более точно 

определить  важнейшие  требования  к  дизайну  именно  на  стадии  определения 

концепции.