Acceptance and Evaluation Criteria Definition

Определение критериев приемки и оценки — определение требований, которые должны быть удовлетворены для того, чтобы решение считалось приемлемым для ключевых заинтересованных сторон.

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

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

Критерий приемки и оценки может быть определен, если может быть продемонстрированно, что решение или компонент решения соответствует требованию. Критерий приемки обычно используется, когда только одно возможное решение в настоящее время оценивается и, как правило, выражается в виде положительного или отрицательного решения. Критерии оценки используются для сравнения нескольких решений или компонентов решения и допускают использование диапазона возможных баллов.
Элементы метода
1. Тестируемость
2. Скоринг (рейтинг)

Backlog Management

Бэклог (backlog) — это приоритезированный список всех работ, записанный в виде коротких описаний.
Каждый элемент бэклога должен удовлетворять следующим принципам:

• Detailed Appropriately — иметь надлежащую детализацию;
• Estimated — иметь оценку;
• Emergent — должен быть возникающим, неожиданно появляющимся. Эмерджентность — наличие у какой-либо системы особых свойств, не присущих её элементам, а также сумме элементов, не связанных особыми системообразующими связями, несводимость свойств системы к сумме свойств её компонентов. Т.е. бэклог не статичен, он изменяется с течением времени, по мере того, как мы больше узнаем о решении, истории в бэклог добавляются, удаляются элементы или изменяются их приоритеты;
• Prioritized — элементы бэклога должны быть приоритезированы.

Управление бэклогом — это «наука» скользящей работы через этапы последовательного жизненного цикла продукта/решения в эффективной форме.

Ключевыми аспектами успешного управления бэклогом являются:

• Постановка целей;
• Назначение и согласование приоритетов;
• Установление организационных обязательств и отношений;
• Реализация процесса достижения целей;
• Измерение производительности;
• Анализ производительности;
• Аудит процесса.

Управление бэклогом включает в себя следующие процессы:

• Управление рабочими запросами;
• Разработка заказов на выполнение работ, подготовка к работе и ремонтные процедуры;
• Планирование работ;
• Выполнение работы и мониторинг незавершенных этапов работ.

Product Backlog:

Sprint Backlog:

Balanced Scorecard

Сбалансированная система показателей (ССП) — концепция переноса и декомпозиции стратегических целей для планирования операционной деятельности и контроля достижения целей. По сути ССП — это механизм взаимосвязи стратегических замыслов и решений с ежедневными задачами, способ направления деятельности всей компании на достижение стратегических целей.

Основная структурная идея BSC состоит в том, чтобы сбалансировать систему показателей в виде четырех групп.
Первая группа включает традиционные финансовые показатели. Как бы мы ни доказывали важность рыночной ориентации предприятия и совершенства внутренних процессов, собственника всегда в первую очередь будут интересовать показатели финансовой отдачи на вложенные средства. Поэтому сбалансированная система должна начинаться (в классификации) и заканчиваться (в конечной оценке) финансовыми показателями.

Вторая группа описывает внешнее окружение предприятия, его отношение с клиентами. Основными фокусами внимания выступают:

• способность предприятия к удовлетворению клиента;
• способность предприятия к удержанию клиента;
• способность приобретения нового клиента;
• доходность клиента;
• объем рынка;
• рыночная доля в целевом сегменте.

Третья группа характеризует внутренние процессы предприятия:

• инновационный процесс;
• разработка продукта;
• подготовка производства;
• снабжение основными ресурсами;
• изготовление;
• сбыт;
• послепродажное обслуживание;

Четвертая группа позволяет описать способность предприятия к обучению и росту, которая фокусируется в следующие факторы:

• люди с их способностями, навыками и мотивацией;
• информационные системы, позволяющие поставлять критическую информацию в режиме реального времени;
• организационные процедуры, обеспечивающие взаимодействие между участниками процесса и определяющие систему принятия решения.

6 обязательных элементов СПП:
1. Перспективы (perspectives) — компоненты, при помощи которых проводится декомпозиция стратегии с целью ее реализации. Обычно используются 4 базовые перспективы, однако их список можно дополнить в соответствии со спецификой стратегии компании. Базовыми перспективами являются:

• Финансы (получение стабильно растущей прибыли — «как видят нас акционеры компании»);
• Клиенты (улучшение знания каждого клиента — «как видят нас клиенты»);
• Процессы (внутренние процессы компании — «чем мы выделяемся среди конкурентов»);
• Персонал (обучение и развитие) и инновации («как мы создаем и увеличиваем ценность для наших клиентов»).

2.Стратегические цели (objectives) определяют, в каких направлениях будет реализовываться стратегия.

3. Показатели (measures) — это метрики достижений, которые должны отражать прогресс в движении к стратегической цели. Показатели подразумевают определенные действия, необходимые для достижения цели, и указывают на то, как стратегия будет реализована на операциональном уровне.

4. Целевые значения (targets) — количественные выражения уровня, которому должен соответствовать тот или иной показатель.
5. Причинно-следственные связи (cause and effect linkages) должны связывать в единую цепочку стратегические цели компании таким образом, что достижение одной из них обуславливает прогресс в достижении другой (связь по типу «если-то»).
6. Стратегические инициативы (strategic initiatives) — проекты или программы, которые способствуют достижению стратегических целей.

Benchmarking and Market Analysis

Benchmarking (Бенчмаркинг)

Бенчмаркинг – это процесс изучения хозяйственной деятельности конкурентов, продуктов, услуг и процессов деятельности конкурентов, с целью использования их положительного опыта в работе своей компании (реализации изменений для достижения и сохранения конкурентоспособности).
В зависимости от объектов сравнения бенчмаркинг может подразделяться на несколько видов:

• Внутренний бенчмаркинг – при этом виде бенчмаркинга осуществляется сравнение процессов (продуктов, услуг) внутри организации. В качестве объектов выбираются близкие или похожие процессы (продукты, услуги). При внутреннем бенчмаркинге довольно легко собрать данные, однако возможности для сравнения ограничены, и результаты могут оказаться предвзятыми.
• Конкурентный бенчмаркинг – сравнение проводится с прямыми конкурентами (по предоставляемым продуктам или услугам), работающими на местном, региональном или международном рынке. Для этого вида бенчмаркинга необходимо выбирать конкурентов, находящихся на другом «уровне» рынка. Например, организация, работающая на местном рынке, может выбрать для сравнения организацию, работающую на международном рынке. В этом случае данные, полученные при сравнении, будут более обоснованными и важными, но их довольно трудно получить.
• Функциональный бенчмаркинг – сравниваются процессы собственной организации с похожими процессами другой организации, но работающей в другой сфере деятельности. При таком виде бенчмаркинга можно получить объективные и важные данные с меньшими усилиями, применяя этичные и легальные методы получения информации.
• Обобщенный бенчмаркинг – для этого вида бенчмаркинга отбираются организации, которые обладают лучшими в своем сегменте процессами и подходами. Такие организации открыто публикуют информацию о деятельности (примерами могут служить публикации по производственной системе Toyota, или по системе 6–сигм компании Motorola). Из этих процессов и подходов выбираются для изучения и сравнения наиболее подходящие. После чего они адаптируются для условий своей собственной организации.

Основные этапы бенчмаркинга включают в себя:
1. Определение, анализ и детализация объекта бенчмаркинга. В качестве объекта могут быть выбраны процессы, услуги или продукты организации. На этом этапе важно понять, сколько ресурсов и усилий организация готова потратить на процесс бенчмаркинга — будет ли это разовое мероприятие или бенчмаркинг станет постоянной практикой организации.
2. Выявление и определение характеристик, по которым будет проводиться бенчмаркинг. Это могут быть важные потребительские свойства продукта или услуги, или параметры качества процесса.
3. Формирование команды бенчмаркинга. В команду лучше включать специалистов из различных подразделений организации, чтобы была возможность более широко и объективно оценить возможности как своих процессов (продуктов, услуг), так и процессов (продуктов, услуг) партнеров по бенчмаркингу.
4. Выбор партнеров по бенчмаркингу. В качестве партнеров могут выступать организации-лидеры, добившиеся успеха в реализации интересующих характеристик (определены на этапе 2). Партнером может быть одна организация или несколько. Если выполняется внутренний бенчмаркинг, то такими партнерами будут смежные подразделения, процессы или продукты предоставляемые самой организацией.
5. Сбор и анализ информации, необходимой для сравнения. Чтобы провести сравнение может потребоваться представить полученную информацию в том же виде, как она представляется внутри организации. Например, если сравниваются технические характеристики продукта, то у разных производителей набор этих характеристик может различаться. Характеристики необходимо будет привести к единой «базе».
6. Проведение оценки возможности организации в достижении необходимых характеристик в сравнении с партнером (или партнерами) по бенчмаркингу. Оценка может проводиться различными методами, которые позволяют оценить существующий «разрыв» между работой собственной организации и работой партнера по бенчмаркингу (например, с помощью GAP – анализа).
7. Определение возможных изменений существующей практики работы. Создается «видение» будущего состояния организации. Это видение должно быть основано на результатах адаптации процессов партнера по бенчмаркингу к условиям своей организации.
8. Разработка стратегических целей и планов по их реализации для достижения желаемого уровня характеристик. В зависимости от масштабности изменений планы могут затрагивать изменение процессов, системы управления, организационной системы, культуру исполнения работ и др. аспекты.
9. Реализация запланированных изменений и постоянный контроль за ходом преобразований в организации. Если необходимо, то выполняются корректировки планов.
10. После достижения установленных целей и реализации планов принимается решение о повторении цикла и реализации всех этапов бенчмаркинга для новых условий.

Market Analysis (Анализ рынка)

Анализ рынка (Market Analysis) — внешний анализ спроса, потребностей, конкуренции, дистрибуции, факторов окружающей среды, влияющих на спрос и поведение потребителей.
Описание этапов анализа рынка:
Этап 1. Определить цели и основные задачи анализа рынка.
Этап 2. Составить последовательный план маркетингового анализа рынка.
Этап 3. Определить возможные сроки и максимальный бюджет на анализ рынка.
Этап 4. Определить методы анализа рынка и источники получения информации по рынку.
Этап 5. Провести необходимые маркетинговые исследования рынка товаров или услуг.
Этап 6. Подготовить наглядный анализ всей собранной информацией с выводами.
Этап 7. Составить сводный отчет по анализу рынка.
Этап 8. По необходимости подготовить презентацию по проведенному маркетинговому анализу рынка.

Перед тем, как приступить к анализу рынка, необходимо определить предмет анализа (что будем анализировать?) и описать цели анализа.

Предмет анализа	Описание цели
Структура рынка	Проведение анализа емкости и конъюнктуры рынка, оценка рыночных тенденции
Товар компании	Проведение анализа развития рынка и рыночной доли товара компании в сегменте
Целевой сегмент	Проведение анализа привлекательности сегментов рынка с целью выбора целевого рынка
Потребитель	Проведение анализа спроса на рынке и анализа ключевых потребностей рынка, подробное изучение поведения, требований целевой аудитории к продукту
Цены	Проведение анализа ценового позиционирования конкурентов, действующей структуры цен в отрасли
Свободные ниши	Анализ сегментов рынка с целью поиска свободных рыночных ниш и новых источников продаж
Конкуренты	Проведение конкурентного анализа рынка с целью анализа конкурентных преимуществ товара и определения слабых стороны компании

5 видов исследования рынка:
1. Интервью — индивидуальная беседа по открытым вопросам для выявления гипотез.
2. Наблюдение — наблюдение за потребителем в привычной окружающей среде.
3. Фокус-группа — групповая дискуссия по открытым вопросам для выявления гипотез.
4. Опросы — количественный опрос по закрытому списку вопросов.
5. Полевые исследования — количественная проверка и оценка нескольких альтернатив.

Описание доступных источников информации о рынке:
Личные интервью. Поговорите лично с целевой аудиторией рынка, проведите 5-10 интервью. Включите в интервью пользователей разных торговых марок, потребителей и непотребителей рынка. Опросите тех, кто принимает решение и влияет на покупку и тех, кто пользуется купленным товаром. На такой опрос вы потратите меньше недели и получите много полезной информации
Форумы и соцсети. Используйте возможности интернет: возможность спросить потребителей на форумах, в социальных сетях, по электронной почте, связаться по Skype — все это снижает затраты на исследование
Ресурсы интернет. Изучите имеющуюся информацию в интернет по интересующей тематике, в том числе информацию о смежных рынках.
Сотрудники компаний. Опросите сотрудников компании о вопросах, которые вас интересуют, узнайте их мнение; отдельно побеседуйте с представителями отдела сбыта. Если вы проводите исследование рынка как независимая сторона — проведите интервью с руководителями компаний.
Личное наблюдение. Сами понаблюдайте за поведением покупателей в местах продаж: как он делает выбор, как выбирает.
Личный опыт. Попробуйте сами стать покупателем своего продукта и опишите свои впечатления.

Brainstorming

Метод мозгового штурма — оперативный метод решения проблемы на основе стимулирования творческой активности, при котором участникам обсуждения предлагают высказывать как можно большее количество вариантов решения, в том числе самых фантастичных. Затем из общего числа высказанных идей отбирают наиболее удачные, которые могут быть использованы на практике. Является методом экспертного оценивания.

Этапы и правила мозгового штурма
Правильно организованный мозговой штурм включает три обязательных этапа. Этапы отличаются организацией и правилами их проведения:
1 этап — Постановка проблемы. Предварительный этап. В начале этого этапа проблема должна быть четко сформулирована. Происходит отбор участников штурма, определение ведущего и распределение прочих ролей участников в зависимости от поставленной проблемы и выбранного способа проведения штурма.
2 этап — Генерация идей. Основной этап, от которого во многом зависит успех (см. ниже) всего мозгового штурма. Поэтому очень важно соблюдать правила для этого этапа:

• Главное — количество идей. Не делайте никаких ограничений.
• Полный запрет на критику и любую (в том числе положительную) оценку высказываемых идей, так как оценка отвлекает от основной задачи и сбивает творческий настрой.
• Необычные и даже абсурдные идеи приветствуются.
• Комбинируйте и улучшайте любые идеи.

3 этап — Группировка, отбор и оценка идей. Этот этап часто забывают, но именно он позволяет выделить наиболее ценные идеи и дать окончательный результат мозгового штурма. На этом этапе, в отличие от второго, оценка не ограничивается, а наоборот, приветствуется. Методы анализа и оценки идей могут быть очень разными. Успешность этого этапа напрямую зависит от того, насколько «одинаково» участники понимают критерии отбора и оценки идей.

В мозговом штурме участвует коллектив из нескольких специалистов и ведущий. Перед самим сеансом мозгового штурма ведущий производит четкую постановку задачи, подлежащей решению. В ходе мозгового штурма участники высказывают свои идеи, направленные на решение поставленной задачи, причём как логичные, так и абсурдные. Если в мозговом штурме принимают участие люди различных чинов или рангов, то рекомендуется заслушивать идеи в порядке возрастания ранжира, что позволяет исключить психологический фактор «согласия с начальством».

Business Capability Analysis

Бизнес-возможность — это способность или возможность для компании приносить пользу либо для клиентов, либо для клиентов или для акционеров. Бизнес-возможность состоит из трех основных компонентов: бизнес-процессов, людей и материальных активов. Набор бизнес-возможностей отражает способность бизнеса воздействовать или трансформировать то, что помогает достичь стратегической цели бизнеса.
Существует два вида возможностей: ориентированных на клиента и операционные возможности. Возможности, ориентированные на клиента, непосредственно добавляют ценность для клиентов. Операционные возможности добавляют ценность для акционеров, а не клиентов.

Бизнес-возможности являются чрезвычайно ценным механизмом перевода стратегии в действия.
Во-первых, они представляют собой дискретные способы отслеживания, как бизнес генерирует измеряемую ценность, поэтому мы можем связать выгоды и издержки с ними.
Во-вторых, возможности имеют иерархию. Они могут быть смоделированы с помощью отношения «родитель-потомок», что позволит нам понять их на разных уровнях детализации.
В-третьих, они могут управляться как активы. Мы можем думать о них, как о портфеле инвестиций и проактивно управлять ими улучшая целевой возврат на инвестиции (target ROI).
В-четвертых, бизнес-возможности позволяют создавать компаниям устойчивое конкурентное преимущество за счет комбинации уникальных людей, бизнес-процессов и материальных активов.

Business Model Canvas

Бизнес-модель «Канвас» — представляет собой способ визуализации бизнес-модели, которая по-умолчанию состоит из 9 структурных блоков:

• Ключевые партнеры;
• Ключевые виды деятельности;
• Ценностные предложения;
• Взаимоотношения с клиентами;
• Потребительские сегменты;
• Ключевые ресурсы;
• Каналы сбыта;
• Структура издержек;
• Потоки поступления доходов.

Иллюстрация структуры бизнес-модели «Канвас»

Как работает модель?

Три основные формы бизнеса:

Business Rules Analysis

Бизнес-правила являются условиями или ограничениями, которые определяют, как работает бизнес. Поэтому бизнес-правила должны быть проанализированы наряду с бизнес-требованиями.
Бизнес-правило — это конкретная, исполняемая и проверяемая директива, которая находится под контролем организации и которая служит для поддержания бизнес-политики.
Бизнес-правила состоят из различных компонентов: терминов, фактов и правил. Термины — это описание правил, факты опираются на термины, а правила строятся на фактах. Бизнес-правила представляют собой сочетание принципов и выводов, которые определяют, как мы делаем бизнес.

Бизнес-правила должны быть:

• Указаны в соответствующей терминологии, чтобы позволить Экспертам по предметным вопросам домена проверить правила.
• Документально независимыми от того, как они будут соблюдаться.
• Изложенными на «атомном уровне» и в декларативной форме.
• Отделенными от процессов, которые поддерживаются или ограничиваются правилом.
• Обслуживается в порядке, который позволяет организации контролировать и адаптировать правила, как изменение бизнес-политик.

Бизнес-аналитикам может потребоваться выявить и проанализировать бизнес-правила. Однако, существует специальная роль бизнес-аналитика, которая посвящена управлению и анализу бизнес-правил: «аналитик бизнес-правил».
Аналитик бизнес-правил выполняет следующие функции:
1) Анализ, проектирование и выполнение бизнес-правил, которые управляют организацией и ее деятельностью;
2) Понимание, как бизнес-правила определяются, документируются и управляются;
3) Карта бизнес-правил и процессы, управляемые бизнес-правилами;
4) Обновление бизнес-правил в соответствии с организационными изменениями;
5) Проверка, какие бизнес-правила будут затронуты при ограниченных организационных изменениях;
6) Управление рисками, которые могут помешать реализации бизнес-правил.

Collaborative Game

Совместные игры относятся к структурированным методам, включают в себя правила, позволяющие участникам сосредоточить внимание на конкретной цели. Игры используются для того, чтобы помочь участникам поделиться своими знаниями и опытом по некоторой теме, выявить скрытые упущения, а также выявить знания, которые не могут появиться в ходе обычного взаимодействия. Обмен опытом в совместной игре поощряет людей с различными точками зрения работать вместе, чтобы лучше понять проблему и описать общую модель для ее решения.
Совместным играм дополнительную пользу приносит нейтральный участник (посредник), который помогает участникам понять правила игры и помогает обеспечить их соблюдение. Работа посредника состоит в том, чтобы сохранить игру и двигаться вперед, чтобы гарантировать, что все участники играют необходимые роли.
Совместные игры также обычно включают сильные визуальные или тактильные элементы. Такие действия, как перемещение заметок, написание на доске или рисование стимулируют творческое мышление и помогают взглянуть со стороны на обсуждаемые проблемы/темы.
12 совместных игр (agile инструментарий)

• Broken Skype
• Crazy Chat
• Collaborative Origami
• Listening Game
• Movers & Shapers
• Human Knot
• 123 go
• Columbian Hypnotist
• Non Musical Chairs
• Yes, and
• Magic Stick
• Singing, Clapping, Numbers

Data Dictionary

Словарь данных — аналитическая модель, описывающая структуры данных и атрибуты системы.
Словарь данных определяет состав структур данных, а также их значение, тип данных, длину, формат и разрешенные значения элементов данных, из которых состоят эти структуры. Серийные средства моделирования данных часто включают компонент-словарь данных. Во многих случаях словарь данных лучше хранить как отдельный артефакт, не внедряя его в спецификацию требований к ПО. Это повышает возможности повторного использования в других проектах.
Словарь данных (data dictionary) представляет собой набор подробной информации об используемых в приложении сущностях данных. Сбор информации о составе, типах данных, разрешенных значениях и т. п. в виде единого ресурса, служащего для определения критериев проверки данных, помогает разработчикам правильно писать программы и избавляет от проблем с интеграцией. Словарь данных является дополнением к словарю терминов проекта, который определяет термины предметной области или бизнес-термины приложения, сокращения и акронимы. Мы рекомендуем поддерживать словарь данных и словарь терминов отдельно.
Во время анализа требований информация словаря данных представляет элементы и структуры данных предметной области. Эта информация попадает в дизайн в форме схем баз данных, таблиц и атрибутов, что в конечном итоге определяет имена переменных в программах. Время, потраченное на создание словаря данных, будет более чем компенсировано временем, которые вы сэкономите, избежав ошибок по причине того, что участники проекта по-разному понимают ключевые данные. Если вы регулярно обновляете словарь данных, он останется ценным средством и при обслуживании системы, и при разработке схожих систем. В противном случае он может вводить в заблуждение, предоставляя устаревшую информацию, и члены команды перестают доверять ему. Ведение словаря данных — серьезный вклад в повышение качества. Определения данных часто повторно используются в других приложениях, особенно в одном семействе продуктов. Использование единообразных определений данных в компании снижает вероятность возникновения ошибок интеграции и интерфейса. По возможности используйте существующие стандартные определения данных из хранилища корпоративных знаний, используя менее масштабный набор определений в проекте для восполнения пробелов.

Data Flow Diagram

Диаграмма потока данных — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Диаграмма потоков данных (data flow diagram, DFD) — основной инструмент структурного анализа. Она позволяет определять процессы преобразования системы, совокупность (хранилище) данных или материалов, которыми система управляет, и потоки данных или материалов между процессами, хранилищами и внешним миром.
При моделировании потоков данных для системного анализа используется прием разложения функций, при котором сложные проблемы раскладываются на составляющие, размещаемые по нарастающей по уровням детализации. Этот подход отлично подходит для систем обработки транзакций и других приложений с большой нагрузкой на функциональность. Добавление элементов управления потоками позволило применять диаграммы потоков данных для моделирования систем реального времени.

Некоторые правила для рисования диаграмм потока данных:

• Процессы взаимодействуют через хранилища данных, а не посредством прямых потоков от одного процесса к другому. Точно так же данные не могут передаваться напрямую из одного хранилища в другое, они должны пройти через процесс (кружок).
• Не пытайтесь передать последовательность этапов процесса с помощью диаграммы потоков данных.
• Называйте процессы как короткое действие: глагол + объект (например, «Создать инвентарный отчет»). Используйте названия, понятные клиентам и употребляемые в деловой или предметной области.
• Присваивайте процессам уникальные номера согласно иерархии. На уровне 0 диаграммы, пронумеруйте каждый процесс целыми числами. Если вы создадите дочернюю диаграмму потоков данных для процесса 3, пронумеруйте процессы в ней как 3.1, 3.2 и т.д.
• Не показывайте на одной диаграмме более 8-10 процессов, в противном случае ее будет трудно рисовать, изменять и понимать. Если у вас больше десяти процессов, создайте еще один уровень абстракции,сгруппировав связанные процессы в процесс более высокого уровня.
• Кружки с только входящими или только исходящими потоками вызывают подозрение. Корректный процесс, изображаемый кружком на диаграмме потоков данных, как правило, отличается наличием и входящих, и исходящих потоков.

Пример Data Flow Diagram (DFD):

Data Modeling

Моделирование данных осуществляется с целью обеспечения разработчика информационной системы концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены СУБД.
Наиболее распространенным средством моделирования данных являются диаграммы сущность-связь — ERD (Entity Relationship Diagram). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).

На каждом этапе проектирования информационной модели будущей системы разрабатывается соответствующая модель данных:

• Логическая модель (концептуальная) — СУБД-независимая модель, отображающая абстрактный взгляд на данные, представленные и поименованные так, как они могут выглядеть и называться в реальном мире, например: «Постоянный клиент», «Отдел» и т.д.;
• Даталогическая модель — СУБД-ориентированная модель, представляющая реляционную модель базы данных в конкретной СУБД, включающей полный список отношений и их атрибутов с указанием первичного ключа;
• Физическая модель — отображение системного каталога; описание всех типов файлов базы данных в зависимости от выбранной СУБД.

Процесс разработки модели данных выбранной предметной области с использованием Case-средства (например, All Fusion Data Modeler) сводится к последовательности действий, которая называется прямым проектированием (Forward Engineering):
1) Создание логической модели — описание всех выделенных в процессе обследования предметной области сущностей, их атрибутов и связей между ними;
2) Переход на даталогический уровень;
3) Осуществление генерации системного каталога СУБД или соответствующего SQL-скрипта.

Процесс может быть и обратным (Reverse Engineering) — создание модели данных на основе существующей схемы базы данных в определенной СУБД.

Decision Analysis

Анализ принятия решений — Подход к принятию решений, который изучает и моделирует возможные последствия различных решений. Такой тип анализа помогает в принятии оптимального решения в условиях неопределенности.

Цель
Для поддержки принятия решений при работе с составными, сложными или неопределенными ситуациями. Анализ решений позволяет бизнес-аналитику изучить и смоделировать последствия различных решений. Конечной целью данного инструмента является разработка обоснованного решения. Оно делается с помощью математического моделирования для оценки возможных результатов. Во многих случаях, анализ решения включает в себя сложные модели, созданные с использованием современных программных приложений.

Описание
Анализ решений — это подход к принятию решений, который исследует и моделирует возможные последствия различных решений. Анализ решений способствует принятию оптимального решения в условиях неопределенности. Неопределенность может существовать из-за неизвестных факторов, которые имеют отношение к проблеме решения, потому что существует слишком много возможных взаимосвязанных факторов для рассмотрения, а также из-за противоречивых взглядов на ситуацию или
из-за компромиссов между различными доступными вариантами.

Эффективный анализ решений требует, чтобы аналитик понимал:
— Ценности, цели и задачи, которые актуальны для решения проблемы;
— Характер решения, которое должно быть выполнено;
— Области неопределенности, которые влияют на решение;
— И последствия каждого из возможных решений.
Задачи в Области знаний Анализа предприятия описывают многое из того, что требуется для эффективного структурирования решения проблемы. Этот метод описывает конкретные инструменты, которые используются для анализа результатов, неопределенности и компромиссов. Анализ решений может включать в себя использование сложных моделей и специализированных программных приложений.

Элементы анализа решений
1. Результаты
Анализ решений обычно требует, чтобы бизнес-аналитик использовал некоторые формы математической модели для оценки возможных результатов.

Финансовый анализ
Финансовые модели оценивают рыночную стоимость активов организации, например, оценка нового решения для бизнеса или его приобретение.
Часто используемые методы финансовой оценки включают в себя:
— Дисконтированный денежный поток (DCF): будущая стоимость по конкретным данным
— Чистая приведенная стоимость (NPV): будущий вид затрат и выгод, преобразованный в сегодняшнюю стоимость
— Внутренняя норма доходности (IRR): проценты (или дисконт), при которой чистая приведенная стоимость равна нулю
— Средняя норма рентабельности (ARR): оценка доходности инвестиций
— Срок окупаемости (PP): количество времени, требующееся для окупания инвестиций
— Анализ затрат и выгод (CBA): количественная оценка затрат и выгод по предлагаемому решению

Нефинансовые результаты
Не все результаты могут быть выражены в денежном выражении. Тем не менее, эффективный анализ решения по-прежнему требует, чтобы результаты были сопоставимыми. В некоторых случаях, будет существовать показатель, который для этого применяется (количество дефектов на тысячу человек, процент безотказной работы, оценка удовлетворенности клиентов). Когда не существует показатель, должны быть определены возможные результаты с помощью сравнительного скоринга.

2. Неопределенность
Неопределенность становится актуальным для решения проблемы, когда невозможно узнать какой наступит результат. Это может быть из-за отсутствия информации, либо потому, что результат зависит от того, как другие реагируют. Общий метод борьбы с неопределенностью в решении проблем является расчет ожидаемой стоимости результатов. Расчет включает в себя оценку вероятности происхождения каждого события в процентах и их умножения на численное значение результата, связанного с этим процентом.
Дерево решений — это метод оценки предпочтительного результата, где может существовать несколько источников неопределенности.

3. Компромиссы
Компромиссы становятся актуальными, когда решение проблемы включает в себя несколько, возможно, противоречивые задачи. Недостаточно просто найти максимальное значение одной переменной (например, финансовая выгода для организации), потому что более чем одна цель является актуальной. При принятии компромиссных решений, эффективные методы включают в себя:
— Исключение доминирующих альтернатив. Доминирующая альтернатива — это любой параметр, который явно уступает некоторым другим параметрам. Если параметр равен или хуже, чем некоторые другие параметры по рейтингу отношения к целям, то другой параметр может доминировать в нем. В некоторых случаях параметр также может доминировать, если он предлагает небольшие преимущества, но имеет существенные недостатки.
— Ранжирование целей, аналогичных по масштабам. Один из способов преобразования рейтинга аналогичного масштаба — это пропорциональный скоринг. Используя этот метод, лучшим результатам присваивается рейтинг 100, худшим — 0, а все остальные результаты получают рейтинг, основанный на том, где они находятся между двумя этими баллами. Оценка может быть назначена каждому результату как лучшая альтернатива, назначенная с помощью дерева решений, если результатам затем присваиваются веса, в зависимости от их относительной важности.

Особенности использования
1. Преимущества
— Анализ решений предоставляет эффективный метод, чтобы определить ожидаемое значение альтернативного сценария для организации.
— Использование последовательных методов финансового обоснования во всех бизнес-кейсах предоставляет лицам, принимающим решения, количественные показатели, чтобы принять инвестиционное решение по проекту.
— Анализ решений может заставить заинтересованные стороны честно оценить важность, которую они придают различным альтернативам.
2. Недостатки
— Анализ решения требует специальных знаний и навыков, в том числе математические знания, понимание вероятности и подобных концепций.
— Результаты анализа решений можно рассматривать как более определенные, чем они есть на самом деле, если лица принимающие решение, не понимают ограничения и предположения модели, которые стоят за ней.
— Лица, принимающие решения, могут быть не заинтересованы в пересмотре решений, даже когда больше информации доступно по областям неопределенности, которые могут изменить оптимальное решение.

Document Analysis

Анализ документов — Метод выявления требований к существующей системе путем изучения доступной информации, документов и определения ее релевантности.
Цель
Анализ документа — является средством для выявления требований, посредством изучения имеющейся документации о существующих и сопоставимых решениях и определения соответствующей информации.

Описание
Анализ документа может включать анализ бизнес-планов, маркетинговые исследования, договоров, заявок на предложения, инструкций по работе, служебных записок, существующих руководящих принципов, процедур, учебных пособий, литературы по конкурирующим продуктам, опубликованные сравнительные обзоры продукции, отчетов о проблемах, журналов предложений клиентов, спецификаций существующих систем. Выявление и принятие во внимание всех возможных источников требований приведет к повышению охвата требований, предполагая, что документация находится в актуальном состоянии. Анализ документа используется, если цель состоит в том, чтобы собрать информацию о существующих решениях, в том числе бизнес-правилах, сущностях и атрибутах, которые должны быть включены в новое решение или должны быть обновлены для текущего решения. Этот метод также применяется в ситуациях, когда эксперта по предметным вопросам по существующим решениям больше нет в организации или он не будет доступен в течение всего времени процесса выявления требований.

Элементы инструмента «Анализ документов»
1. Подготовка
Оцените, какие из существующих систем и бизнес-документации являются актуальными, доступными и необходимо для изучения.
2. Рассмотрение документов
— Изучите материал и определите соответствующие сведения бизнеса.
— Задокументируйте бизнес-информацию, а также вопросы для последующей деятельности с экспертами в предметной области.
3. Подведение итогов
— Рассмотрите и подтвердите с экспертами в предметной области выбранные детали.
— Организуйте информацию в формате требований.
— Получите ответы на дополнительные вопросы.

Особенности использования
1. Преимущества
— Не начинаем с чистого листа.
— Используем существующие материалы для обнаружения и/или подтверждения требований.
— Соответствует перекрестной проверки требований из других техник сбора информации, таких как интервью, работы-слежки, опросы или фокус-группы.
2. Недостатки
— Ограничено точкой зрения «как есть».
— Существующая документация может не быть современной или утвержденной.
— Данный процесс может быть трудоемким или даже утомительным процессом, чтобы найти соответствующую информацию.

Estimation

Цель метода проведения оценки
Методы оценки прогнозируют стоимость и усилия, которые вовлечены в проведение курса действий.

Описание
Методы оценки используются для углубления понимания возможного диапазона стоимости и усилий, связанных с любой инициативы. Оценка используется при невозможности определения точной стоимости. Оценка не может и не устраняет неопределенность; напротив, цель заключается в том, чтобы получить разумную оценку вероятной стоимости или усилий. Чем меньше информации, которая доступна для оценщика, тем шире будет диапазон неопределенности. Оценки должны быть пересмотрены по мере поступления новой информации. Многие методы оценки опираются на исторические записи показателей от организации, чтобы откалибровать их с фактическими показателями. Оценки (Estimates) должны включать оценку диапазона неопределенности, связанной с оценкой (estimate).

Элементы метода оценки
1. Аналогичная оценка
Используйте подобный проект в качестве основы для разработки оценок для текущего проекта. Он используется, когда мало что известно. Аналогичные оценки часто используются для разработки оценки «грубого порядка величины» (ROM), и также известен как оценка «сверху- вниз». Обычно это делается в начале проекта или фаз проекта и более детальные оценки следуют как становится больше известно.
2. Параметрическая оценка
Использование параметров, умноженных на количество часов. Чтобы параметрическая оценка была полезной, достаточно, чтобы история должна была быть доступна для использования в качестве основы для сравнения. При этом типе оценки, бизнес-аналитик сделал достаточно работы для того, чтобы определить какие параметры будут использоваться и сколько их там будет. Например, бизнес-аналитик определил, что будет разработано десять вариантов использования. Бизнес-аналитик также имеет историю, которая указывает для каждого варианта использования общее количество часов, которые будут потрачены, в этом случае будет 20 часов. Используя эту технику, бизнес-аналитик может умножить 10 на 20, чтобы получить итоговое значение, или 200 часов.
Ряд четко определенных методов параметрической оценки существует для разработки программного обеспечения, таких как COCOMO II, подсчет функциональных точек, точки вариантов использования и исторические баллы.
3. Оценка
С помощью этой техники, бизнес-аналитик собирает конечные результаты деятельности, задач и оценок от всех заинтересованных сторон и обобщает их, чтобы получить общие для всех активностей и задач. Потому что, как правило, легче оценить мелкие элементы, чем более крупные элементы, оценки снизу-вверх могут производить наиболее точные и обоснованные оценки.
4. Набегающая волна
Это метод привлечения уточнения оценок. Детали оценки для деятельности в текущей итерации или приращение и предоставление аналогичной оценки за весь объем работ. Как в конце итерационных подходов, оценки могут быть сделаны для следующей итерации и первоначальная оценка для всех активностей уточняется.
5. Трех-точечная оценка
Использует сценарии для:
— Самая оптимистичная оценка или самый лучший сценарий
— Самая пессимистичная оценка или самый худший сценарий
— Наиболее вероятная оценка
Обратите внимание, что наиболее вероятная оценка это не среднее между самым лучшим и наихудшим сценариями. Она требует глубокого знания ситуации. При правильных обстоятельствах, лучший сценарий может также быть наиболее вероятным.
6. Исторический Анализ
Использует историю в качестве основы для оценки. Метод похож на аналогичную оценку, но используется не только для оценки «сверху-вниз», но также и для детализации задач. Исторические оценки требуют предварительных записей проекта, которые поддерживаются формально в репозитории проекта или неформально в индивидуальной проектной документации.
7. Экспертное Заключение
Оценка опирается на опыт тех, кто выполнял работу в прошлом. Эти эксперты могут быть внутренними или внешними по отношению к проектной команде или организации.
8. Delphi Оценка
Эта техника использует комбинацию экспертной оценки и истории. Есть несколько вариантов этого процесса, но все они включают в себя индивидуальные оценки, обмен оценками с экспертами и имеют несколько раундов пока консенсус не будет достигнут. Используется среднее арифметическое трех оценок. Иногда, за среднее принимается взвешенное по оптимистическому, пессимистическому и умноженное на 4 наиболее вероятное, деленное на 6, чтобы получить среднее.

Особенности использования
1. Преимущества
Оценки могут помочь заинтересованным сторонам принимать более обоснованные решения на основе более четкого понимания вероятных исходов от инициативы.
2. Недостатки
Заинтересованные стороны часто относятся к оценкам как к обязательствам, и ожидают, что как только дается оценка команда разработки будет придерживаться времени и стоимости оценки. Оценки часто сознательно и бессознательно меняются, чтобы соответствовать желаниям влиятельных заинтересованных сторон, поскольку оценщики и другие озабочены тем, что более высокие оценки приведут к тому, что проект будет отклонен или будет рассматриваться как демонстрация отсутствия обязательств.

Focus Group

Цель
Фокус-группа — это средство выявления идей и взглядов о конкретном продукте, услуге или возможности в среде интерактивной группе. Участники делятся своими впечатлениями, предпочтениями и потребностями, под руководством модератора.

Описание
Фокус-группа состоит из предварительно отобранных лиц, целью которых является обсуждение и комментирование по теме. Это возможность для людей, чтобы поделиться своими точками зрения и обсудить их в группе. Это может привести участников к решению заново оценить свои точки зрения на фоне чужого опыта. Обученный модератор управляет административной предварительной работой, способствует проведению сессии и выдает отчет. Наблюдатели могут записывать или контролировать фокус-группы, но не участвовать. Так как эта техника выявления считается одной из форм качественного исследования, результаты сессии анализируются и регистрируются как темы и точки зрения, а не как численные результаты. Отчет также может содержать в себе избранные цитаты в поддержку темы. Традиционная фокус-группа собирается в одной комнате. Онлайн фокус-группа позволяет членам находиться удаленно, участвуя через сетевые соединения. Каждый подход имеет свои плюсы и минусы с точки зрения логистики и расходов.
Фокус-группа может быть использована в течение любого состояния жизненного цикла: исследовательский, в стадии разработки, готовый к запуску или стадии производства. Если темой группы является продукт стадии разработки, то идеи группы анализируются во взаимосвязи с заявленными требованиями. Это может привести к обновлению существующих требований или раскрытию новых требований. Если темой является законченный продукт, который готов к реализации, доклад группы может влиять на то, как позиционировать товар на рынке. Если темой является продукт стадии производства, то доклад группы могут дать указания по изменениям следующих версий требований. Фокус-группа может также служить средством оценки удовлетворенности клиентов с продуктом или услугой. Работа фокус-группы может быть похожа на то, что делается в сессии мозгового штурма. Одним из отличий является то, что фокус-группа, как правило, является более структурированной. Другое отличие состоит в том, что целью мозгового штурма является активный поиск расширенных, творческих и даже преувеличенных идей.

Элементы метода фокус-группы
1. Подготовка
Отбор Участников
Фокус-группы обычно имеют 6-12 участников. Отбор участников может быть необходим, чтобы пригласить дополнительных лиц или чтобы разрешить тем, кто не присутствовал на сессии из-за конфликтов, чрезвычайных обстоятельств или по другим причинам, обсудить тему. Если многие люди должны участвовать, то отбор участников может быть необходим, чтобы запустить более чем одну фокус-группу.
Тема фокус-группы должна будет влиять на отбор участников. Если темой является новый продукт, вполне вероятно, что должны быть включены в группу существующие пользователи (эксперты и новички). Существуют плюсы и минусы, которые необходимо учитывать при использовании однородного состава против неоднородного состава.
— Однородные — люди со схожими характеристиками. Внимание: различиями во взглядах не будут делиться. Возможное решение: проводить отдельные сеансы для различных однородных групп, чтобы собирать различные точки зрения.
— Неоднородные — люди с разнообразным опытом и/или взглядами на будущее. Предупреждение: люди могут подвергать себя само-цензуре, если им не комфортно с другими предпосылками или мнениями, что приводит к снижению собираемых данных.

Назначить Модератора и Регистратора
Модератор (ведущий) должен быть опытным в организации групп. Типичные навыки включают в себя следующие возможности:
— поощрение обсуждения
— задавать открытые вопросы (те, которые требуют или поощряют расширенный ответ)
— облегчать взаимодействие между членами группы
— вовлекать всех членов
— поддерживать фокусирование сессии (на том, чему она посвящена)
— оставаться нейтральным
— быть легко приспосабливающимся и гибким
Создать руководство по дискуссиям (обсуждениям)
Руководство по дискуссиям включает в себя цели/задачи сессии и пять-шесть открытых вопроса.
Запасное место и услуги
Выберите место для сессии. Организуйте техническую поддержку для расшифровки дискуссии на сессии и, если используется, аудио/видео-съемочное оборудование.

2. Запустите сессию фокус-группы
Модератор руководит обсуждением в группе, следует конкретным вопросам по заранее спланированному сценарию и обеспечивает достижению поставленных целей. Однако, групповая дискуссия должна обозначаться как свободно текущая и относительно неструктурированная для участников. Сеанс, как правило, длится от 1 до 2 часов. Регистратор записывает комментарии группы.
3. Создание отчета
Модератор анализирует и документирует соглашения и разногласия участников встречи, и синтезирует их в темы.

Особенности использования
1. Преимущества
— Возможность извлекать данные из группы людей в течение одной сессии экономит время и стоимость по сравнению с проведением индивидуальных интервью с тем же количеством людей.
— Эффективен для изучения отношения людей, опыта и желаний.
— Активное обсуждение и возможность задать другие вопросы создает атмосферу, в которой участники могут рассмотреть их личное видение в отношении других аспектов.
2. Недостатки
— В групповых установках, участники могут быть озабочены вопросами доверия или могут не захотеть обсуждать деликатные или личные темы.
— Собранные данные (что люди говорят) могут не совпадать с тем, как на самом деле ведут себя люди.
— Если группа слишком однородная, то их ответы могут не представлять полный набор требований.
— Требуется опытный модератор для того, чтобы управлять групповыми дискуссиями и обсуждениями.
— Планирование группы на некоторую дату и время может быть сложным.
— Если целью фокус-группы является выявление идей по новому или изменяющемуся продукту, то фокус-группа не является эффективным способом оценки юзабилити.

Functional Decomposition

Декомпозиция (Decomposition) — Техника, при которой проблема разбивается на компоненты для облегчения последующего анализа и понимания этих компонентов.

Цель функциональной декомпозиции
Разложение процессов, функциональных областей или конечных результатов (целевых результатов) на составные части для дальнейшего анализа каждой части по отдельности.

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

Элементы функциональной декомпозиции
В процессе выполнения функциональной декомпозиции выявляются высокоуровневые функции организации или решения (solution), а затем эти функции разбиваются на более мелкие части, такие как суб-процессы, виды деятельности, суб-функции и т.д.
При разложении организационных функций, модели функциональной декомпозиции начинаются с верхнеуровневых функций, которые соответствуют организационному юниту. Далее функции детализируются на суб-функции, представляющие собой процессы, которые осуществляются внутри этого юнита. Данный процесс направлен сверху вниз. Результатом функциональной декомпозиции является иерархическая диаграмма функций, диаграмма в виде дерева функций или списка пронумерованных функций, включающих в себя вложенные функции.
В управлении проектами существует аналогичный процесс, который носит название Структура декомпозиции работ (WBS, Work Breakdown Structure). Проект разбивается на фазы проекта, пакеты работ и конечные результаты.
Структура декомпозиции работ (WBS) является иерархической декомпозицией целей проекта на ориентированные на результат задачи, выполняемые проектной группой для достижения общих целей проекта. WBS образует основу всей деятельности по планированию проекта. WBS делит объем проектных работ на более мелкие, управляемые пакеты работ для сохранения лучшего контроля над операциями проекта.

Пример диаграммы функциональной декомпозиции
FDD (Functional Decomposition Diagram) — диаграмма функциональной декомпозиции

Glossary

Цель глоссария
Глоссарий определяет ключевые термины и данные, относящиеся к предметной области.

Описание глоссария
Глоссарий используется для официального выявления и определения всей терминологии, которая используется организацией или подразделением. Например, подразделение может различать клиента (client) и клиента (customer), где клиент (client) — это сторона, с которой бизнес имеет законную силу соглашения о предоставлении профессиональных услуг, в то время как клиент (customer) может иметь более непринужденные, на основе транзакций, отношения с бизнесом. В медицинской организации, такой как больница, термин пациент может использоваться, вместе с его уникальным определением, а не как клиент (client) или клиент (customer).

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

Interface Analysis

Цель анализа интерфейсов
Идентифицировать интерфейсы между решениями и/или компонентами решения, а также определить требования, которые будут описывать их взаимодействие.

Описание анализа интерфейсов
Интерфейс — это связь между двумя компонентами, канал передачи информации между двумя людьми, человеком и системой или между двумя системами. Большинство ПО (программ) требуют один или более интерфейсов. Различают следующие типы интерфейсов:
— Пользовательские интерфейсы, включая пользователей, непосредственно взаимодействующих с системой, а также отчеты, предоставленные пользователям;
— Интерфейсы для внешних приложений (входящие и исходящие);
— Интерфейсы для внешних устройств (входящие и исходящие).
Анализ интерфейса помогает уточнить границы взаимодействия приложений. Анализ интерфейса выделяет какое приложение обеспечивает определенную функциональность в соответствии с потребностями входных и выходных данных. Основой для успешной настройки взаимодействия необходимо четко и тщательно отделить требования для каждого приложения и затем описать требования к соединяющим интерфейсам.
Идентификация, какие интерфейсы необходимы для обслуживания приложения создает условия для выявления самых разнообразных требований. Раннее выявление интерфейсов раскрывает и подтверждает взаимодействие заинтересованных сторон, а также служит основой для последующего анализа детальных требований по каждому интерфейсу. Анализ интерфейса, безусловно, необходимо для программных решений или компонентов решений, но также может быть полезным для непрограммных решений, например, при определении требований к результатам, которые будут произведены третьими лицами.

Элементы анализа интерфейсов
1. Подготовка к этапу идентификации интерфеса
Обзор существующей документации на предмет наличия признаков требований к интерфейсам. Например, контекстная диаграмма может обеспечить эффективную визуализацию для входящих и исходящих интерфейсов для внешних сторон.
2. Сопровождение идентификации интерфейса
Для каждой заинтересованной стороны или системы, которая взаимодействует с системой, определить какие интерфейсы необходимы.
Для каждого интерфейса:
— Описать назначение интерфейса.
— Оценить, какой тип интерфейса может быть целесообразен в каждом конкретном случае: интерфейс пользователя, интерфейс система-система и/или интерфейсы к внешним аппаратным устройствам.
— Выявить высокоуровневые детали по интерфейсу, в зависимости от его типа.
Для интерфейса, в котором пользователь непосредственно взаимодействует с приложением, необходимо пользоваться техникой Создания прототипов.
Для интерфейса приложение-приложение или интерфейса к внешним аппаратным устройствам, кратко изложить содержание и связанные с ним события.
3. Описать интерфейсы
Требования к интерфейсу должны быть сфокусированы главным образом на описании входов и выходов интерфейса, должны быть описаны некоторые правила проверки, которые регулируют эти входы и выходы, а также требуется описать события, которые могут инициировать взаимодействия. Там может быть большое количество возможных типов взаимодействий, несмотря на это, необходимо описать все возможные взаимодействия без исключений.

Interview

Interview (BABOK v 2.0)

Цель интервью
Интервью — это системный подход, предназначенный для выявление информации от человека или группы людей в неформальной или официальной обстановке, путем общения с интервьюируемым, задавания релевантных вопросов и документирования ответов.

Описание интервью
В ходе интервью, интервьюер официально или неформально задает напрямую вопросы заинтересованной стороне для того, чтобы получить ответы, которые будут использоваться для создания официальных требований. Интервью один-на-один, как правило, является наиболее распространенным. В групповом интервью (более одного опрашиваемого) интервьюер должен быть осторожным, чтобы получить ответы от всех участников.

С целью выработки требований интервью бывает двух основных типов:
— Структурированное интервью: интервьюер имеет заранее определенный набор вопросов и ищет ответы.
— Неструктурированное интервью: интервьюер и интервьюируемый без каких-либо заранее определенных вопросов обсуждают в открытом формате заданную тему.

Успешное интервьюирование зависит от нескольких факторов, которые включают в себя следующие пункты (но не ограничиваются ими):
— Уровень понимания интервьюером прикладной области;
— Опыт проведения интервью интервьюера;
— Умение интервьюера документировать обсуждение (протоколирование интервью);
— Готовность интервьюируемого предоставлять релевантную информацию;
— Степень ясности в уме интервьюируемого о том, что бизнес хочет получить от целевой системы;
— Контакт интервьюера с интервьюируемым.

Элементы интервью
1. Подготовка к интервью
Определите фокус или цель интервью перед тем как продолжить подготовку.

Идентификация (выявление) потенциальных интервьюируемых
Бизнес-аналитик рассматривает следующие вопросы при определении, кого нужно опросить:
— Кто владеет наиболее достоверной и наиболее актуальной информацией по теме интервью?
— Какова их доля участия в текущей инициативе?
— Какова относительная важность информации, находящейся в распоряжении одного человека по отношению к информации другого человека? Эта информация полезна при анализе противоречивой информации, полученной из разных интервью?

Разработка интервью
Интервьюеру может потребоваться нестандартная разработка интервью для каждого идентифицированного интервьюируемого. На разработку интервью влияет желаемый результат опроса. Также принимаются в расчет следующие факторы:

• Формат интервью — структурированное по сравнению с неструктурированным интервью. Для структурированного интервью характерны следующие типы вопросов:
  • Закрытые вопросы предполагают однозначный ответ (например, сообщение точной даты, названия, указания на количество чего-либо) или ответ «да» или «нет».Это гипотезы, уже готовые предположения, которые нужно лишь подтвердить или опровергнуть. Лучше гипотезы заменить открытыми вопросами, которые позволяют партнеру дать свою версию. Пример: Когда истекает срок сдачи проекта? Сколько человек у вас в группе? Ты хочешь отказаться от работы?
  • Открытые вопросы должны быть сформулированы так, чтобы партнеру хотелось на них отвечать. Эти вопросы предполагают развернутый ответ. Начинайте вопрос со слов: Что? Как? Почему? Каким образом? При каких условиях? Пример: На какие факты(условия, преимущества) мы должны обратить внимание? Что следует предпринять, чтобы изменить ситуацию? Какой результат был бы приемлемым для вас?
• Организация вопросов: используйте вопросы в логическом порядке или в порядке приоритета/их значения. Например, вопросы могут задаваться от общих к частным, могут быть вопросы привязаны ко времени, от детальных вопросов к суммирующим вопросам и т.д. Фактическая организация базируется на таких факторах, как уровень знаний интервьюируемого и предмета интервью. Цель в том, чтобы следовать логическому порядку, а не прыгать от одного вопроса к другому в ходе интервью.
• Расположение участников: интервью может проводиться при непосредственной встрече участников, по телефону, может организовываться в формате веб-конференции или с помощью других удаленных видов связи.
• Время для интервью и площадка должны быть удобными для интервьюируемого.
• Определите нужен ли вам секретарь (тот, кто будет составлять протокол интервью) и если да, то включите этого человека в процесс планирования. Определите, необходимо ли вести запись интервью. Если запись необходима, то обсудите цели записи и ее дальнейшее использование с интервьюируемым.

Установление контакта с потенциальными интервьюируемыми
Интервьюер устанавливает контакт с выбранными интервьюируемыми и объясняет им почему необходима их помощь. Цель установления контакта заключается в разъяснении целей интервью потенциальному интервьюируемому.

2. Проведение интервью

• Открытие интервью. Интервьюер обговаривает цель интервью, обозначает некоторые начальные проблемы, поднятые интервьюируемым, а также объясняет, что замечания будут приняты и опубликованы для интервьируемого после интервью.
• В ходе интервью:
  • Интервьюер сохраняет фокус на установленных целях и предварительно определенных вопросах.
  • Все проблемы, затронутые интервьюируемым, рассматриваются в ходе интервью или документируются для последующего отслеживания (follow-up) после интервью или разбираются в последующих интервью.
  • Интервьюером используется практика активного слушания.
• Завершение интервью. Интервьюер спрашивает интервьюируемого о возможных упущенных деталях, областях, которые были пропущены на сессии. В завершении, интервьюер подытоживает сессию, напоминает интервьюируемому о предстоящем процессе обработки информации интервью и благодарит собеседника за потраченное его время.

3. Отслеживание и подтверждение результатов интервью
После того, как интервью завершилось, интервьюер организует информацию и рассылку примечаний к интервью для ознакомления. Документирование дискуссий для ознакомления позволяет интервьюируемому видеть всю информацию в контексте. Данный обзор может указывать на пункты, в которых были допущены ошибки или которые были пропущены, потому что интервьюер или секретарь пропустили их при документировании, или потому, что интервьюер или секретарь неправильно их задокументировал, или потому, что интервьюируемый пропустил их при обсуждении. Этот обзор не ставит своей целью проверить требования или провести согласование требований. Пост-обзор служит проверкой правильности документирования интервью.

Правила проведения интервью (bankiram.pro)

Данные правила помогут успешно провести интервью для сбора практически любой информации (описание бизнес-процессов, переговоры, получение экспертных оценок и опыта, исследование предметной области и т.п.).
1. Тщательная подготовка к интервью
Рекомендуется собрать и изучить всю возможную информацию о теме интервью и собеседнике. Заранее ознакомиться со всеми специфическими терминами, подготовить возможные дополнительные вопросы, примеры, комментарии и т.п.
2. Постарайтесь сделать так, чтобы вышестоящий руководитель вашего собеседника организовал интервью
Важно, чтобы руководитель того сотрудника, с кем вы собираетесь проводить интервью, объяснил ему, что это важно. В этом случае ваш собеседник с меньшей вероятностью станет игнорировать какие-то вопросы и предоставлять неполную информацию.
3. Слушайте, а не командуйте
В большинстве интервью вы задаете вопросы, на которые не отвечают просто да или нет. Вам необходимы исчерпывающие ответы, содержащие как можно больше информации. Единственный способ – слушать. Задавайте открытые вопросы.
4. Перефразируйте вопросы, говорите на понятном языке
Перед тем, как закончить интервью необходимо перефразировать и произнести вслух уже полученные ответы. Некоторые люди не думают и не выражают свои мысли в законченной (лаконичной) форме. Они «прыгают» с одного на другое и смешивают важные вещи с незначительными. Если вы перефразируете информацию, структурировав уже сказанное, собеседники могут ответить, верно ли их поняли. Такой прием также позволяет интервьюируемому добавить информацию или развить важные темы.
5. Не задавайте слишком много вопросов
Когда вы готовите план интервью, то старайтесь сузить круг вопросов, сфокусировав свое внимание на 3-5 наиболее важных.
6. Применяйте тактику «последнего вопроса»
Часто можно получить важный ответ, в котором нуждаешься, задавая его, уже собирая вещи и стоя в дверях.
Когда интервью закончено, все чувствуют себя расслаблено. Ваш собеседник не ощущает, что вы имеете какую-то власть над ним. Он с меньшей вероятностью займет защитную позицию и будет готов рассказать вам то, что вы хотите. Попробуйте этот прием, он работает.
Также вы можете задавать вопрос через 1-2 дня после проведения интервью. Этот вопрос необходимо обыграть таким образом, как будто вы забыли его задать в прошлый раз. Это также поможет вам получить ту информацию, которая требуется.
7. Всегда пишите благодарственные письма
Возвратившись с интервью, найдите время, чтобы написать письмо с благодарностью вашему собеседнику. Это будет вежливо и профессионально с вашей стороны. Может даже привести к более благоприятным результатам.
8. Обработка результатов интервью
После проведения интервью необходимо разобрать все сделанные конспекты и перевести всю информацию в электронный (компьютерный) формат для удобства дальнейшей работы с ней, поиска, сортировки и т.п. В случае возникновения вопросов, запишите их для проведения повторного интервью.

Item Tracking (Отслеживание пунктов)

Цель
Техника «Отслеживание пунктов» используется для того, чтобы захватить и назначить ответственных за проблемы и опасения заинтересованных сторон, которые оказывают влияние на решение.

Описание Item tracking
Отслеживание пунктов — это организационный подход, который используется бизнес-аналитиками для того, чтобы учитывать опасения заинтересованных сторон. Заинтересованные лица могут выявить такие типы пунктов, как действия, допущения, ограничения, дефекты, улучшения и проблемы. Когда беспокойство заинтересованных сторон впервые оглашается, то оно оценивается, чтобы определить насколько данная проблема жизнеспособна. Если проблема может превратиться в жизнь, то беспокойству присваивается определенный тип пункта таким образом, что оно может быть лучше отслеживаться и процесс отслеживания мог бы контролироваться, пока рассматриваемый элемент не будет закрыт. То есть пока проблема не будет исчерпана. Во время своего жизненного цикла пункту назначается одна или более заинтересованных сторон, которые несут ответственность за его исполнение. Отслеживание пункта позволяет следить за пунктом от начальной записи беспокойства (опасения) и степени воздействия до его закрытия. Записи при отслеживании пункта могут быть переданы заинтересованными сторонам для обеспечения прозрачности и видимости состояния и развития пунктов в записи.

Элементы отслеживания пунктов
1. Запись пункта
Каждый записанный пункт может содержать все или любые из следующих атрибутов для отслеживания пунктов. Эти пункты могут быть записаны с использованием различных программных приложений или может быть создан каталог вручную для обмена информацией между утвержденной группой заинтересованных сторон.

• Идентификатор пункта: уникальный идентификатор, который отличает один пункт от другого.
• Суммарная информация: краткое описание пункта.
• Категория: группировка пунктов с общими свойствами.
• Тип: вид рассматриваемого пункта.
• Дата выявления: дата, когда пункт вызвал опасения.
• Кем идентифицирован: человек, который изначально поднял данный вопрос.
• Воздействие: возможные последствия, если пункт не будет разрешен в поставленный срок. Воздействие может быть оценено по отношению ко времени инициативы, по отношению к стоимости, рамкам или качеству инициативы.
• Приоритет: важность пункта для затронутых заинтересованных сторон.
• Дата разрешения пункта: дата, до которой пункт должен быть решен (или закрыт).
• Владелец: заинтересованная сторона, назначенная для управления пунктом для его закрытия.
• Распознаватель: назначенная заинтересованная сторона, которая разбирается в деталях пункта.
• Согласованная стратегия: согласованная стратегия для пункта. Например, может включать в себя меры по утверждению, отслеживанию, игнорированию, смягчению или избеганию.
• Статус: текущий статус пункта в рамках его жизненного цикла. Например, открыт, назначен, решен, отменен.
• Обновления по решению: запись журнала детальной информации о том, как решается пункт по пути к закрытию, а также утверждение его завершения.
• Матрица эскалации: уровень эскалации, в случае, если элемент не удается устранить с помощью данного срока.

2. Управление пунктом
Разрешение каждого пункта осуществляется в порядке, установленном в соответствии с потребностями заинтересованных сторон, а также в соответствии с любыми стандартами организационных процессов. В некоторых случаях, один пункт может быть связан с другим пунктом для записи и отслеживания. В таких ситуациях пристальное внимание необходимо для того, чтобы не дублировать действия и иметь прогресс в координации работы. Каждый пункт должен отслеживаться до его закрытия или разрешения.

3. Метрики
Все заинтересованные стороны выиграют от более подробной информации, которая поддерживается по пункту и его прогрессу. Эти пункты могут быть рассмотрены в индивидуальном порядке в ходе разрешения или даже могут быть использованы для определения ключевых показателей эффективности с учетом процесса отслеживания пункта.
Просматривая выходную информацию, заинтересованные стороны могут определить насколько хорошо:

• Пункты решаются при существующих ресурсах,
• Инициатива продвигается,
• Насколько процесс отслеживания пункта используется.

Особенности использования:
1. Сильные стороны

• Обеспечивает фиксирование опасений вокруг требований заинтересованных сторон, их отслеживание и разрешения для удовлетворения заинтересованных сторон.
• Позволяет заинтересованным сторонам ранжировать важность нерешенных пунктов.

2. Ограничения

• Если не быть осторожным, то подробное документирование данных о пунктах может перевесить любые преимущества.
• Данная методика может потребовать время, которое можно было бы потратить на другие усилия и заинтересованные стороны могут погрязнуть в деталях или статистике.

Lessons Learned Process

Цель
Целью процесса извлеченных уроков является сбор и документирование успехов, возможностей для улучшения, неудач и рекомендаций для повышения эффективности будущих проектов или проектных фаз.

Описание
Сессии извлеченных уроков могут проходить в любом формате или в любом месте, которое подойдет для ключевых заинтересованных сторон, участвующих в этих сессиях.

Элементы
Сессии могут включать рассмотрение следующих пунктов:
— Деятельность бизнес-анализа;
— Результаты бизнес-анализа;
— Конечный (финальный) продукт;
— Процессы бизнес-анализа;
— Используются или не используются автоматизация и технологии;
— Управленческие проблемы или вопросы;
— Как активы организационных процессов помогают или мешают бизнес-анализу и процессам работы с требованиями;
— Производительность по отношению к плану;
— Отклонения:
— Основные причины отклонений (первопричины);
— Отклонения были планируемыми или значительно аномальные;
— Какие корректирующие и/или профилактические действия были рекомендованы, утверждены или отклонены, а также приняты;
— Сессии извлеченных уроков могут проходить в виде формальных, неофициальных совещаний с заданными повестками дня и ролей участников встреч, в виде формальных или неформальных рабочих заседаний, неформальных собраний, любые из которых могут включать или не включать торжества.

Особенности использования
1. Преимущества

• Полезно для выявления возможностей для улучшения процесса.
• Может помочь в построении боевого духа команды после трудного периода.

2. Недостатки

• Все участники должны быть готовы избегать какого-либо желания присваивать в ходе сессии кому-либо вину, в противном случае честной дискуссии может не произойти.
• Участники могут неохотно документировать и обсуждать проблемы.
• Сессия может застопориться и возможности для улучшения могут быть упущены.

Metrics and Key Performance Indicators (KPIs)

Цель
Целью метрик и ключевых показателей эффективности является оценка эффективности решений, компонентов решения и других вопросов, которые представляют интерес для заинтересованных сторон.

Описание
Метрика — это количественный уровень показателя, который организация использует для измерения прогресса. Показатель указывает на определенное числовое измерение, которое характеризует степень прогресса на пути к достижению цели, задачи, результату, выполнению вида деятельности или дополнительному вкладу. Ключевым показателем эффективности является тот, который измеряет прогресс на пути к достижению стратегической цели или задачи. Отчетность — это процесс информирования заинтересованных сторон при помощи метрик индикаторов в указанном формате через определенные промежутки времени.
Метрики и отчетность являются ключевыми компонентами мониторинга и оценки. Мониторинг представляет собой непрерывный процесс сбора данных для определения того, насколько хорошо решение было реализовано по сравнению с ожидаемыми результатами. Оценка — это систематическая и объективная оценка решения для определения его статуса реализации и эффективности достижения целей с течением времени, а также для того, чтобы определить пути улучшения решения для лучшего соответствия целям. Наиболее приоритетными направлениями системы мониторинга и оценки являются поставленные цели и эффекты решения, а также входные ресурсы/данные, виды деятельности и выходные результаты.

Элементы
1. Indicators (Показатели)
Показатель (индикатор) определяет конкретное численное измерение для цели, воздействия, результат, вида деятельности, входных ресурсов (материалы, данные и т.п.). Каждый из этих факторов выгоды (пользы) имеет показатель для изменения его должным образом, но некоторым факторам может потребоваться несколько показателей. Хороший показатель удовлетворяет пяти характеристикам:

• Clear (Понятность): показатель должен быть точным и однозначным;
• Relevant (Соответствие или релевантность): должен соответствовать измеряемому фактору;
• Economical (Экономичность): затраты на показатель должны быть умеренными;
• Adequate (Адекватность): показатель должен обеспечивать достаточную основу для оценки производительности;
• Quantifiable (Измеримость): показатель может быть независимо подтвержден.

В дополнение к этим характеристикам, интересы заинтересованных сторон могут быть также важны. Некоторые показатели могут помогать заинтересованным сторонам выполнять или улучшать процессы больше, чем другие. Со временем, недостатки в некоторых показателях могут быть идентифицированы и улучшены.
Не все факторы могут быть измерены непосредственно. Косвенные показатели могут использоваться когда данные для прямых показателей не доступны или не целесообразно собирать данные на регулярной основе. Например, при отсутствии процессов опроса удовлетворения клиентов, организация может использовать в качестве косвенного показателя долю возобновленных (пролонгированных) договоров в общем объеме договоров.
При создании индикатора необходимо учитывать его характеристики: источник данных, метод сбора, кто собирает данные, а также стоимость, частоту и сложность сбора. Вторичные источники данных могут быть наиболее экономичными, но для удовлетворения других характеристик хорошего индикатора может потребоваться проведение первичных исследований, таких как опросы, интервью, прямые наблюдения. Метод сбора данных — это ключевой фактор мониторинга, оценки и отчетности по стоимости системы.

2. Metrics (Метрики)
Метрики — это количественный уровень показателя, который оценивается на указанный момент времени. Целевая метрика — это задача, которая должна быть выполнена в течение определенного периода. При настройке метрики (обычно одной) для показателя важно иметь четкое понимание базовой отправной точки, ресурсы, которые могут быть направлены на улучшение факторов, которые охватываются показателями, а также иметь четкое понимание политических проблем.
Метрика может являться конкретным пунктом, пороговым значением или диапазоном. Диапазон может быть полезным, если показатель является новым. Рамки времени для достижения целевой метрики могут представляться в многолетнем, годовом или квартальном виде, или чаще, в зависимости от необходимости.

3. Structure (Структура)
Создание системы мониторинга и оценки требует процедуры сбора данных, процедуры анализа данных, процедуры создания отчетности и сбора исходных данных. Процедура сбора данных охватывает блоки анализа, процедуры отбора образцов, выбор инструментов сбора данных для использования, частоту сбора данных и ответственность за сбор данных. Метод анализа определяет порядок проведения анализа и потребителей данных, которые могут иметь сильную заинтересованность в том, как проводится анализ. Процедура создания отчетности охватывает шаблоны отчетов, получателей отчетов, частоту создания отчетов и средства коммуникации (коммуникационные каналы). Исходная информация заключается в том, какие данные предоставляются непосредственно перед измерениями или в начале периода измерения. Исходные данные используются для того, чтобы узнать о последних успехах и оценки прогресса в отправной точке. Исходная информация должна быть собрана для каждого показателя, который будет анализироваться или использоваться в отчетности.
Существует три ключевых фактора в оценке качества показателей и их метрик — это надежность, достоверность (валидность) и своевременность. Надежность — это степень, в которой подход к сбору данных является стабильным и последовательным во времени и пространстве. Достоверность — это степень, в которой данные понятно (четко) и напрямую измеряют производительность, которую организация намерена измерить. Своевременность — это соответствие частоты и времени ожидания данных, в которых нуждается менеджмент.

4. Reporting (Отчетность)
Как правило отчеты сравнивают базовые, текущие и целевые показатели друг с другом, рассчитанные различия представлены как в абсолютном выражении, так и в относительном. В большинстве случаев, тенденции являются более авторитетными и важными, чем абсолютные показатели. Визуальные представления тренда, как правило, более эффективно, чем таблицы, особенно при использовании качественных описаний для объяснения данных.

Особенности использования
1. Преимущества
Создание системы мониторинга и оценки позволяет заинтересованным лицам понять, насколько решение соответствует целям и как эффективным была разработка решения (входы, выходы и деятельность решения).
Показатели, метрики и отчеты также способствует согласованности внутри организации, связываются цели с задачами, осуществляется поддержка решения, происходит лучше процесс управления базовыми задачами и ресурсами.
2. Недостатки
Сбор чрезмерного количества данных сверх того, что обеспечило бы получения требуемых результатов, приведет к напрасным затратам по сбору данных, их анализу и составлению отчетности. Это также будет отвлекать участников проекта от других обязанностей. На agile проектах это будет особенно актуально.
Бюрократическая программа по метрикам завершится с ошибкой из-за сбора слишком большого объема данных и не будут созданы полезные отчеты, которые позволят реализовать своевременные ответные действия. Лица, которым поручен сбор данных для метрик должны получить обратную связь для того, чтобы понять как их действия влияют на качество результатов проекта.
Когда показатели используются для оценки производительности, некоторые люди могут действовать таким образом, чтобы увеличить свою производительность на этих показателях, даже если это приводит к снижению производительности по другим видам деятельности.

Non-functional Requirements Analysis

Цель анализа нефункциональных требований
Целью нефункциональных требований является описание необходимых качеств системы, таких как юзабилити и эксплуатационные (технические) характеристики. Они дополняют документацию по функциональным требованиям, которые описывают поведение системы.

Описание
Документ с нефункциональными требованиями по качеству системы:

• для группы пользователей необходимо описывать: юзабилити (удобство использования), обучаемость, надежность и т.д.
• для группы разработчиков необходимо описывать: маштабируемость, ремонтопригодность, возможность многократного использования и т.д.

Строго говоря, термин «нефункциональные требования» применяется только при описании программного приложения. Тем не менее, различные категории нефукнциональных требований могут быть применимы и к другим компонентам решения, для которых требования могут быть разработаны. Например, требования к надежности для организационной единицы могут включать определенные часы обслуживания, а также требования к эффективности бизнес-процессов могут включать длительность цикла по решению запроса клиента и могут быть зафиксированы в соглашении об уровне обслуживания (SLA). В этих случаях, альтернативный термин требования «качество обслуживания» может быть предпочтительнее.

Элементы
Следующие элементы обычно включены в описание нефункциональных требований.
1. Категория
Нефункциональные требования, как правило, организованы по категориям. Классификация (категоризация) поддерживает выявление нефукнциональных требований путем представления в уме списка характеристик, которые следует учитывать при выполнении сбора требований. Схема, перечисленная здесь, основана на ISO 9126, но другие классификации/категории (такие как FURPS +) могут также быть использованы.
Reliability (Надежность): Доступно ли приложение ПО когда это необходимо? Требования к надежности включают в себя возможность приложения для того, чтобы исправлять ошибки, время безотказной работы или сбои в работе интерфейсов.
Performance Efficiency (Уровень производительности, эффективность исполнения): Обеспечивает ли приложение ПО приемлемый уровень производительности с учетом имеющихся ресурсов? Требования по уровню производительности включают в себя время, которое необходимо для выполнения активностей и уровни использования ресурсов.
Operability (Работоспособность): Данное приложение ПО понятно для пользователей? Требования по работоспособности включают в себя описание какие пользователи могут признать, что приложение будет на самом деле удовлетворять их потребности, а также описывается легкость обучения по работе с приложением и удобство применения (юзабилити) приложения.
Security (Безопасность): Препятствует ли приложение преднамеренному неправильному использованию? Требования безопасности включают в себя возможность обеспечения надлежащей конфиденциальности информации, целостности информации, которая хранится в заявке, возможность проверить какие и кем были осущеставлены действия в системе, а также возможность проверки подлинности пользователей (процесс аутентификации).
Compatibility (Совместимость): Может ли приложение эффективно работать с другими приложениями в той же среде (окружении)? Требования к совместимости включают в себя требования правильной замены другого приложения, способность сосуществования с другим приложениями, а также способность взаимодействия с другими приложениями.
Maintainability (Удобство сопровождения): Может ли приложение эффективно быть изменено после внедрения (реализации) для удовлетворения меняющихся потребностей? Требования по удобству сопровождаемости (обслуживания) включают в себя возможность изменения одного компонента без изменения остальных, возможность повторного использования компонентов, может ли приложение быть эффективно протестировано и могут ли проблемы быть правильно диагностированы, легкость внесения изменений и возможность осуществления изменений, не вызывая непредвиденные сбои.
Transferability (Переносимость): Может ли приложение быть установленно и в другой среде? Требования переносимости включают легкость установки и удаления приложения, виды разных сред, в которых приложение может работать, а также простота миграции приложения на новую среду.

2. Measurement
Определение нефункциональных требований должно включать в себя соответствующую метрику успеха для каждого требования, чтобы они могли быть адекватно протестированы. Некоторые нефункциональные требования могут показаться очень субъективными (например, «интуитивно понятный интерфейс»), но внимательное размышление, как правило, может обеспечить соответстующую метрику для измерения успеха.

3. Documentation
Нефункциональные требования, как правило, документируются в текстовом виде с помощью повествовательных высказываний, таких как:

• 90% операторов должны иметь возможность использовать всю функциональность системы после того, как пройдут тренинг, который длится не более чем 6 часов.
• Система должна обеспечивать 90% ответов в течении не более 2х секунд.

Эта документация представляется как часть документации общей совокупности требований, часто в виде раздела или отдельного документа.

Особенности использования
1. Преимущества
Успех в удовлетворении нефункциональных требований будет оказывать сильное влияние на то, будет или не будет принята система пользователями.
2. Недостатки
Нефункциональные требования зачастую труднее определить по сравнению с функциональными требованиями. Ожидания от атрибутов качества не могут быть описаны и пользователи приложения могут испытывать сложности при их формулировки.
Чрезмерно строгие нефункциональные требования могут существенно повлиять на стоимость разработки прикладного программного обеспечения.

Observation

Наблюдение — К.Вигерс и Дж.Битти

Если вы попросите пользователей описать, как они выполняют свою работу, им наверняка будет тяжело быть точным — детали могут отсутствовать или быть некорректными. Часто это происходит из-за того, что задачи сложные и каждую мелочь не упомнишь. В других случаях причина в том, что пользователи довели выполнение задачи данных до такого автоматизма, что не состоянии сформулировать, что они в точности делают. Задача становится такой привычной, что они даже не думают о ней. Иногда можно узнать очень многое, наблюдая за тем, как пользователи в реальности выполняют свои задачи.
Наблюдения занимают много времени, поэтому они не годятся для каждого пользователя или задачи. Чтобы не нарушать ежедневную работу пользователей, ограничьте наблюдение двумя часами или меньше. Выбирайте для наблюдения важные или высокорискованные задания и множественные классы пользователей. При наблюдении в проектах гибкой разработки просите пользователей демонстрировать только задачи, относящиеся к будущей итерации.
Наблюдение рабочего процесса пользователя в рабочей среде позволяет бизнес-аналитику проверять информацию, полученную из других источников, определять новые темы для интервью, обнаруживать проблемы с текущей системой и определять возможности улучшения, чтобы новая система лучше поддерживала рабочий процесс. Бизнес-аналитик должен абстрагироваться и обобщать наблюдаемые операции пользователей, чтобы зафиксированные требования относились к классу пользователей в целом, а не к отдельным личностям. Опытный бизнес-аналитик часто может предложить идею по улучшению текущих бизнес-процессов.

Смотрите, как надо печь кекс
Чтобы продемонстрировать мощь наблюдения, расскажите нескольким своим друзьям, как испечь кекс. Вы наверняка не забудете перечислить такие шаги, как: разогреть духовку, взять нужную посуду и инструменты, добавить ингредиенты, перемешать их, вылить жидкое тесто в форму, испечь и вытащить готовый кекс из духовки. Но рассказывая о добавлении ингредиентов, не забыли ли вы сказать, что нужно открыть пакет с разрыхлителем? Или что яйца надо разбить и использовать содержимое, а скорлупу выкинуть? Эти очевидные операции могут быть не столь очевидны человеку, который никогда не занимался выпечкой.

Наблюдение может быть пассивным (молчаливым) или интерактивным. Пассивное наблюдение уместно, когда занятых пользователей нельзя отвлекать от работы. В процессе интерактивного наблюдения бизнес-аналитик может отвлекать пользователя и задавать вопросы. Это позволяет моментально понять, почему пользователь сделал именно такой выбор, или спросить, о чем он думал, предпринимая именно такое, а не иное действие. Документируйте свои наблюдения, чтобы их можно было потом проанализировать. Если позволяют корпоративные политики, может иметь смысл вести видеозапись, чтобы можно было освежить память в последующем.
Я разрабатывал приложение контактного центра для сотрудников по обслуживанию клиентов, которым нужно было просматривать печатный каталог и находить товары, которые заказывали клиенты. Команда бизнес-аналитиков встретилась с несколькими такими сотрудниками, чтобы выявить варианты использования нового приложения. Все как один сотрудники говорили о том, как сложно листать большое количество каталогов в поиске именно того товара, о котором говорил клиент. Каждый бизнес-аналитик сел рядом с одним из сотрудников и понаблюдал, как они принимают заказы по телефону. Мы увидели, что им сложно: сначала надо найти каталог по дате, а потом попытаться найти нужный товар. Наблюдения помогли нам понять, какие функции могут потребоваться в программном каталоге товаров.

Наблюдение за работой людей — Илья Корнипаев

Наблюдать за работой людей можно по-разному. Во-первых, можно попросить разрешения прийти на рабочее место человека, где он расскажет, как он работает. Во-вторых, можно найти место рядом с рабочим местом человека, наблюдение за работой которого вам интересно для получения требований. В-третьих, вы можете не присутствовать рядом, а наблюдать за работой человека удаленно, с помощью камер и/или средств, позволяющих видеть, что человек делает на компьютере (или использовать для этого журналы операций в системе).
Когда прибегают к таким способам получения требований? В основном, когда представители заинтересованной стороны (в частности будущие пользователи) не могут внятно рассказать о том, как они выполняют свою работу. В этом случае посещение рабочего места представителя заинтересованной стороны может существенно ускорить процесс получения требований. Аналитик своими глазами сможет увидеть, как и что делают люди.
Однако у этого метода есть также и свои недостатки. Во-первых, обычно это более трудозатратный метод по сравнению с интервью. Для получения одной и той же информации приходится тратить больше времени. Во-вторых, часть работы, возможно, аналитик не увидит, поскольку она может выполняться не каждый день. Это, например, периодическая отчетность или работа с нестандартными случаями или ошибками. В-третьих, человек может вести себя в присутствии аналитика на своем рабочем месте скованно и стесненно, бояться показаться некомпетентным в присутствии коллег, ошибаться и путаться. Может рассказывать не то, как он работает, а то, как это положено по инструкции, даже если это неудобно и он и его коллеги уже давно выработали для себя более эффективные способы выполнения своей работы.
Если работа аналитика связана с разработкой и развитием систем автоматизации деятельности предприятия, на котором он работает, т.е. он сотрудник той организации, для которой делается автоматизация, то ему имеет смысл найти рабочее место не в ИТ-отделе, а в бизнес-подразделении. Это способствует большему погружению аналитика в предметную область, хотя и имеет также свои негативные стороны. Если аналитик сидит вместе с представителями бизнеса, он очень много времени вынужден тратить на поддержку. И в то же время он становится менее доступен для команды разработки. Иногда возможен уход аналитика в бизнес-подразделение, после того, как он некоторое время поработал рядом с представителями бизнеса. Поэтому по возможности нужно стараться на некоторое время сажать аналитика в бизнес-подразделение, но потом возвращать его в ИТ. Если говорить об удаленном наблюдении, то это еще более трудозатратный способ, хотя не стоит его отметать полностью. Например, если текущая система позволяет понять по журналу операций, кто, когда и что делает, это может стать неплохим подспорьем аналитику. Он сможет по такому журналу, в частности, сделать вывод о том, какими функциями существующей системы пользуются часто, а какими не пользуются, и потом спросить, почему так происходит. Может быть эти функции совсем не нужны для работы, а возможно, они работают плохо, и людям приходится выполнять эту работу за пределами системы вручную. Также к недостаткам удаленного наблюдения за работой будущих пользователей системы можно отнести возможные неточности в интерпретации аналитиком увиденного, поскольку при таком методе наблюдения он не может спросить, что и зачем делает человек, а следовательно, может неправильно понять увиденное.
Таким образом, стоит применять этот способ получения требований, когда этом может помочь собрать требования лучше и полнее.

Organization Modeling

Цель
Организационное моделирование используется для описания ролей, обязанностей и структуры отчетности, которая существует в пределах организации, а также согласовать эти структуры с целями организации.

Описание
Организационная модель определяет, как организация или ее подразделения структурированы. Организационные подразделения объединяют группу людей для осуществления общего предназначения и достижения целей. Предназначение подразделения может быть функциональным — это означает, что люди, которые принимают участие в решении вопроса, имеют общий набор навыков и знаний, или обслуживают конкретный рынок. Организационная модель будет определять границы организационного подразделения, формальные отношения между людьми, которые являются членами этого подразделения, роли этих людей в подразделении, а также взаимодействие между этим подразделением и другими подразделениями или заинтересованными лицами.

Элементы
1. Организационные цели и организационная структура
Functions (Функции): Функционально-ориентированные организации группируют вместе персонал на основе общих навыков или областей знаний. Они, как правило, утверждаются в целях содействия стандартизации работы или процессов внутри организации. Функциональные организации упрощают управление затратами и сокращают дублирования работы, но склонны к развитию проблем в коммуникации и в кросс-функциональной координации (их неофициально называют «силосы», т.е. появляется препятствие в обмене информацией).
Markets (Рынки): Термин «Ориентированный на рынок» охватывает ряд различных возможных способов организации предприятия, все действия которого базируются на обслуживании определенного сегмента клиентов, а не на общих навыках и знаниях работника. Структуры, ориентированные на рынок, позволяют организации лучше ориентироваться на потребности своих клиентов, но такие структуры склонны к развитию противоречий в том, как работа должна быть выполнена и происходит дублирование работы в разных подразделениях. Организация, ориентированная на рынок, может быть организована по группам клиентов, географическим районам, проектам или по процессам.
Matrix (Матрица): В этой модели существуют отдельные менеджеры для каждой функциональной области и для каждого продукта, сервиса (услуги) или группы клиентов. Сотрудники указывают в строке менеджера, который несет ответственность за выполнения того или иного вида работы и для выявления возможностей повышения эффективности в работе, а также менеджера по рынку (продукту/сервису/проекту и т.п.), который отвечает за управление продуктом, сервисом (услугой) и т.д. в разрезе функциональных областей.

2. Роли
Организационная единица (подразделение) будет включать в себя ряд заданных ролей. Каждая роль будет требовать определенного набора навыков и знаний, будет иметь определенные обязанности, будет выполнять определенные виды работ, а также будет иметь определенные отношения с другими ролями в организации.

3. Интерфейсы
Каждая организационная единица будет иметь интерфейсы с другими организационными единицами. Интерфейсы могут быть в форме рабочих пакетов, которые организационная единица получает или посылает другим единицам, коммуникации с людьми в других ролях и так далее. Рабочие пакет должны иметь определенные требования и стандарты качества, которые согласовываются заинтересованными сторонами, которых эти пакеты затрагивают. Эти требования, стандарты и ожидания могут быть определены формально или неформально, а также могут быть согласованы в каждом отдельном случае или допускают гибкость по отношению к первичному фиксированию (требований, стандартов и ожиданий).

4. Организационные Диаграммы
Принципиальной схемой, которая используется в организационном моделировании, является организационная диаграмма. Не существует официального стандартного набора для определения организационных диаграмм, хотя есть определенные стандартные соглашения, которым удовлетворяют большинство организационных диаграмм. Организационная диаграмма показывает:

• Организационные единицы, которые могут представлять людей, команды (группы людей), департаменты или подразделения (отделы) в зависимости от уровня абстракции организационной диаграммы. Часто в организационных диаграммах будем смешивать организационные единицы, показывая комбинации людей, команд и высокоуровневых подразделений.
• Линии отчетности, с помощью которых прослеживают подотчетность и контроль между организационными единицами. Сплошная линия обычно означает прямую власть, а пунктирная линия показывает передачу информации или ситуационную власть. Линии отчетности визуально изображают норму управляемости конкретного менеджера или подразделения (то есть число людей, за руководство которыми руководитель несет ответственность).
• Роли и люди. Организационная диаграмма должна показывать роли, которые существуют в пределах организации и людей, которые назначены на каждую из этих ролей.

Рисунок «Организационная диаграмма»

Особенности использования:
1. Преимущества
Организационные модели — это одни из немногих типов моделей любой организации, которые почти наверняка должны быть определены. Даже простейшая организация должна определить структуры отчетности между членами команды для того, чтобы координировать работу между своими людьми.
2. Недостатки
Основным ограничением организационного моделирования является не сама техника, а скорей всего последствия, включая организационную реконструкцию в рамках проекта. Организационная реконструкция, вероятно, будет весьма спорным моментов и потребует значительной поддержки для того, чтобы быть успешной.
Вторичная проблема заключается в том, что неформальные линии власти и коммуникаций, которые не отражены в организационной структуре, почти наверняка существуют в организации.

Prioritization

Приоритеты — это способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы. Расстановка приоритетов помогает проекту обеспечить максимальную пользу для бизнеса как можно быстрее и в рамках ограничений проекта.

Для успешного определения приоритетов требуется понимание шести характеристик:

• потребностей клиентов;
• относительной важности требований для клиентов;
• последовательности, в которой должны предоставляться функции;
• требований, служащих основой для других требований, и других связей между требованиями;
• потребности реализовывать какие-то группы требований целиком;
• затраты на удовлетворение каждого требования.

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

• Есть ли другой способ удовлетворить это требование клиентов?
• Что случится, если это требование убрать или отложить?
• Что произойдет с бизнес-целями проекта, если это требование не будет реализовано в ближайшие месяцы?
• Почему пользователи будут недовольны, если реализация этого требования будет отложена до следующего выпуска?
• Стоит ли из-за этой функции откладывать выпуск всех остальных функций с тем же приоритетом?

Метод 1 «Включать или не включать»
Группа заинтересованных лиц просматривает список требований и по каждому принимает простое бинарное решение — включать требование в следующий выпуск или нет? При этом надо держать в уме бизнес-цели проекта и пытаться свести список к абсолютному минимуму, необходимому в первом выпуске.
Далее, после начала реализации этого выпуска, можно вернуться к ранее исключенным требованиям и повторить весь процесс снова для следующего выпуска.

Метод 2 «Попарное сравнение и ранжирование»
Ранжирование списка требований предусматривает выполнение попарного сравнения между всеми требованиями, чтобы можно было определить, какой член в каждой паре приоритетнее.

Рисунок «Пример определения приоритетов атрибутов качества для терминала регистрации в аэропорту»

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

Метод 3 «Трехуровневая шкала приоритетов»
Этот способ оценки приоритетов предлагает учитывать два измерения: важность и срочность. Получаются четыре комбинации для определения шкалы приоритетов:

Требования с высоким приоритетом (high priority) — и важные (пользователям нужны функции), и срочные (они необходимы уже в следующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин. Если реализацию требования можно отложить до более позднего выпуска без отрицательных последствий, тогда, в соответствии с этим определением, его нельзя считать высокоприоритетным;

Требования со средним приоритетом (medium priority) — важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска);

Требования с низким приоритетом (low priority) — не важные (пользователи при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, возможно неограниченно долго);

Требования в четвертой клетке кажутся срочными части заинтересованных лиц, возможно по каким-то «политическим» причинам, но в действительности они не важны для достижения бизнес-целей. Не тратьте время на работу над ними, потому что они не добавят продукту ценности. Если они не важны, присвойте им низкий приоритет или вообще удалите.

Рисунок «Определение приоритетов требований по важности и срочности»

Рисунок «Многопроходная приоритизация обеспечивает ориентацию на получение набора высокоприоритетных требований»

При выполнении анализа приоритетов по трехуровневой шкале нужно помнить о зависимостях требований. У вас будут проблемы, если высокоприоритетное требование зависит от другого, у которого приоритет ниже и которое запланировано к реализации позже.

Метод 4 «Схема классификации приоритетов MoSCoW»
Четыре заглавных буквы в схеме определения приоритетов MoSCoW обозначают четыре возможных классификации приоритетов в наборе:

• Must — требование должно быть удовлетворено, чтобы решение было успешным;
• Should — требование важно и по возможности должно быть включено в решение, но оно не является условием успеха решения;
• Could — это желательная функция, но ее можно отложить или удалить. Реализуйте ее, только если позволяет время и ресурсы;
• Won’t — так обозначается требование, которое в этот раз реализовываться не будет, но может быть включено в будущий выпуск.

Схема MoSCoW неоднозначна в том, что касается временных характеристик, особенно когда речь идет о рейтинге «Won’t» — это может означать «не в следующем выпуске» или «никогда». Такие различия должны определяться четко, чтобы у всех заинтересованных лиц было единое представление о последствиях данного конкретного рейтинга. Трехуровневая шкала более точна в отношении приоритетов (лучше пользоваться ею).

Метод 5 «100 долларов»
Дайте команде, занимающейся определением приоритетов сто воображаемых долларов. Члены команды должны потратить эти доллары на «покупку» конкретных требований из всего набора требований-кандидатов. На более приоритетные требования надо выделить больше денег. Если одно требование в три раза важнее для заинтересованного лица, чем другое, оно должно выделить, скажем, десять долларов на первое и три — на второе. Но каждый получает только 100 долларов — когда деньги кончаются, ничего больше нельзя реализовать, по крайней мере не в том выпуске, над которым сейчас идет работа. К процессу приоритизации привлекают различных участников для распределения своих долларов, после чего суммируются доллары по каждому требованию, чтобы определить, за какие требования было отдано больше всего долларов.

Метод 6 «Определение приоритетов на основе ценности, стоимости и риска»
Quality Function Deployment (QFD) — всесторонний метод определения относительной ценности для клиента предлагаемых функций продукта. В таблице показана модель, которая поможет вам оценить относительные приоритеты для набора вариантов требований. Эта методика была признана самой эффективной в сравнительной оценке 17 методик определения приоритетов требований:

План использования модели:
1. Перечислите в таблице все функции, варианты использования, направления вариантов использования, пользовательские истории или функциональные требования, для которых хотите определить относительные приоритеты.
2. Попросите представителей клиентов оценить относительную выгоду, которую каждая функция дает клиенту или бизнесу, по шкале от 1 до 9: 1 балл означает, что никто не находит ее полезной, а 9 — что она крайне ценная.
3. Оцените относительный ущерб, который понесет клиент или бизнес, если функция не будет реализована. Снова используйте шкалу от 1 до 9: 1 балл означает, что никто не расстроится, если она будет исключена; 9 показывает серьезный ущерб.
4. В этой таблице подсчитаны итоговые значения для каждой функции как сумма баллов ее выгоды и ущерба (распределение весов описывается далее в этой главе). В ней суммируется ценность всех функций и вычисляется процент от общего значения для каждого набора функций, равного сумме ценностей каждой функции (столбец «Ценность, %»).
5. Попросите разработчиков оценить относительную стоимость реализации каждой функции по шкале от 1 (легко и быстро) до 9 (трудоемко и дорого).
6. Подобным же образом, разработчики оценивают относительную степень технического риска (не бизнес-риска), связанного с каждой функцией, по шкале от 1 до 9. Технический риск — это вероятность неудачной реализации функции с первого раза. 1 балл означает, что вы сможете запрограммировать ее даже во сне, 9 баллов означает серьезную озабоченность возможностью реализации, нехваткой сотрудников с необходимым опытом или использованием неиспытанных или незнакомых средств и технологий.
7. После того как вы введете все результаты оценки в таблицу, по следующей формуле подсчитывается значение приоритета для каждой функции:
Приоритет = Ценность % / (Затраты % + Риск %)
8. Наконец, отсортируйте список функций по уменьшению подсчитанного приоритета — крайний правый столбец. Функции вверху списка характеризуются наиболее благоприятным сочетанием ценности, стоимости и риска, и поэтому — при равенстве остальных факторов — должны иметь наивысший приоритет.

Process Analysis

Анализ процессов

Process Modeling

Цель
Моделирование процессов необходимо для того, чтобы понять, как работа, которая включает в себя несколько ролей и подразделений, выполняется в рамках организации.

Описание
Процесс описывает как несколько человек или групп сотрудничают в течение определенного периода времени для того, чтобы выполнить работу. Процессы включают в себя ряд мероприятий, которые связаны потоком последовательности. Процесс повторяется и может иметь несколько путей для того, чтобы он считался завершенным.
Процесс инициируется событием в области бизнеса, таких как продажа продукта клиенту, запрос о предоставлении информации старшим руководителем, или при возникновении сбоя в ходе выполнения транзакции. События могут быть деятельностью людей, результатом работы правил, которые вызывают действия, или возникать при прошествии определенного периода времени. Модель процесса может содержать ручную деятельность, деятельность может быть полностью автоматизирована, или может применяться комбинированный подход из автоматизации и ручной деятельности. Процесс завершается когда задачи или цели процесса выполнены/достигнуты.
Модель процесса — это визуальное представление последовательного потока и логики управления набором взаимосвязанных мероприятий или действий. Процесс моделирования используется для графического представления текущего или будущего процесса внутри организации. Модель может быть использована на самом высоком уровне, чтобы получить общее представление о процессе или же на более низком уровне, в качестве основы для моделирования, для того, чтобы сделать процесс максимально эффективным.
Figure «Flowchart»

Figure «Activity Diagram»

Элементы
Существует множество различных нотаций, которые используются для описания моделей процессов. Наиболее часто используемыми являются блок-схемы (flowcharts) и UML диаграммы деятельности, хотя в последние годы широкое распространение получила нотация BPMN. Модели процессов обычно содержат некоторые или все из следующих основных элементов:
1. Обозначения элементов
Activities (Деятельность): Индивидуальные шаги или части работы, которая должна быть завершена в целях исполнения бизнес-процесса. Деятельность может проявляться в виде одной задачи или может быть в дальнейшем разложена на составные части подпроцесса (с его собственной деятельностью, потоками и другими элементами процесса).
Decisions (Решения): Разветвления, где поток работы продолжается в двух или более потоках и, при необходимости, где отдельные потоки сливаются воедино. Решение может создать взаимоисключающие или параллельные потоки.
Events (События): События происходят за рамками процесса и могут являться результатом принятых мер (действий), принятых сообщений, или по прошествии времени. События могут создавать, прерывать или завершать процессы.
Flow (Поток): Укажите направление рабочего потока в виде последовательности действий «шаг за шагом». В общем, схемы рисуются сверху вниз или в направлении чтения, чтобы показать течение времени. Поток процесса может разделиться, чтобы показать деятельности, которые происходят одновременно и позднее сливаются.
Roles (Роли): Роли представляют собой тип человека или группы. Определения ролей, как правило, совпадают с организационной моделью (organization model).
Swimlanes and Pools (Дорожки и Пул/Объединение дорожек): Дорожки — это горизонтальные или вертикальные секции модели процессов, которые показывают какие виды деятельности выполняются определенной ролью. Когда поток работ пересекает границу дорожки, ответственность за работу переходит к другому лицу или группе лиц внутри организации.
Объединение дорожек (Пул) представляет собой организационную границу. Пул может включать в себя несколько дорожек. Как правило, процесс будет включать в себя один пул для заказчика и второй пул для организации, хотя возможно, что процесс включает в себя любое количество пулов.
Terminal Points (Конечные точки): Конечные точки представляют собой начало или конец выполнения процесса или потока процессов. Конечная точка, как правило, представляет собой некое событие, которое является видимым для организации или вне ее.

2. Улучшение процесса
Существует ряд фреймворков (framework, каркас или структура) и методологий, которые сосредоточены на методах совершенствования процессов, такие как Six Sigma, Lean, а также большое количество патентованных подходов BPM. Методы улучшения процесса включают в себя метод Value Stream Mapping (VSM, Систематизирование потока ценности), статистический анализ и контроль, моделирование процесса, бенчмаркинг, процессные фреймворки и другие. Общие изменения процессов с целью их улучшения включают в себя:
— Анализ процесса для выявления или устранения тех видов деятельности, которые не добавляют ценности для заинтересованных сторон, где это возможно.
— Сокращение времени, которое требуется для завершения процесса (за счет сокращения времени выполнения задачи или времени ожидания между задачами).
— Улучшение интерфейсов или передачи обслуживания между ролями и организационными единицами, для устранения ошибок.
— Сокращение или ликвидация узких мест и бэклогов (backlogs, невыполненных заказов).

Особенности использования
1. Преимущества
— Большинство заинтересованных сторон знакомы с основными элементами и понятиями, которые лежат в основе модели бизнес-процессов.
— Модели процессов являются эффективными в случае, когда необходимо показать, как обрабатывается большое количество сценариев и параллельных ветвей.
— Модели процессов, вероятно, имеют ценность сами по себе, так как они будут использоваться заинтересованными сторонами бизнеса для подготовки и координации видов деятельности.
2. Недостатки
— Модели процессов могут стать чрезвычайно сложными и громоздкими, если их тщательно не структурировать. Сложные процессы могут содержать достаточное количество видов деятельности и ролей, что может привести к практически невозможныму для понимания виду ни для одного человека.
— Проблемы в процессе не всегда можно идентифицировать, посмотрев на модель. Обычно необходимо привлекать непосредственно заинтересованные стороны, чтобы найти проблемы, с которыми они столкнулись при выполнении процесса.

Prototyping

Прототипирование — Тодд Заки Варфел

Плюсы прототипирования

• Прототипирование продуктивно;
• Прототипирование дает возможность показать и рассказать;
• Прототипирование снижает вероятность неправильного восприятия;
• Прототипирование позволяет сэкономить время, усилия и деньги;
• Прототипирование создает быструю цепь обратной связи, в результате снижаются риски.

Процесс прототипирования в Messagefirst:
Прототипирование — процесс, а не продукт, средство достижения цели. Несколько важных моментов:

• Создание набросков — ключевая часть процесса прототипирования;
• Используйте метод дизайнерской студии: составление набросков;
• Показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;
• Начинайте с количества, исследуя множество идей. Качество придет позже.

Прототипы могут отличаться по качеству и функциональности, но наиболее типичное их использование включает:

• создание среды для совместного общения;
• переработку методом проектирования;
• «продажу» идеи своему начальнику или коллегам в компании;
• тестирование удобства использования;
• оценку технической реализуемости и стоимости.

Ошибки при прототипировании — обычное явление. Избежать их легко, если руководствоваться следующими восемью принципами:

• узнайте целевую аудиторию и ее намерения;
• планируйте немногое, прототипируйте остальное;
• формируйте ожидания;
• делайте наброски;
• это прототип, а не Мона Лиза;
• если не можете что-то сделать, притворитесь, что можете;
• прототипируйте только необходимое;
• уменьшайте риски — прототипируйте на ранних этапах и часто.

Инструмент Прототипирования — Частота использования:

• Бумага — 77%
• Visio — 59%
• PowerPoint — 43%
• Dreamweaver — 47%
• Axure — 30%
• OmniGraffle — 30%
• Illustrator — 23%
• Flash — 21%
• Acrobat — 19%
• Fireworks — 18%
• InDesign — 12%
• Photoshop — 10%
• Другой редактор — 4%
• Keynote — 3%
• Flex — 2%
• Blend — 0,2%
• iRise — 0,1%
• Другие (Excel,FileMaker) — 0,1%

Факторы, влияющие на выбор инструментов прототипирования:
1. Аудитория: кто будет смотреть прототип или работать с ним?
2. Намерения: вспомните пять видов прототипов. Какие из них вам нужны?
3. Степень знакомства и возможность изучения: знакомы ли вы с методом или инструментом, хотите ли их изучать?
4. Стоимость: принимайте во внимание стоимость не только лицензии, но и простоя, пока вы будете изучать инструмент.
5. Совместная работа: нужна ли она? Если да, то ваши возможности заметно ограничены.
6. Распространение: как вы собираетесь сообщать результаты другим людям?
7. Выбросить или использовать повторно: если нужен повторно используемый код, то выбор ограничен. Если нет, что гораздо более вероятно, то перед вами широкий выбор.

Прототипирование программного обеспечения

Прототипирование программного обеспечения — это этап разработки программного обеспечения, целью которого является разработать прототип программы, т.е. его макет или пробную версию. С помощью прототипа программы осуществляется проверка пригодности предлагаемых концепций, архитектурных и технологических решений. Прототип обычно демонстрируют заказчику на ранних стадиях процесса разработки программного обеспечения. В ходе демонстрации собирается обратная связь от будущих пользователей. Прототипирование может проходить в несколько этапов, в ходе которых будут уточняться функциональные требования к будущей системе. Данный процесс позволяет минимизировать ошибки проектирования на ранних стадиях разработки.

Шаги прототипирования программного обеспечения
1. Определение начальных требований к программе (системе)
2. Разработка первого варианта прототипа, в котором реализованы начальные требования к программе (системе). В основном первичный вариант содержит только пользовательский интерфейс;
3. Демонстрация прототипа заказчику и конечным пользователям, сбор обратной связи о необходимых изменениях и дополнениях в программе (системе);
4. Переработка функциональных требований, выпуск новых версий прототипа для того, чтобы учесть все замечания и предложения заказчика и пользователей. Шаги 3 и 4 могут повторяться.

Типы прототипирования ПО
Быстрое прототипирование (rapid prototyping) — технология быстрого «макетирования», быстрого создания опытных образцов или работающей модели системы для демонстрации заказчику или проверки возможности реализации текущей концепции системы. При использовании данного метода, предполагается, что созданный макет не станет частью готовой системы. Основное преимущество подхода — скорость представления макета в соответствии с требованиями. Стоимость изменений требований на этом этапе низкая. Быстрое прототипирование может осуществляться на платформе, которая отличается от промышленной системы.

Бумажное прототипирование — широко распространённый метод проектирования программного обеспечения. Процесс, позволяющий разработчикам выяснить реальные ожидания и потребности пользователей, прежде всего в том, что касается пользовательского интерфейса. Это метод быстрого прототипирования, при котором создаются грубые наброски интерфейса, часто даже сделанные от руки, и используются в качестве прототипа (модели) будущего продукта.
Бумажное прототипирование появилось в середине 1980-х и стало популярным в середине 1990-х, когда такие компании как IBM, Honeywell, Microsoft и другие стали использовать эту технику при разработке своих продуктов.
Бумажное прототипирование экономит время и деньги, поскольку позволяет разработчикам тестировать интерфейс (как программных продуктов и веб-сайтов, так и потребительской электроники) до того, как писать код или начинать разработку. Метод также позволяет выполнять легкие и дешевые изменения предложенного дизайна.

Эволюционное прототипирование (evolutionary prototyping) — последовательное создание макетов системы, которые будут с каждой итерацией приближаться к реальному продукту. На каждом шаге данного подхода мы команда проекта располагает работающей системой, которая может не обладать всей нужной функциональностью, но с каждой новой итерацией ее функциональность будет улучшаться. В данном случае, разработанный прототип может стать частью будущего продукта и разработанный код не будет «выброшен».
Эволюционный подход к прототипированию может быть выбран, если все необходимые требования к моменту начала разработки неизвестны и будут определяться по мере создания программы. Разработчики могут сосредотачиваться на работе только над теми модулями системы, требования к которым уже определены.

Risk Analysis and Management

Анализ рисков на основе BABOK v 2.0

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

Описание
Риск описывает неопределенное событие или явление, которые могут оказать влияние на способность бизнес-аналитика, проектной команды или организации достигнуть цели. Риски по своей природе могут быть положительными или отрицательными. Анализ рисков предполагает понимание допустимых уровней рисков организации, оценки рисков, а также идентификацию мер реагирования.

Элементы
1. Толерантность к риску
Ключевым фактором в определении меры реагирования, которая будет выбрана человеком или организацией в отношении риска, является понимание их толерантности к риску. Не существует правильной или идеальной меры реагирования — общая стратегия должна быть адаптирована к каждой конкретной ситуации. Три основные категории толерантности к риску:
— Неприятие риска. Люди или организации не толлерантные к риску будут стремиться снизить риски, особенно негативные риски, а также будут стремиться подойти как можно ближе к определенности, насколько это возможно. Сокращение потенциальных выгод в обмен на более определенные результаты рассматривается как приемлемый компромисс.
— Нейтралитет. Нейтральный подход к риску означает, что вероятные выгоды, получаемые от реагирования на риск, должны быть равны или превышать затраты для того, чтобы оправдать действия.
— Ищущий риски. Человек или организация ищущие риски будут готовы принимать относительно высокие риски для того, чтобы максимизировать потенциальную выгоду. Искатели рисков могут принять низкие шансы на успех, если выгоды от успеха выше.
Лицо или организация, может иметь различные уровни толерантности к риску (допуски риска) в разное время. Размер и потенциальное воздействие риска также может повлиять на толерантность к риску.

2. Оценка риска
Оценка предполагает определение вероятности возникновения риска и воздействий риска, если он возникнет. Каждый из этих факторов оценивается по общей шкале (Высокая, Средняя и Низкая вероятность, ряд чисел от 1 до 5, и т.д.). Этот анализ позволяет сосредоточить внимание на наиболее важных рисках.

3. Меры реагирования на риски
Стратегии реагирования определяют как организация будет справляться с риском. Для отрицательных рисков стратегии включают в себя:
— Acceptance (Принятие). Никаких усилий для борьбы с риском не производится. Организация принимает возможность того, что риск произойдет.
— Transfer (Передача). Ответственность за работу с риском и возможными последствиями от риска переходят к третьей стороне.
— Avoidance (Избегание). Организация принимает меры для того, чтобы риск не мог произойти.
— Mitigation (Смягчение). Организация предпринимает шаги, чтобы уменьшить вероятность возникновения риска или возможных негативных последствий возникновения риска.
Для положительных рисков также существует жизнеспособная стратегия. Другие стратегии включают в себя:
— Share (Разделение). Работа с третьей стороной для увеличения возможного положительного результата в случае исполнения и согласие в разделении выгод.
— Enhance (Усиление). Организация предпринимает шаги, чтобы увеличить вероятность риска и потенциальных выгод в случае реализации риска.
— Exploit (Эксплуатирование). Организация работате для того, чтобы событие произошло.

Особенности использования
1. Преимущества
Анализ рисков позволяет организации подготовиться к вероятности того, что, по крайней мере, некоторые вещи пойдут не так, как это планировалось.
2. Недостатки
Число возможных рисков для большинства инициатив может легко стать неуправляемо большим. В таком случае возможно управлять лишь подмножеством возможных рисков.
Так как риски по своей сути неопределенны, то это может привести к затруднениям в оценке степени воздействия рисков.

Анализ рисков и управление рисками на основе PMBOK Guide 5

Риск проекта — это неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта, таких как содержание, расписание, стоимость и качество. Риск может быть вызван одной или несколькими причинами и в случае возникновения может оказать воздействие на один или несколько аспектов. Причиной может быть существующее или потенциальное требование, допущение, ограничение или условие, которое создает вероятность отрицательных или положительных последствий.

Организации воспринимают риск как воздействие неопределенности на цели проектов и цели организации. Для организаций и заинтересованных сторон приемлемыми являются различные степени риска в зависимости от их отношения к риску. На отношение к риску как организации, так и заинтересованных сторон могут оказывать влияние различные факторы, которые классифицируются по трем категориям:
• Склонность к риску — степень неопределенности, которую хочет принять субъект в предвкушении вознаграждения.
• Толерантность к риску — уровень, количество или объем риска, который организация или лицо могут выдержать.
• Порог риска — измерение уровня неопределенности или уровня воздействия, к которому заинтересованная сторона может проявлять определенный интерес. Ниже этого порога риска организация примет риск. Выше этого порога риска организация не примет риск.

Процессы управления рисками проекта:
1. Планирование управления рисками — процесс, определяющий, каким образом осуществлять управление рисками проекта.
2. Идентификация рисков — процесс определения перечня рисков, которые могут воздействовать на проект, и документирования их характеристик.
3. Качественный анализ рисков — процесс расстановки приоритетов в отношении рисков для их дальнейшего анализа или действий, выполняемый путем оценки и сопоставления их воздействия и вероятности возникновения.
4. Количественный анализ рисков — процесс численного анализа воздействия идентифицированных рисков на цели проекта в целом.
5. Планирование реагирования на риски — процесс разработки вариантов и действий по расширению благоприятных возможностей и сокращению угроз целям проекта.
6. Контроль рисков — процесс применения планов реагирования на риски, отслеживания идентифицированных рисков, мониторинга остаточных рисков, выявления новых рисков и оценки результативности процесса управления рисками на протяжении всего проекта.

Общая схема процесса управления рисками проекта:

Root Cause Analysis

Цель
Целью анализа основных причин является определение базового источника проблемы.

Описание
Анализ основных причин — это структурированное изучение аспектов ситуации для установления причин и последствий существующей проблемы. Важнейшим элементом анализа первопричин является то, что существующие бизнес-мышление и процессы подвергаются сомнению. То есть, имеют ли они смысл или обеспечивают необходимую ценность для бизнеса в свете существующих реалий.

Элементы
Два часто используемых метода анализа основных причин — это диаграмма «Рыбьей кости» и Пять «Почему?»:
1. Диаграмма Исикавы — так называемая диаграмма «рыбьей кости» (Fishbone Diagram)
Диаграмма «рыбьей кости» (также известная как диаграмма Исикавы или причинно-следственная диаграмма) используется для идентификации и систематизации возможных причин проблемы. Этот инструмент помогает сосредоточиться на причинах проблемы по отношению к решению и организует генерацию идей для дальнейшего анализа. Схема служит своеобразной картой, изображающей возможные причинно-следственные отношения. Этапы разработки причинно-следственной диаграммы включают в себя:

• Фиксируем вопрос или проблему, которая обсуждается, в рамке (рамкой может служить прямоугольник) в верхней части диаграммы;
• Проведите линию от рамки по бумаге или на доске (формирование позвоночника рыбьего скелета);
• Нарисуйте диагональные линии от позвоночника, которые будут представлять категории потенциальных причин проблемы. Категории могут включать в себя людей, процессы, инструменты, а также политики организации;
• Рисуйте меньше линий, которые представляют более глубокие причины;
• Мозговой штурм категории и возможных причин проблемы и их фиксирование под соответствующей категорией;
• Анализ результатов. Помните, что группа определила только потенциальные причины проблемы. Дальнейший анализ необходим для того, чтобы подтвердить фактическую причину на основе данных;
• Мозговой штурм возможных решений после того, как фактическая причина была идентифицирована.

Рисунок «Диаграмма Исикавы»

2. Пять «Почему?»
Пять «Почему?» — это процесс задавания вопросов для того, чтобы исследовать природу и причину проблемы. Подход пять «Почему?» заключается в том, что необходимо многократно задавать вопрос в попытке добраться до первопричины проблемы. Это один из самых простых инструментов, который можно использовать, в случае когда проблема имеет компонент взаимодействия людей. Чтобы использовать эту технику, необходимо:

• Написать проблему на флип-чарте, белой доске;
• Задать вопрос: «Как вы думаете, почему это происходит?», а дальше зафиксировать озвученную идею ниже проблемы;
• Задать вопрос: «Почему?» снова и зафиксировать следующую идею, ниже первой идеи «Почему?».

Продолжайте выполнять 3 шаг до тех пор, пока вы убеждены, что реальная причина не была выявлена. Процесс может вызвать больше или меньше вопросов — методика называется 5 «Почему?», потому что часто необходимо многократно задавать вопрос в попытке добраться до первопричины, а не потому, что вопрос должен быть задан ровно пять раз.
Пять «Почему?» может использоваться самостоятельно или как часть диаграммы «Рыбьей кости». После того, как все идеи фиксируются на диаграмме, используйте пять «Почему?» для детализации причин.

Особенности использования:
1. Преимущества
Анализ основных причин обеспечивает структурированный метод по выявлению первоначальных причин идентифицированных проблем, обеспечивая тем самым полное понимание рассматриваемой проблемы.
2. Недостатки
Анализ основных причин работает лучше всего, когда кто-то, кто имеет официальную подготовку или большой опыт, оказывает содействие команде специалистов. Главной задачей ведущего является способность оставаться объективным, обеспечивая эффективный процесс анализа первопричин.

Scope Modeling

Цель
Модели границ (scope models) используются для описания границ анализа и границ решения.

Описание
Модели границ служать основой для определения и разграничения границ бизнес-анализа и объемов работ проекта. Модели границ позволяют определить полный охват — то есть границы области деятельности, которые соответствуют естественным границам предметной области.
Существует множество различных стандартов в области моделирования. В целом, выбранная модель границ (scope model) будет зависеть от методов анализа, отобранных для дальнейшего изучения границ.

Элементы
1. Контекстная диаграмма
Контекстная диаграмма — это высокоуровневая диаграмма потоков данных. Она представляет единый процесс передачи данных для того, чтобы описать границы и показать внешние сущности, а также хранилища данных, которые предоставляют необходимые данные и получают данные из системы. Контекстные диаграммы до сих пор используются на многих проектах, на которых не используются иных диаграмм потоков данных.
Рисунок «Контекстная диаграмма (Gane-Sarson Notation — нотация Гейна-Сарсона)»

Рисунок «Контекстная диаграмма (Yourdon Notation — нотация Йордона)»

2. События
Внешние события происходят во внешней сущности. Они являются внешними границами изучаемой системы (клиент делает запрос, партнер отправляет сообщение). Временные события управляются временем (например, ежемесячные или годовые отчеты). Время определяется бизнес-правилами, которые связаны со временем (например, производить этот отчет в конце каждого дня или подготовить налоговую декларацию по окончании каждого налогового периода).
Когда события были определены, следующий вопрос, который необходимо задать — это «Какие процессы необходимо обеспечить, чтобы предоставить полный отклик (ответ) на это событие?» Ответы на этот вопрос идентифицируют процессы системы. Эти процессы могут быть задокументированы и в дальнейшем проанализированы, используя соответствующую методику моделирования процессов.

3. Особенности
Функция — это служба, которую обеспечивает решение для выполнения одной или нескольких потребностей заинтересованных сторон. Функции высокого уровня абстракции решения, которые должны быть впоследствии полностью описаны в функциональных и дополнительных требованиях. Они позволяют проставлять приоритет и управлять границами (scope), а также согласовывать обзор решения заинтересованными лицами.

4. Диаграмма вариантов использования (Use Case)
Диаграмма вариантов использования (use case) наглядно представляет варианты использования, которые поддерживаются системой, актерами, которые инициируют варианты использования, а также отношения между вариантами использования.

5. Бизнес-процесс
Модели высокоуровневых бизнес-процессов также могут быть использованы в качестве модели границ (scope model).

Особенности использования
1. Преимущества
С помощью модели границ легче определить, что входит в рамки решения, а что выходит за рамки решения, даже когда идентифицируются новые требования или необходимы изменения в требованиях.
2. Недостатки
Модель границ, как правило, оставляют много детальных границ, которые нуждаются в иследовании и детализировании.

Sequence Diagram

Диаграмма последовательности — диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. Используется в языке UML.

Основными элементами диаграммы последовательности являются:

• обозначения объектов (прямоугольники с названиями объектов);
• вертикальные «линии жизни» (lifeline), отображающие течение времени;
• прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни»);
• стрелки, показывающие обмен сигналами или сообщениями между объектами.

Элементы диаграммы:

Пример диаграммы последовательности:

Questionnaire

Опросные листы — К.Вигерс и Дж.Битти

Опросные листы — один из способов обследования больших групп пользователей с целью выяснения их потребностей. Это недорого, хорошо подходит для сбора информации в больших сообществах пользователей и их легко использовать, даже если пользователи далеко разнесены географически.
Результаты анализа опросных листов можно рассматривать, как подготовку к применению других методов выявления требований. Например, опросные листы можно применять для выявления наболевших проблем пользователей в существующей системе, а результаты использовать при обсуждении приоритетов с ответственными за принятие решений на семинаре. Опросные листы можно также использовать для получения откликов пользователей серийного продукта.
Самое сложное в опросных листах — задать правильные вопросы. Существует много рекомендаций по написанию опросных листов, ниже приведены самые важные:

• варианты ответов должны охватывать весь диапазон возможных ответов;
• варианты ответов должны быть взаимоисключающими (никаких перекрытий в числовых диапазонах) и исчерпывающими (приведите все возможные варианты и/или добавьте свободное место, куда можно вписать вариант, о котором вы не догадались);
• вопрос не должен подразумевать получение «правильного» ответа;
• шкалы величин нужно использовать единообразно во всем опросном листе;
• используйте закрытые вопросы с двумя или большим числом вариантов, если опросный лист предназначен для статистического анализа. Открытые вопросы позволяют пользователям отвечать так, как им хочется, что затрудняет поиск общих моментов в результатах;
• стоит проконсультироваться со специалистом по составлению материалов и проведению опросов, чтобы удостовериться, что вы задаете правильные вопросы «правильным» людям;
• всегда тестируйте опросный лист до его распространения. Очень обидно слишком поздно обнаружить, что вопрос был задан неоднозначно или какой-то вопрос вообще забыли добавить;
• не задавайте слишком много вопросов, потому что люди просто не станут отвечать.

Опросы — Илья Корнипаев

Опрос или анкетирование — это метод, который может помочь аналитику в двух ситуациях.
Первая и достаточно распространенная ситуация — когда представитель заинтересованной стороны не может в полной мере сформулировать требования ввиду того, что реальных пользователей системы, работающих в одной роли, очень много. Эта ситуация характера, например, для коробочных продуктов. У продукта может быть не одна сотня или даже тысяча пользователей, и один человек вряд ли сможет сформулировать все требования от лица такой аудитории. В заказной разработке такие ситуации тоже возможны, например, в колл-центре может быть несколько сотен операторов, работающих в три смены. Для того, чтобы наиболее полно собрать требования, бывает очень полезно провести опрос среди большого количества пользователей.
Вторая ситуация — это выявление наиболее активных представителей заинтересованных сторон.
При составлении опросов (анкет) особое внимание нужно уделять тому, сколько и каких вопросов вы посылаете. Чем больше вопросов, тем меньше человек дойдет до конца. Чем меньше вопросов, тем меньше информации вы получите. Чем больше открытых вопросов вы зададите, тем дольше вы будете обрабатывать результаты, чем больше закрытых вопросов вы зададите, тем больше шанс упустить что-то важное. Поэтому необходимо тщательно продумывать вопросы при составлении анкеты. Обычно формулируют несколько закрытых вопросов, для того чтобы получить статистику, и несколько открытых, чтобы выявить новые требования.
Проведение опросов среди будущих пользователей системы повышает их самооценку. Этим мы показываем людям, что их мнение важно. Они чувствуют себя вовлеченными в процесс создания системы, особенно если по итогам опроса проводятся какие-то мероприятия, направленные на публичную демонстрацию того, что результаты опроса реально используются для улучшения жизни конечных пользователей, принявших в нем участие. Впоследствии это положительно сказывается на том, как идет приемка и внедрение системы в промышленную эксплуатацию.

SWOT Analysis

SWOT-анализ — это базовая аналитическая модель поиска стратегии, которая основывается на общей оценке сильных и слабых сторон компании, а также возможностей и угроз внешней среды. SWOT-анализ весьма абстрактен, поскольку его выводы носят чисто описательный характер: они не предполагают никаких рекомендаций и не расставляют приоритеты. Но этого и не требуется. Его задача — просто представить нам структурированное описание ситуации, в отношении которой нужно принять решение.

АНАЛИЗ ВНЕШНЕЙ СРЕДЫ (ВОЗМОЖНОСТЕЙ И УГРОЗ). Бизнес-единица должна постоянно отслеживать основные факторы макросреды (демографические, экономические, природные, технологические, политические, правовые, социальные, культурные), а также значимые элементы микросреды (покупатели, конкуренты, поставщики, дистрибьютеры, дилеры), которые влияют на получение прибыли. Обнаружить новые тенденции макро- и микросреды и происходящие в них изменения позволяет создание маркетинговой информационной системы. Для каждой новой тенденции руководство компании должно выявить соответствующие возможности и угрозы.
Маркетинговая возможность — область покупательских потребностей и интересов, удовлетворение которых с высокой долей вероятности принесет компании прибыль.
Угрозы внешней среды — это отрицательное влияние неких тенденций или неблагоприятное развитие событий, которые в отсутствие защитных маркетинговых мероприятий приводят к сокращению объемов продаж или прибыли компании.

АНАЛИЗ ВНУТРЕННЕЙ СРЕДЫ (СИЛЬНЫХ И СЛАБЫХ СТОРОН). Оценка внутренних сильных и слабых сторон выполняется по следующим направлениям деятельности компании — организация, производство, снабжение и логистика, инновации, финансы, маркетинг, персонал, безопасность, материально-техническое обеспечение.

На основе возможностей и угроз, сильной и слабой сторон составляются 4 типа стратегии:
1. Стратегия сопоставления сильных сторон и возможностей;
2. Стратегия сопоставления сильных сторон и угроз;
3. Стратегия сопоставления слабых сторон и возможностей;
4. Стратегия сопоставления слабых сторон и угроз.

Пример SWOT-анализа:

User Cases

Сценарий использования — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.

Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования):

• Деловой сценарий использования не затрагивает технологий, а рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей (например, обработка оплаты, одобрение авансового отчета, управляет корпоративным недвижимым имуществом). Деловой сценарий использования описывает процесс, ценный для делового агента, описывает что именно делает процесс.
• Системный сценарий использования обычно описывается на уровне функций системы (например, создайте ваучер) и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает, что актер может сделать, взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования начинались с глагола (например, создайте ваучер, выберите платежи, отмените ваучер).

Уровень детализации
Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

• Краткий сценарий использования состоит из нескольких предложений. Он может быть легко вставлен в ячейку электронной таблицы, позволяя записать в соседних столбцах приоритет, продолжительности, техническую сложность и другие параметры.
• Обычный сценарий использования состоит из нескольких параграфов текста, подытоживающих сценарий использования.
• Полностью детализированный сценарий использования — формальный документ, основанный на подробном шаблоне с различными разделами. Именно этот вариант подразумевается в большинстве случаев под понятием сценария использования.

Элементы сценария использования
Имя сценария
Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше, чем Регистрирующийся Пользователь), и должно объяснять смысл сценария использования. Неплохо использовать имя сценария, цель актера, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.
Цель
Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком актере, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
Актеры (Акторы)
Актер это кто-то или что-то вне системы и влияющий на систему или находящийся под ее влиянием. Актер может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими актерами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия.
Заинтересованные лица (Стейкхолдеры)
Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования.
Предварительные условия
Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария.
Активаторы
Активатор это событие инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), но ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.

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

• Один путь состоит в том, чтобы обработать «ошибку» в пределах сценария (как исключение). В принципе такой подход нелогичен, потому что «предварительные условия» — теперь не истинные предварительные условия вообще (потому что поведение сценария определено, даже когда предварительные условия не встречены).
• Другой путь — поместить все предварительные условия в активатор (так, чтобы сценарий не выполнялся, если предварительные условия не выполнены), и создать отдельный сценарий описывающий проблему.

Порядок Событий
Как минимум, каждый сценарий использования должен описать типичный ход событий, часто представленный как ряд пронумерованных шагов.
Альтернативные пути и дополнения
Сценарии использования могут содержать вторичные пути или альтернативные сценарии, которые являются вариантами основного. Каждое проверенное правило может привести к альтернативному пути и когда правил много количество альтернативных путей возрастает приводя к очень сложным документам. Иногда лучше использовать условную логику или диаграммы, чтобы описать сценарии со многими правилами и условиями.
Бизнес-правила
Бизнес-правила — cпособ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

Пример Use Cases:

User Stories

Пользовательские истории (User Stories) — это короткие предложения (одно или несколько предложений), которые описывают требования клиентов на ежедневном или деловом языке пользователя. Пользовательские истории используются в Гибких методологиях разработки ПО. Пользовательские истории фокусируются на нуждах заказчика и не содержат в себе деталей реализации. Пользовательские истории — это быстрый способ документирования требований клиента, без необходимости разработки обширных формализованных документов, требующих ресурсов на их поддержание.
Шаблон пользовательских историй:

Как <роль>, я хочу <цель>, чтобы <деловая выгода>.
или
Как <пользователь>, я могу <действие>, для того, чтобы <цель>.

Примеры пользовательских историй:
1. Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
2. Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
3. Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
4. Во время обсуждения первой истории, заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» – группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.
5. Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
6. Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.

Пользовательские истории можно выстраивать в иерархии (эпопеи). Эпопеи (epic) — это пользовательские истории, описывающие функциональность на высшем уровне. В дальнейшем, эпопеи разбиваются на более мелкие пользовательские истории и/или эпопеи.
Пример «Разложение эпопеи на несколько пользовательских историй»

Пользовательские истории представляют работу, которую команда должна произвести над продуктом, чтобы выполнить требования заказчика. Объем работ пользовательской истории должен быть расчитан на 2-3 дня, для эпопеи объем работ не имеет значения, т.к. она потом будет детализироваться на более мелкие пользовательские истории.
Когда начальный набор историй готов, все истории обговорены и детализированы до нужной степени, команда разработчиков переходит их реализации, выпуская программный продукт, в соответствии с приоритетами заказчиков и желаниями пользователей.
Более подробную информацию см. Проекты гибкой разработки (Agile)>>>

Vendor Assessment

Цель
Проведение оценки способности потенциального поставщика выполнить обязательства в отношении товара или услуги.

Описание
Когда решения являются частью, которая обеспечивается внешними поставщиками (которые могут быть вовлечены в проектирование, построение, реализации и технического обслуживания решения или компонентов решения) или когда решение находится на аутсорсинге, то в таких случаях могут существовать особые требования в отношении участия третьей стороны.
Например, может возникнуть необходимость, чтобы гарантировать, что поставщик является материально обеспеченным, способен поддерживать определенную численность персонала, осуществлять подготовку квалифицированных сотрудников для поддержки решения и так далее. Нефункциональные требования могут использоваться для опредлеения уровня обслуживания, который ожидается от третьей стороны. Оценка поставщиков проводится с целью подтверждения того, что поставщик надежен и, что уровень обслуживания будет соответствовать ожиданиям организации.

Элементы
1. Знания и опыт
Общая причина для использования сторонних поставщиков заключается в том, что они могут предоставить знания и опыт, который отсутствует внутри вашей организации. В таких случаях, бизнес-аналитик должен рассмотреть вопрос о том, какую экспертизу необходимо передать и способность поставщика выполнить эту передачу. Желательно, чтобы целевые поставщики обладали определенным опытом в сфере необходимых методологий и технологий для того, чтобы этот опыт перенимался людьми внутри предприятия.

2. Модели лицензирования и ценообразования
В тех случаях, когда решение или компонент решения приобретается из вне или отдается на аутсорсинг внешнему поставщику, модель лицензирования или ценообразования должна быть принята во внимание. Во многих случаях, решения, которые предлагают аналогичные функции могут значитально отличаться в своих моделях лицензирования. Поэтому необходимо провести анализ различных сценариев использования для того, чтобы определить, какой вариант обеспечит лучшее соотнесение затраты/прибыль в разрезе сценариев, которые могут встретиться на предприятии.

3. Репутация продукта и положение на рынке
Сколько клиентов в данный момент используют продукт или услугу? Рассматриваемый продукт широко принят или используется в аналогичных вашей организациях? Существует ли регулярный график обновлений и дорожная карта будущих возможностей, которые планируются добавляться к продукту?

4. Сроки и условия
Услуги, которые оказывает поставщик, будут временными или постоянными? Бизнес-аналитику следует выяснить, содержат ли в себе лицензионные условия и технологическая инфраструктура поставщика потенциальные проблемы, которые могут возникнуть в случае, если организация впоследствии решит перейти к другому поставщику. Здесть также можно исходить из соображений, которые касаются использования поставщиком и его ответственность за сохранение целостности конфиденциальных данных организации. Дополнительно необходимо рассмотреть условия индивидуальной настройки продукта (кастомизация продукта).

5. Опыт и репутация вендора (поставщика)
Опыт работы поставщика с другими клиентами может дать ценную информацию о том, насколько вероятно, что поставщик будет в состоянии выполнить договорные и внедоговорные обязательства. Поставщик также может быть оценен на соответствие и соблюдение внешних релевантных стандартов качества, безопасности и профессионализма.

6. Стабильность вендора (поставщика)
Какова вероятность того, что поставщик сможет обеспечить необходимые услуги в будущем? Для обеспечения услуг может потребоваться предпринять шаги, которые будут гарантировать отсутствие рисков, если вендор столкнется с финансовыми трудностями и что вендор будет поддерживать и улучшать решение, даже если ситуация радикально изменится.

Особенности использования:
1. Преимущества
Эффективная оценка поставщиков снижает риск для организации развития отношений с неподходящим поставщиком и, вероятно, приведет в долгосрочной перспективе к удовлетворению в связи с принятым решением.
2. Недостатки
Данный процесс может быть весьма трудоемким, т.к. требует сбора достаточного количества информации о различных поставщиках. Некоторая информация может быть недоступна. Поставщиков новых и инновационных продуктов можно недооценить, потому что они не имеют существенной истории на рынке.

Requirements Workshops

Семинары — Илья Корнипаев (Требования для программного обеспечения)

Это методика сбора требований. Суть состоит в том, чтобы собрать всех представителей заинтересованных сторон в одном месте на целый день или даже на два дня и полностью посвятить это время разработке и согласованию требований.
Основной смысл таких семинаров — это сбор требований в необходимом объеме за минимальный срок.
Подготовка к семинару:
1. Выявление всех заинтересованных сторон и определение представителей от каждой из этих сторон. Каждого из этих людей нужно убедить в необходимости посетить семинар, ставя во главу угла эффективность этого мероприятия и те выгоды, которые получит он сам и/или его отдел/организация от успеха мероприятия.
2. Выбор правильного времени и места проведения мероприятия. Все участники должны иметь возможность провести это время (день или два) за пределами рабочего места, не отвечать на звонки, электронную почту. Поэтому некоторая удаленность пойдет на пользу. Также важно продумать то, как люди попадут туда, где будет проводиться семинар. Задержка или, что еще хуже, неявка любого из участников может расстроить все планы.
3. Сбор и распространение среди участников семинара подготовительных материалов. Подготовительные материалы могут включать как документы, относящиеся непосредственно к проекту, так и те, которые могут настроиться на правильный лад.
4. Выбор ведущего (facilitator). Задачей ведущего является вести семинар так, чтобы участники не отвлекались, а работали в команде для достижения цели — собрать и утвердить в короткий срок требования. Если не удается найти внешнего независимого ведущего и приходится брать кого-то из проектной команды, то ему запрещается участвовать в обсуждении и вносить свои идеи на рассмотрение. Его работа — вести семинар и следить за регламентом и соблюдением правил семинара его участниками.

Повестка дня семинара обычно состоит из следующих основных пунктов:
— Вводная часть — представление места, повестки дня и правил проведения семинара;
— Презентация проекта — по сути, это краткий экскурс по подготовительным материалам, отправленным заблаговременно;
— «Мозговой штурм»;
— Определение возможностей и ограничений;
— Определение приоритетов и рамок проекта/фаз;
— Определение дальнейших шагов.

К.Вигерс и Дж.Битти (Разработка требований к ПО)

Семинары по сбору требований — это специально организованные встречи со многими заинтересованными лицами и формальными ролями, такими как организатор и секретарь. В семинарах обычно участвует несколько типов заинтересованных лиц — от пользователей до разработчиков и тестировщиков. Они применяются для сбора требований одновременно у нескольких заинтересованных лиц. В группе удается эффективнее разрешать разногласия, чем при индивидуальном разговоре. Также семинары полезны, когда выявить требования требуется быстро из-за плотного графика.
Ответственный за мероприятие играет ключевую роль: именно он планирует семинар, отбирает участников и следит, чтобы обсуждение проводилось продуктивно. Если вы собираетесь применять новые технологии сбора требований, ответственным за первый семинар следует назначить стороннего сотрудника или второго бизнес-аналитика. В этом случае основной бизнес-аналитик сможет полностью сосредоточиться на обсуждении. Пригласите также секретаря, чтобы он фиксировал все идеи, возникающие в ходе обсуждения. Если за семинар отвечает один бизнес-аналитик, он должен четко понимать, когда играет роль ответственного и когда рядового участника обсуждения. Пригласите также секретаря, чтобы он фиксировал все идеи, возникающие в ходе обсуждения. Очень сложно одновременно вести семинар, фиксировать идеи на бумаге и принимать активное участие в обсуждении.
Семинары могут требовать много ресурсов — иногда приходится сразу собирать многих участников на несколько дней. Семинары нужно тщательно планировать, чтобы не тратить время попусту. Сводите пустую трату времени к минимуму, приходя на семинар с заранее подготовленными предварительными версиями материалов. Например, можно набросать вчерне варианты использования, которые группа проверит в процессе семинара, вместо того, чтобы формулировать их с нуля. Очень редко бывают ситуации, когда имеет смысл начинать семинар с чистого листа. Воспользуйтесь другими методами выявления требований, и лишь затем используйте семинар только для того, чтобы собрать вместе заинтересованных лиц для проработки только сложных и неясных мест.

Приемы проведения эффективных семинаров выявления требований:
1. Определите и отслеживайте выполнение основных правил. Участники должны договориться об основных правилах проведения семинаров, своевременно начинать и заканчивать семинар, не опаздывать после перерывов, отключить звук у всех электронных приборов, не проводить несколько обсуждений одновременно, следить, чтобы каждый принимал участие в работе и комментировать и критиковать решение, а не личность. После определения правил следите, чтобы участники придерживались их.
2. Обеспечьте наличие всех ролей в команде. Организатор должен обеспечить выполнение участниками семинара следующих задач: ведение протокола, отслеживание времени, управление базовыми правилами, а также чтобы каждый был услышан. В частности, секретарь может фиксировать на бумаге все происходящее, а кто-то другой должен следить за часами.
3. Планируйте повестку дня. У каждого семинара должен быть четкий план. Заранее составьте план и повестку дня семинара и доведите их до участников, чтобы они знали, какие задачи будут обсуждаться и что ожидать и к чему готовиться.
4. Придерживайтесь границ проекта. Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте документ о концепции и границах проекта. Следите, чтоб на каждой встрече уровень обобщения соответствовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на прояснение пользовательских требований — время деталей наступит позже. Задача организатора — по мере необходимости возвращать участников к теме обсуждения.
5. Фиксируйте темы для дальнейшего обсуждения. На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес-правила, идеи по разработке пользовательского интерфейса, ограничения и т.п. Запишите их на плакатах — простейшим способом, — так вы не потеряете их и продемонстрируете уважение участнику, высказавшему их. Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся критически важными, например бизнес-правилом, которое ограничивает варианты использования. После семинара опишите, что случилось с высказанными идеями.
6. Ограничивайте некоторые дискуссии по времени. Подумайте о выделении фиксированного времени на обсуждение каждой темы. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано, на первую тему обсуждения, в результате чего может не хватить времени для обсуждения остальных тем. Перед завершением обсуждения темы резюмируйте ее состояние и последующие шаги.
7. Не увеличивайте размер команды и тщательно отбирайте участников. Небольшие группы работают намного быстрее. Семинары, число активных участников которых превышает пять или шесть человек, могут забуксовать, вылиться в параллельные дискуссии и даже ссоры. Попробуйте одновременного проводить несколько семинаров — это позволит исследовать требования различных классов пользователей. В обсуждении должны участвовать сторонник продукта и другие представители пользователей, возможно, эксперт в данной предметной области, бизнес-аналитик и разработчик. Допуском к участию в семинарах по сбору информации являются знания, опыт и право принимать решения.
8. Вовлекайте в обсуждение каждого. Иногда участники самоустраняются от обсуждения, расстроившись по какой-то причине. Возможно, их идеи не воспринимают серьезно, поскольку другим участникам их проблемы кажутся неинтересными или они не хотят отвлекать группу от текущего обсуждения. Возможно, аутсайдер не уверен в себе и уступил право голоса более активным сотрудникам или главному аналитику. Организатору семинара необходимо следить за языком телодвижений, чтобы разобраться в причинах замкнутости того или иного участника, и попытаться снова вовлечь его в работу. Видимые подсказки недоступны, если обсуждение ведется в режиме телеконференции — в этом случае вы должны внимательно слушать и ориентироваться по тону голоса. Молчаливых участников можно спросить прямо, нет ли у них мыслей, которыми они хотели бы поделиться. Организатор обязан обеспечить, чтобы все были услышаны.

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

1. http://lib.uml2.ru/
2. http://tim.com.ua
3. http://dic.academic.ru/
4. http://businessstudio.ru/
5. http://www.kpms.ru/General_info/Benchmarking.htm
6. http://powerbranding.ru/rynok/plan-analiza/
7. https://ru.wikipedia.org
8. http://www.bankiram.pro/2011/11/blog-post_17.html
9. Илья Корнипаев. Требования для рограммного обеспечения: рекомендации по сбору и документированию.
10. Вигерс Карл и Джой Битти. Разработка требований к программному обеспечению.