Методы описывают, как задачи выполняются при определенных обстоятельствах. Задача может не иметь ни одного, или одного, или нескольких связанных методов. Техника должна быть связана хотя бы с одной задачей.
Ниже приведены некоторые из известных методов сбора требований:
мозговая атака
Мозговой штурм используется при сборе требований, чтобы получить как можно больше идей от группы людей. Обычно используется для определения возможных решений проблем и уточнения деталей возможностей.
Анализ документов
Просмотр документации существующей системы может помочь при создании документа процесса AS – IS, а также провести анализ пробелов для определения масштабов проектов миграции. В идеальном мире мы бы даже рассмотрели требования, которые привели к созданию существующей системы, – отправную точку для документирования текущих требований. Самородки информации часто скрываются в существующих документах, которые помогают нам задавать вопросы в рамках проверки полноты требований.
Анализ требований 3. Сбор требований.
Фокус-группа
Фокус-группа – это группа людей, представляющих пользователей или клиентов продукта для получения обратной связи. Отзывы могут быть собраны о потребностях / возможностях / проблемах для определения требований, или могут быть собраны для проверки и уточнения уже выявленных требований. Эта форма исследования рынка отличается от мозгового штурма тем, что это управляемый процесс с конкретными участниками.
Анализ интерфейса
Интерфейсы для программного продукта могут быть человеческими или машинными. Интеграция с внешними системами и устройствами – это просто еще один интерфейс. Ориентированные на пользователя подходы к проектированию очень эффективны при создании программного обеспечения, пригодного для использования. Анализ интерфейса – проверка точек соприкосновения с другими внешними системами важна для того, чтобы убедиться, что мы не пропускаем требования, которые не сразу видны пользователям.
Опрос
Интервью заинтересованных сторон и пользователей имеют решающее значение для создания отличного программного обеспечения. Без понимания целей и ожиданий пользователей и заинтересованных сторон мы вряд ли сможем их удовлетворить. Мы также должны признать точку зрения каждого интервьюируемого, чтобы мы могли правильно взвесить и учесть их вклад. Слушание – это навык, который помогает великому аналитику получить больше пользы от интервью, чем средний аналитик.
наблюдение
Наблюдая за пользователями, аналитик может определить ход процесса, этапы, болевые точки и возможности для улучшения. Наблюдения могут быть пассивными или активными (задавать вопросы во время наблюдения). Пассивное наблюдение лучше для получения обратной связи по прототипу (для уточнения требований), где активное наблюдение более эффективно для понимания существующего бизнес-процесса. Любой подход может быть использован.
макетирования
Прототипирование – это относительно современный метод сбора требований. При таком подходе вы собираете предварительные требования, которые вы используете для создания начальной версии решения – прототипа. Вы показываете это клиенту, который затем предъявляет вам дополнительные требования. Вы меняете приложение и снова работаете с клиентом. Этот повторяющийся процесс продолжается до тех пор, пока продукт не удовлетворяет критической массе потребностей бизнеса или в течение согласованного количества итераций.
Мастер-класс по сбору и анализу требований
Семинары по требованиям
Семинары могут быть очень эффективными для сбора требований. Более структурированные, чем мозговые штурмы, вовлеченные стороны сотрудничают с требованиями к документам. Одним из способов получения совместной работы является создание артефактов модели предметной области (например, статических диаграмм, диаграмм действий). Семинар будет более эффективным с двумя аналитиками, чем с одним.
Обратный инжиниринг
Если у проекта миграции нет доступа к достаточной документации существующей системы, обратный инжиниринг определит, что делает система. Он не будет определять, что должна делать система, и не будет определять, когда система поступает неправильно.
Анкетирование
При сборе информации от многих людей – слишком много, чтобы провести собеседование с бюджетом и временными ограничениями – можно использовать опрос или анкету. Опрос может заставить пользователей выбирать из вариантов, оценивать что-либо («Согласен строго, согласен…») или иметь открытые вопросы, позволяющие получить ответы в произвольной форме. Дизайн опроса сложный – вопросы могут поставить в тупик респондентов.
Источник: coderlessons.com
9 визуальных инструментов для сбора требований к вашему программному обеспечению
Если у вас под рукой нет необходимых инструментов, сбор требований может показаться трудной задачей.
В этой статье мы рассмотрим несколько методов сбора требований, которые можно использовать при планировании и разработке программного обеспечения. Эти инструменты помогут вам сделать документ с требованиями более удобным для чтения.
Область применения этих методов сбора требований ни в коем случае не ограничивается разработкой программного обеспечения: вы можете использовать наши инструменты в любом другом проекте для облегчения этого процесса.
Что такое сбор требований
Сбор требований – важнейшая часть любого проекта вне зависимости от его масштабов. Он необходим для понимания и удовлетворения потребностей клиентов.
Процесс сбора требований включает в себя определение и документирование требований клиентов, пользователей, заинтересованных сторон и т.д., связанных с проектом. Эти знания будут использоваться для разработки различных решений: продуктов, услуг, программного обеспечения и т.д.
Методы, используемые для сбора этих данных, могут включать такие приемы, как интервьюирование, мозговой штурм, фокус-группы, анкетирование и т.д.
Методы сбора требований для разработки программного обеспечения
Следующие инструменты могут быть использованы в качестве вспомогательных или самостоятельных методов сбора требований.
Составление карт пользовательской истории
Составление пользовательской истории – это техника, которая используется для выявления и понимания требований конечных пользователей. Оно помогает командам разработчиков определять приоритеты своей работы исходя из того, что необходимо для обеспечения отличного пользовательского опыта.
Используя карту пользовательской истории, вы можете описать, как пользователь взаимодействует с вашим программным обеспечением (или продуктом, услугой, веб-сайтом и т.д.), а также историю знакомства пользователя с вашим продуктом.
Таким образом, вы сможете определить,что является наиболее желательным для ваших пользователей, и определить приоритетность создания функций, которые позволят улучшить их опыт взаимодействия с вашим продуктом.
Как создать карту пользовательской истории
Шаг 1: Соберите междисциплинарную команду сотрудников, участвующих в разработке продукта.
Шаг 2: С помощью профиля клиента выявите своих пользователей, их цели, потребности и т.д.. Проанализируйте собранные вами данные, чтобы сформулировать проблемы вашего пользователя. Подумайте, как ваш продукт может решить эти проблемы.
Шаг 3: Определите, какие действия совершают ваши пользователи при использовании вашего продукта. Это будут истории или темы, расположенные в верхней части вашей карты пользовательской истории. Вы можете использовать функцию совместной работы Creately в режиме реального времени, чтобы привлечь команду к совместной работе по разбивке этих действий на более мелкие пользовательские сценарии. Расположите эти сценарии вертикально на карте, самые важные из них разместите вверху.
Шаг 4: Зафиксируйте действия пользователя в рамках вашего продукта слева направо на вашей карте истории пользователя. Если пользователей несколько, создайте разные сценарии для каждого из них.
Шаг 5: Выделите истории, которые важны для создания лучшего пользовательского опыта. Затем определите зависимости, технические требования, проблемные аспекты, которые могут повлиять на предстоящую работу. Перед планированием работы убедитесь, что у вас есть методы решения этих проблем.
Аналогичным инструментом, который можно использовать для описания и анализа траектории пользователя, является карта действий пользователя.
Диаграммы вариантов использования
Диаграммы вариантов использования помогают визуализировать взаимодействие между пользователем и системой, или, другими словами, действия пользователя и реакцию системы на них. Это помогает сохранять фокус на требованиях конечного пользователя на всем протяжении процесса разработки системы.
Ознакомьтесь с нашим пособием по диаграмме вариантов использования, чтобы узнать, как ее составить.
Диаграммы последовательности
Еще один тип диаграмм UML, который может использоваться в качестве метода сбора требований, – это диаграмма последовательности.
Диаграмма последовательности иллюстрирует, как различные части системы взаимодействуют друг с другом для выполнения функции, а также порядок, в котором происходят эти взаимодействия при выполнении конкретного сценария использования.
Узнайте все о диаграммах последовательности и о том, как их составлять, в нашем пособии по диаграммам последовательности.
Каркасное представление и макеты пользовательского интерфейса
Каркасное представление
Каркасное представление – это общий план интерфейса веб-сайта или приложения, визуализирующий его навигацию и расположение. Оно поможет вам понять, как будет работать приложение или сайт, и определить, нет ли ошибок в его проекте.
Используя шаблон каркасного представления, подобный приведенному ниже, вы и ваша команда сможете понять, как работает ваша система.
Макет пользовательского интерфейса
Более наглядной и детализированной версией каркаса является макет пользовательского интерфейса. Он поможет вам получить представление не только о том, как работает ваше приложение, но и о том, как оно будет выглядеть.
С помощью инструмента макета пользовательского интерфейса Creately вы сможете добавить ссылки на элементы диаграммы, сделав ее навигационной, так что при нажатии на кнопку вы сможете перейти на соответствующую страницу. Это поможет вам составить представление о пользовательском опыте сайта.
Карты процессов и блок-схемы
Карты процессов и блок-схемы дают упрощенное представление о процессе. Они могут оказаться очень полезными, если вы хотите отобразить свои бизнес-процессы, потоки пользователей или понять и объяснить процесс сбора требований.
Вы можете использовать его для того, чтобы
- понять существующую систему (с помощью карты текущего состояния) и то, как она изменится после применения того или иного решения (с помощью карты будущего состояния);
- объяснить, как применить новое решение;
- составить карту задач и этапов проекта (и добавить дополнительную информацию, например, владельцев задач или отделы с плавающими дорожками);
- выявить пробелы и препятствия в ваших процессах и найти соответствующие решения.
Вот наше руководство по блок-схемам, который поможет понять, как рисовать и использовать блок-схемы.
Диаграммы связей
При сборе требований часто проводятся индивидуальные и групповые мозговые штурмы. Вы можете использовать диаграммы связей, чтобы фиксировать свои идеи, организовывать и классифицировать их и продолжать их доработку с помощью диаграмм связей.
Вот еще несколько визуальных методов мозгового штурма, которые вы можете использовать для более быстрого генерирования идей.
Контекстные диаграммы системы
Контекстные диаграммы – это один из методов сбора требований к программному обеспечению, который следует использовать в самом начале процесса.
Контекстные диаграммы системы дают глубокое представление о системе в ее окружении и о том, как она взаимодействует с внешним миром: пользователями, другими системами и т.д.
9 визуальных инструментов для сбора требований к программному обеспечению
Диаграммы функциональной декомпозиции
Диаграмма функциональной декомпозиции может быть использована для разбиения системы на более мелкие и простые части. Это поможет вам лучше понять, как она функционирует.
Разбив таким образом систему или процесс, вы сможете легко понять, что требуется сделать.
Знаете другие методы сбора требований?
Эти методы сбора требований облегчают восприятие; то, что они являются визуальными, поможет сделать ваш документ с требованиями более легким для чтения и понимания.
Хотите дополнить наш список методов сбора требований? Расскажите нам о вашем любимом методе в комментариях ниже.
Источник: creately.com
Что нужно сделать до старта проекта. Часть 2
Наш эксперт Максим Якубович рассказывает, что необходимо сделать до начала проекта, чтобы его шансы на успех выросли. Сегодня речь о том, как получить четкие требования к ожидаемым результатам проекта.
– В Части 1 речь шла о влиянии допущений на планирование проекта. Анализ допущений помогает руководителю сформулировать риски проекта и снизить неопределенность.
Но еще большая неопределенность в проекте порождается нечеткими требованиями к его результатам. Изучим вопрос сбора и анализа требований к продуктам (результатам) проекта.
В проекте создается некоторая ценность для компании, которая платит за проект. Ценность эта может выражаться в виде материальных или нематериальных результатов.
До старта проекта руководителю и заказчику нужно договориться о том, какие результаты ожидает от проекта заказчик.
Сформулировать результаты проекта иногда не так просто как кажется. Попробуйте сформулировать цель для проекта проведения корпоративного праздника, а после этого для реализации целей сформулируйте результаты проекта. Не думаю, что у вас это получится легко сделать.
Давайте вернемся к кейсу, который был описан в Части 1 – проект внедрения CRM-системы. В этом проекте заказчик определил следующие результаты:
1. Регламент, описывающий работу сотрудников с клиентами.
2. Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте.
3. Обученные работе с программным продуктом сотрудники компании.
4. Работающий сервис поддержки пользователей программного продукта.
Чтобы удовлетворить ожидания заказчика от проекта, руководителю проекта необходимо уточнить требования к каждому результату проекта.
Что такое требование?
Существуют десятки определений термина «требование».
Например, в ISO 9000 этот термин определяют как: потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
За основу возьмем это определение, и будем считать, что ожидание считается установленным, если оно записано в документе, который согласовал заказчик.
Классификация требований
Для некоторых продуктов уже разработаны классификаторы. Они позволяют снизить вероятность того, что некоторые важные требования к продукту могут быть упущены.
Например, существуют классификаторы требований к программному обеспечению. Один из них представлен на рисунке:
С точки зрения сбора требований к программному продукту, такая классификация позволяет аналитику помнить что, кроме требований к функциям, которые должен выполнять программный продукт, нужно еще уточнить требования к внешним интерфейсам, ограничениям системы.
Эта классификация помогает также понять, с чего начать сбор требований и как их уточнять (стрелки на диаграмме показывают последовательность сбора требований, но при этом аналитик может возвращаться к предыдущим этапам). В книге Карла Вигерса «Разработка требований к программному обеспечению» даны определения каждой категории требований и примеры, поэтому я не буду приводить их в статье.
Итак, при сборе требований к программному продукту аналитику требований уже есть чем руководствоваться – есть классификаторы требований и описания классов требований.
Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:
1. Регламент процесса должен содержать описание процесса в нотации … (здесь нужно уточнить название нотации).
2. Регламент должен содержать матрицу ответственности с перечислением функций каждого участника процесса (к матрице ответственности тоже можно предъявить требования).
3. Документ не должен превышать определенное количество слов (это является ограничением).
4. Документ должен быть написан определенным шрифтом (можно указать его название и кегль).
5. В документе обязательно должны быть следующие разделы (к каждому можно предъявить требования по содержанию).
6. Документ должен содержать раздел, описывающий внесенные изменения в документ.
Какие требования можно предъявить к такому результату, как обученные сотрудники?
1. Сотрудники должны пройти обучение работе с программным продуктом.
2. Для обучения сотрудников должна быть разработана программа обучения (могут быть требования к содержанию программы).
3. Обучение должно проходить на реальных примерах компании. Примеры для обучения должны быть утверждены заказчиком проекта.
4. По итогам обучения проходит тестирование знаний сотрудников. Средний балл по итогам тестирования на знание программного продукта составляет не менее ___ баллов (по 10-бальной шкале).
5. Требования к методике тестирования знаний сотрудников следующие…
Требования к работающему сервису поддержки программного продукта можно сгруппировать по следующим темам:
1. Стоимость сервиса поддержки в месяц.
2. Время предоставления сервиса (например, с 8.00 до 20.00 по GMT+2).
3. Время реагирования на обращение в службу (к примеру, 30 минут с момента регистрации обращения в службу поддержки).
4. Время на решение проблемы, описанной в обращении пользователя (здесь нужно вводить классификацию обращений и по каждому из них определять норматив на закрытие обращения или на перевод его в другой статус).
5. Время на восстановление сервиса в случае сбоя.
6. Возможность для пользователей отследить статус своего обращения.
7. Возможность получить отчет по обращениям за определенный период.
Сформулировав требования к результатам проекта, руководитель проекта может начинать планировать состав работ по проекту и прогнозировать объемы работ, сроки и бюджет проекта.
