Бизнес-анализ - Краткое руководство
Что такое бизнес-анализ?
Бизнес-анализ - это набор задач, знаний и методов, необходимых для выявления бизнес-потребностей и определения решений бизнес-проблем предприятия. Хотя общее определение схоже, практика и процедуры могут различаться в разных отраслях.
В индустрии информационных технологий решения часто включают компонент разработки систем, но могут также включать улучшение процессов или организационные изменения.
Бизнес-анализ также может выполняться для понимания текущего состояния организации или служить основой для определения бизнес-потребностей. Однако в большинстве случаев бизнес-анализ выполняется для определения и проверки решений, соответствующих потребностям, целям или задачам бизнеса.
Кто такой бизнес-аналитик?
Бизнес-аналитик - это тот, кто анализирует организацию или бизнес-область (реальную или гипотетическую) и документирует ее бизнес, процессы или системы, оценивая бизнес-модель или ее интеграцию с технологиями. Тем не менее, звания в организации различаются, например, аналитик, бизнес-аналитик, аналитик бизнес-систем или, возможно, системный аналитик.
Почему бизнес-аналитик?
Организации используют бизнес-анализ по следующим причинам:
Чтобы понять структуру и динамику организации, в которой будет развернута система.
Чтобы понять текущие проблемы в целевой организации и определить возможности улучшения.
Чтобы гарантировать, что заказчик, конечный пользователь и разработчики имеют общее представление о целевой организации.
На начальном этапе проекта, когда требования интерпретируются группами разработчиков и разработчиков решений, роль бизнес-аналитика заключается в проверке документов решений, в тесном сотрудничестве с разработчиками решений (ИТ-группа) и менеджерами проектов, чтобы гарантировать, что требования ясны.
В типичной крупной ИТ-организации, особенно в среде разработки, вы можете найти как локальные, так и удаленные группы доставки, выполняющие указанные выше роли. Вы можете найти «бизнес-аналитика», который действует как ключевой человек, который должен связать обе команды.
Иногда он взаимодействовал с бизнес-пользователями, а иногда с техническими пользователями и, наконец, со всеми заинтересованными сторонами в проектах, чтобы получить одобрение и окончательный кивок перед тем, как приступить к документации.
Следовательно, роль БА очень важна для эффективного и успешного старта любого проекта.
Роль ИТ-бизнес-аналитика
Роль бизнес-аналитика начинается с определения и оценки бизнес-областей организации, затем выявления требований, анализа и документирования требований, передачи этих требований соответствующим заинтересованным сторонам, определения правильного решения и затем проверки решения, чтобы определить, требования соответствуют ожидаемым стандартам.
Чем он отличается от других профессий?
Бизнес-анализ отличается от финансового анализа, управления проектами, обеспечения качества, организационного развития, тестирования, обучения и разработки документации. Однако в зависимости от организации бизнес-аналитик может выполнять некоторые или все эти связанные функции.
Бизнес-аналитики, которые работают исключительно над разработкой программных систем, могут называться ИТ-бизнес-аналитиками, техническими бизнес-аналитиками, онлайн-бизнес-аналитиками, аналитиками бизнес-систем или системными аналитиками.
Бизнес-анализ также включает взаимодействие между заинтересованными сторонами, командами разработчиков, командами тестирования и т. Д.
Жизненный цикл разработки программного обеспечения
Жизненный цикл разработки программного обеспечения (SDLC) - это процесс, которому следуют в программном проекте внутри программной организации. Он состоит из подробного плана, описывающего, как разрабатывать, поддерживать, заменять, изменять или улучшать конкретное программное обеспечение. Он определяет методологию улучшения качества программного обеспечения и всего процесса разработки.
SDLC - это процесс, используемый ИТ-аналитиками для разработки или перепроектирования высококачественной программной системы, отвечающей как требованиям заказчика, так и реальным требованиям.
Он принимает во внимание все связанные аспекты тестирования программного обеспечения, анализа и постпроцессного обслуживания.
Важные этапы SDLC изображены на следующей иллюстрации -
Стадия планирования
Каждое действие должно начинаться с плана. Неспособность спланировать - значит потерпеть неудачу. Степень планирования отличается от одной модели к другой, но очень важно иметь четкое представление о том, что мы собираемся построить, создавая спецификации системы.
Определяющий этап
На этом этапе мы анализируем и определяем структуру системы. Мы определяем архитектуру, компоненты и то, как эти компоненты сочетаются друг с другом для создания работающей системы.
Стадия проектирования
При проектировании системы функции и операции проектирования подробно описываются, включая макеты экранов, бизнес-правила, диаграммы процессов и другую документацию. Результат этого этапа будет описывать новую систему как набор модулей или подсистем.
Этап строительства
Это этап разработки. Мы начинаем генерацию кода на основе дизайна системы с использованием компиляторов, интерпретаторов, отладчиков для воплощения системы в жизнь.
Реализация
Реализация - это часть стадии строительства. На этом этапе мы начинаем генерацию кода на основе дизайна системы с использованием компиляторов, интерпретаторов, отладчиков, чтобы оживить систему.
Этап тестирования
Как доработаны разные части системы; они проходят серию тестов. он тестируется на соответствие требованиям, чтобы убедиться, что продукт действительно удовлетворяет потребности, решаемые на этапе требования.
Планы тестирования и тестовые примеры используются для выявления ошибок и обеспечения работы системы в соответствии со спецификациями.
На этом этапе выполняются различные типы тестирования, такие как модульное тестирование, ручное тестирование, приемочное тестирование и тестирование системы.
Отслеживание дефектов при тестировании
Отчеты о тестировании программного обеспечения используются для сообщения результатов выполненных планов тестирования. В этом случае отчет должен содержать всю тестовую информацию, относящуюся к текущей тестируемой системе. Полнота отчетов будет проверяться на пошаговых занятиях.
Тестирование проекта направлено на достижение двух основных целей:
Обнаруживать сбои и дефекты в системе.
Выявить несоответствие между требованиями и реализацией.
На следующей схеме изображен Defect Tracking Process -
Для достижения основных целей стратегия тестирования предлагаемой системы обычно состоит из четырех уровней тестирования.
Это модульное тестирование, интеграционное тестирование, приемочное тестирование и регрессионное тестирование. В следующих подразделах описаны эти уровни тестирования, какие роли в группе разработчиков отвечают за их разработку и выполнение, а также критерии для определения их полноты.
Развертывание
После завершения фазы тестирования система выпускается и переходит в производственную среду. После тестирования и готовности продукта к развертыванию он официально выпускается на соответствующий рынок. Иногда развертывание продукта происходит поэтапно в соответствии с бизнес-стратегией организации.
Сначала продукт может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде (UAT - пользовательское приемочное тестирование). Затем, основываясь на отзывах, продукт может быть выпущен как есть или с предлагаемыми улучшениями в целевом сегменте рынка.
Пост SDLC процесс
После того, как продукт выпущен на рынок, его обслуживание выполняется для существующей клиентской базы.
Попав в производственную среду, система претерпит изменения из-за необнаруженных ошибок или других неожиданных событий. Система оценивается, и цикл повторяется для обслуживания системы.
Роль бизнес-аналитика в процессе SDLC
Как видно на диаграмме ниже, BA участвует в формировании бизнес-требований и преобразовании их в требования к решению.
Он участвует в переводе функций решения в требования к программному обеспечению. Затем руководит этапом анализа и проектирования, диктует разработку кода, затем следует этапу тестирования во время исправления ошибок в качестве агента изменений в команде проекта и, в конечном итоге, выполняет требования заказчика.
Бизнес-анализ - роли
Роль бизнес-аналитика в ИТ-проекте может быть многогранной. Члены проектной группы могут иметь несколько ролей и обязанностей. В некоторых проектах БА может взять на себя роли аналитика бизнес-аналитики, конструктора баз данных, специалиста по обеспечению качества программного обеспечения, тестировщика и / или инструктора при наличии ограниченных ресурсов.
Координатор проекта, руководитель разработки приложений или разработчик также могут взять на себя роль бизнес-аналитика в конкретных проектах.
Бизнес-анализ во многом перекликается с анализом требований бизнеса к обычному функционированию и оптимизации его функционирования. Некоторые примеры бизнес-анализа:
- Создание бизнес-архитектуры
- Подготовка бизнес-обоснования
- Проведение оценки рисков
- Выявление требований
- Анализ бизнес-процессов
- Документирование требований
Основные роли бакалавра
Ключевая роль большинства бизнес-аналитиков - поддерживать связь между бизнес-разработчиками и техническими разработчиками. Бизнес-аналитики начинают работать вместе с бизнес-клиентами, чтобы собрать / определить требования к системе или процессу для повышения производительности, в то же время работая с техническими группами над проектированием и внедрением системы / процесса.
Как участник
Основная обязанность БА - способствовать развитию бизнес-пользователей / ключевых пользователей в выявлении бизнес-проблем, потребностей и функций, понимать проблемы и требования заинтересованных сторон для определения возможностей улучшения и вносить бизнес-вклад в разработку бизнес-обоснования для ИТ. проект развития системы.
Как фасилитатор
Бизнес-аналитик также должен способствовать / координировать выявление и анализ требований, сотрудничать и общаться с заинтересованными сторонами, управлять их ожиданиями и потребностями, а также обеспечивать полноту, однозначность требований и их соответствие бизнес-потребностям в реальном времени. организации.
Как аналитик
Другая важная роль будет заключаться в оценке предлагаемой системы и готовности организации к внедрению системы, а также в предоставлении поддержки пользователям и координации с ИТ-персоналом.
Чтобы помочь проанализировать и внести вклад в проектирование предлагаемой ИТ-системы с точки зрения бизнеса, разрешить проблемы / конфликты между заинтересованными сторонами, помочь организовать комплексную и качественную UAT, помогая пользователям в разработке тестовых примеров, а также помогая организовать обучение с целью обеспечения развернутая ИТ-система, способная удовлетворить потребности и требования бизнеса, а также реализовать ожидаемые преимущества.
Планирование и мониторинг деятельности по бизнес-анализу для разработки объема, графика и подхода к выполнению действий, связанных с бизнес-анализом для проекта разработки ИТ-системы, отслеживание хода выполнения, координация с внутренним менеджером проекта и создание отчетов о доходах, прибыльности, рисках и проблемах везде подходящее.
Ключевые обязанности бизнес-аналитика
Набор ответственности бизнес-аналитика потребует от него выполнения различных обязанностей на разных этапах проекта, и они поясняются ниже -
Фаза инициации
Эта фаза станет началом нового проекта, и бизнес-аналитик будет выполнять следующие обязанности:
- Помощь в проведении анализа рентабельности проекта.
- Понять бизнес-кейс.
- Убедитесь в целесообразности решения / проекта / продукта.
- Помощь в создании устава проекта.
- Определите заинтересованные стороны в проекте.
Фаза планирования
Эта фаза будет включать сбор требований и планирование того, как проект будет выполняться и управляться. В его обязанности будут входить следующие функции:
- Выявление требований
- Анализируйте, систематизируйте и документируйте требования.
- Управляйте требованиями, создавая варианты использования, RTM, BRD, SRS и т. Д.
- Оцените предлагаемые решения.
- Поддерживайте связь и улучшайте взаимодействие с заинтересованными сторонами.
- Помощь в составлении планов управления проектом.
- Помощь в определении объема проекта, ограничений, допущений и рисков.
- Помощь в разработке пользовательского опыта решения.
Фаза выполнения
Этот этап знаменует разработку решения в соответствии с собранными требованиями. В обязанности входит:
Объясните требования ИТ-команде / команде разработчиков.
Прояснить сомнения, опасения по поводу предлагаемого решения, которое предстоит разработать.
Обсудите и определите приоритеты изменения содержания проекта и получите согласие.
Создайте сценарии бета-тестирования для первоначального тестирования.
Обмен разрабатываемыми модулями с заинтересованными сторонами и получение их отзывов.
Соблюдение сроков и управление ожиданиями заинтересованных сторон.
Разрешение конфликтов и управление коммуникациями с командой проекта.
Фаза мониторинга и контроля
На этом этапе проект измеряется и контролируется на предмет любых отклонений от первоначальных планов. Этот этап выполняется одновременно с этапом выполнения.
Разработка сценариев тестирования и проведение комплексного модульного и интеграционного тестирования.
Проведение UAT (использование приемочного тестирования) и создание отчетов о тестировании.
Получите одобрение / одобрение результатов от клиента.
Объясните запросы на изменение команде разработчиков.
Следите за развитием запросов на изменения и проверяйте их выполнение в соответствии с целью проекта.
Заключительный этап
Этот этап знаменует собой закрытие проекта. Обязанности -
Представляем заказчику готовый проект и получаем одобрение.
Создавайте учебные пособия для пользователей, любые функциональные материалы и другие инструкции.
Проведите детальное интеграционное тестирование в производственной среде.
Создавайте окончательную документацию продукта, документируйте извлеченные уроки проекта
Что ожидается от BA?
Бизнес-аналитик служит мостом между бизнес-пользователями и техническими ИТ-специалистами. Их присутствие внесет значительный вклад в успех ИТ-проектов. Наличие специального бизнес-аналитика дает множество преимуществ. Специализированный бизнес-аналитик может:
Обеспечивает четкий масштаб проекта с точки зрения бизнеса.
Разработайте обоснованные бизнес-кейсы и более реалистичную оценку ресурсов и выгод для бизнеса.
Готовит более качественные отчеты об объеме проекта, планировании и управлении с точки зрения затрат и графика, особенно для крупномасштабных ИТ-проектов.
Формирует четкие и краткие требования, которые, в свою очередь, помогают предоставить более четкие и точные требования, если ИТ-проект передан на аутсорсинг.
Выявите у пользователей реальные потребности бизнеса и эффективно управляйте ожиданиями пользователей.
Повышает качество проектирования предлагаемой ИТ-системы, чтобы она соответствовала требованиям пользователей.
Обеспечивает качество разработанной системы перед передачей конечным пользователям для проверки и принятия.
Организует всестороннюю проверку качества поставленных систем и обеспечивает обратную связь с техническими специалистами по ИТ.
Бизнес-анализ - инструменты и методы
Бизнес-аналитик должен быть знаком с различными аналитическими инструментами и соответствующими технологиями, когда вы носите шляпу BA. Я имею в виду, если вы занимаетесь этой позицией.
Как мы уже узнали ранее, бизнес-анализ - это процесс, в котором вы пытаетесь понять бизнес-предприятие и выявлять возможности, проблемные области, проблемы и встречаться с широким кругом людей, имеющих широкий спектр ролей и обязанностей, таких как генеральный директор, вице-президент, директор и понимание их бизнес-требований.
По сути, есть 3 типа бизнес-анализа, которые мы можем разделить на следующие категории:
Strategic Analysis- Стратегический бизнес-анализ занимается предпроектной работой. Это метод или процесс выявления бизнес-проблем, разработки бизнес-стратегий, целей и задач, помогающий высшему руководству. Он предоставляет отчеты об управленческой информации для эффективного процесса принятия решений.
Tactical Analysis - Это включает в себя знание конкретных методов бизнес-анализа, которые можно применить в нужное время в соответствующем проекте.
Operational Analysis- В этом типе бизнес-анализа мы фокусируемся на бизнес-аспектах, используя информационные технологии. Это также процесс изучения операционных систем с целью выявления возможностей для улучшения бизнеса.
Для каждого типа анализа существует набор инструментов, доступных на рынке, и их следует использовать в зависимости от потребностей и требований организации.
Тем не менее, чтобы воплотить бизнес-требования в понятную информацию, хороший бакалавр в своей повседневной деятельности будет использовать методы установления фактов, интервью, анализа документации, анкетирования, выборки и исследования.
Функциональные и нефункциональные требования
Мы можем разбить требование на два основных типа, например, функциональные и нефункциональные требования.
Для всех технологических проектов функциональные и нефункциональные требования должны быть разделены и проанализированы отдельно.
Определить правильный инструмент и подходящую технику может оказаться непростой задачей. Независимо от того, создаете ли вы новое приложение или вносите изменения в существующее приложение. Обдумать правильную технику функционального процесса - само по себе искусство.
Обзор широко используемых методов бизнес-анализа, имеющихся в настоящее время на рынке -
Процессы | Методы | Результаты процесса (результаты) |
---|---|---|
Для определения функциональных и нефункциональных требований |
|
Business Requirements Documents -
Common Template -
|
Применимость инструментов и процесса
Хотя существует множество инструментов и процедур, доступных бизнес-аналитикам, все зависит от текущей практики организации и того, как они хотели бы ее использовать.
Например, root-cause analysis используется, когда необходимо углубиться в определенную важную область или функцию.
Однако документ с бизнес-требованиями - самый популярный и общепринятый способ изложить требования в формате документации.
В следующих главах мы подробно обсудим некоторые из вышеперечисленных методов.
Бизнес-анализ - сессия JAD
Совместная разработка приложений (JAD) - это процесс, используемый для сбора бизнес-требований при разработке новых информационных систем для компании. Процесс JAD также может включать подходы для расширения участия пользователей, ускорения разработки и повышения качества спецификаций. Целью JAD-сессии является объединение профильных экспертов / бизнес-аналитиков или ИТ-специалистов для выработки решений.
Бизнес-аналитик - это тот, кто взаимодействует со всей группой и собирает информацию, анализирует ее и выдает документ. Он играет очень важную роль в сеансе JAD.
Использование сеанса JAD
Сессии JAD - это хорошо структурированные семинары, на которых собираются лица, принимающие решения для клиентов, и ИТ-персонал для получения высококачественных результатов в короткие сроки.
Другими словами, сеанс JAD позволяет клиентам и разработчикам быстро прийти к соглашению об основных объемах, целях и спецификациях проекта или, в случае несогласия, прийти к соглашению, что означает необходимость повторной оценки проекта.
Проще говоря, сеансы JAD могут
Simplify - Он объединяет месяцы встреч и телефонных звонков в структурированный семинар.
Identify - Проблемы и участники
Quantify - Потребности в информации и обработке
Clarify - Кристаллизовать и прояснить все требования, согласованные на сеансе.
Unify - Результаты одного этапа разработки используются для следующего.
Satisfy- Заказчики определяют систему; следовательно, это их система. Совместное участие приносит долю в результате; они стремятся к успеху систем.
Участники сессии JAD
В сеансе JAD участвуют следующие участники:
Исполнительный спонсор
Исполнительный спонсор - это человек, который руководит проектом ─ владелец системы. Обычно они занимают более высокие должности и могут принимать решения и обеспечивать необходимую стратегию, планирование и руководство.
Эксперт предметной области
Это бизнес-пользователи и сторонние эксперты, которые необходимы для успешного семинара. Специалисты в данной области составляют основу сессии JAD. Они будут способствовать изменениям.
Фасилитатор
Он председательствует на собрании; он определяет вопросы, которые можно решить в рамках встречи. Фасилитатор не передает информацию на встречу.
Ключевые пользователи
Ключевые пользователи, или также называемые суперпользователями, в некоторых случаях использовались взаимозаменяемыми и все еще различаются от компании к компании. Ключевыми пользователями обычно являются бизнес-пользователи, которые более тесно связаны с ИТ-проектом и несут ответственность за настройку профилей членов своей группы во время проектов.
Например: предположим, что Джон - ключевой пользователь, а Нэнси и Эван - пользователи системы SAP. В этом случае Нэнси и Эван не имеют доступа к изменению функциональности и профиля, тогда как Джон, являющийся ключевым пользователем, имеет доступ к редактированию профиля с дополнительными полномочиями.
Считается, что подход JAD, по сравнению с более традиционной практикой, приводит к сокращению времени разработки и большему удовлетворению запросов клиентов, поскольку клиент участвует на протяжении всего процесса разработки. Для сравнения: при традиционном подходе к разработке систем разработчик изучает системные требования и разрабатывает приложение, при этом клиентский вклад состоит из серии интервью.
Методы сбора требований
Методы описывают, как задачи выполняются в конкретных обстоятельствах. Задача может не иметь одного или нескольких связанных методов. Техника должна быть связана хотя бы с одной задачей.
Ниже приведены некоторые из хорошо известных методов сбора требований.
Мозговой штурм
Мозговой штурм используется при сборе требований, чтобы получить как можно больше идей от группы людей. Обычно используется для определения возможных решений проблем и уточнения деталей возможностей.
Анализ документов
Обзор документации существующей системы может помочь при создании документа процесса AS – IS, а также при анализе пробелов для определения объема проектов миграции. В идеальном мире мы бы даже пересматривали требования, которые привели к созданию существующей системы - отправную точку для документирования текущих требований. Крупицы информации часто скрываются в существующих документах, которые помогают нам задавать вопросы в рамках проверки полноты требований.
Фокус-группа
Фокус-группа - это собрание людей, которые представляют пользователей или клиентов продукта для получения обратной связи. Обратная связь может быть собрана о потребностях / возможностях / проблемах для определения требований или может быть собрана для проверки и уточнения уже выявленных требований. Эта форма исследования рынка отличается от мозгового штурма тем, что это управляемый процесс с конкретными участниками.
Анализ интерфейса
Интерфейсы для программного продукта могут быть человеческими или машинными. Интеграция с внешними системами и устройствами - это еще один интерфейс. Подходы к проектированию, ориентированные на пользователя, очень эффективны для создания пригодного для использования программного обеспечения. Анализ интерфейса - изучение точек соприкосновения с другими внешними системами важно, чтобы убедиться, что мы не упускаем из виду требования, которые не сразу видны пользователям.
Интервью
Опрос заинтересованных сторон и пользователей имеет решающее значение для создания отличного программного обеспечения. Без понимания целей и ожиданий пользователей и заинтересованных сторон мы вряд ли сможем их удовлетворить. Мы также должны осознавать точку зрения каждого респондента, чтобы мы могли правильно взвесить и учесть их мнения. Слушание - это навык, который помогает отличному аналитику получить больше пользы от интервью, чем среднему аналитику.
Наблюдение
Наблюдая за пользователями, аналитик может определить поток процесса, шаги, болевые точки и возможности для улучшения. Наблюдения могут быть пассивными или активными (задавание вопросов во время наблюдения). Пассивное наблюдение лучше для получения обратной связи по прототипу (для уточнения требований), где активное наблюдение более эффективно для понимания существующего бизнес-процесса. Можно использовать любой подход.
Прототипирование
Прототипирование - это относительно современный метод сбора требований. При таком подходе вы собираете предварительные требования, которые используете для создания начальной версии решения - прототипа. Вы показываете это клиенту, который затем предъявляет вам дополнительные требования. Вы меняете приложение и снова работаете с клиентом. Этот повторяющийся процесс продолжается до тех пор, пока продукт не будет удовлетворять критическую массу бизнес-потребностей или согласованное количество итераций.
Требование семинаров
Семинары могут быть очень эффективными для сбора требований. Более структурированный, чем мозговой штурм, вовлеченные стороны сотрудничают для документирования требований. Один из способов зафиксировать сотрудничество - это создание артефактов модели предметной области (например, статических диаграмм, диаграмм действий). Семинар будет эффективнее с двумя аналитиками, чем с одним.
Разобрать механизм с целью понять, как это работает
Когда у проекта миграции нет доступа к достаточной документации по существующей системе, обратный инжиниринг определит, что делает система. Он не определяет, что система должна делать, и не определяет, когда система делает неправильные действия.
Анкетирование
При сборе информации от большого количества людей - слишком многих, чтобы проводить собеседование из-за ограничений бюджета и времени, - можно использовать опрос или анкету. Опрос может вынудить пользователей сделать выбор, оценить что-то («Полностью согласен, согласен…») или иметь открытые вопросы, позволяющие отвечать в свободной форме. Дизайн опроса сложен - вопросы могут вызвать предвзятость респондентов.
Документ функциональных требований
Документ функциональных требований (FRD) - это формальное изложение функциональных требований приложения. Он служит той же цели, что и контракт. Здесь разработчики соглашаются предоставить указанные возможности. Клиент соглашается признать продукт удовлетворительным, если он обеспечивает возможности, указанные в FRD.
Функциональные требования фиксируют предполагаемое поведение системы. Такое поведение может быть выражено как услуги, задачи или функции, которые система должна выполнять. Документ должен быть адаптирован к потребностям конкретного проекта. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением.
Документ функциональных требований (FRD) имеет следующие характеристики:
Это демонстрирует, что приложение имеет ценность с точки зрения бизнес-целей и бизнес-процессов в ближайшие несколько лет.
Он содержит полный набор требований к приложению. Он не оставляет места для каких-либо предположений, которые не указаны в FRD.
Это не зависит от решения. ERD - это заявление о том, что приложение должно делать, а не о том, как оно работает. FRD не обязывает разработчиков заниматься дизайном. По этой причине любые ссылки на использование определенной технологии в FRD совершенно неуместны.
Функциональное требование должно включать следующее:
Описание data быть введенным в систему
Описание operations выполняется каждым экраном
Описание work-flows выполняется системой
Описание system reports или другие выходы
Кто может войти в data в систему?
Как система соответствует применимым regulatory requirements?
Функциональная спецификация предназначена для чтения широкой аудиторией. Читатели должны понимать систему, но для понимания этого документа не требуется никаких технических знаний.
Функциональные требования.
Документ бизнес-требований (BRD) состоит из:
Functional Requirements- Документ, содержащий подробные требования к разрабатываемой системе. Эти требования определяют функциональные особенности и возможности, которыми должна обладать система. Убедитесь, что все допущения и ограничения, выявленные в ходе бизнес-обоснования, по-прежнему точны и актуальны.
Business Process Model - Модель текущего состояния процесса (модель «как есть») или концепция того, каким должен стать процесс (модель «быть»).
System Context Diagram - Контекстная диаграмма показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.
Flow Diagrams (as-is or to-be)- Диаграммы графически отображают последовательность операций или движение данных для бизнес-процесса. Одна или несколько блок-схем включены в зависимости от сложности модели.
Business Rules and Data Requirements - Бизнес-правила определяют или ограничивают некоторые аспекты бизнеса и используются для определения ограничений данных, значений по умолчанию, диапазонов значений, количества элементов, типов данных, вычислений, исключений, требуемых элементов и реляционной целостности данных.
Data Models - Диаграммы взаимосвязей сущностей, описания сущностей, диаграммы классов
Conceptual Model - Высокоуровневое отображение различных сущностей бизнес-функции и их взаимосвязи.
Logical Model - Иллюстрирует конкретные сущности, атрибуты и отношения, задействованные в бизнес-функции, и представляет все определения, характеристики и отношения данных в деловой, технической или концептуальной среде.
Data Dictionary and Glossary - Сбор подробной информации об элементах данных, полях, таблицах и других объектах, составляющих модель данных, лежащую в основе базы данных или аналогичной системы управления данными.
Stakeholder Map- Определяет все заинтересованные стороны, которых затрагивает предлагаемое изменение, и их уровень влияния / полномочий в отношении требований. Этот документ разрабатывается на начальном этапе методологии управления проектом (PMM) и принадлежит менеджеру проекта, но должен обновляться командой проекта по мере того, как новые / измененные заинтересованные стороны выявляются на протяжении всего процесса.
Requirements Traceability Matrix - Таблица, иллюстрирующая логические связи между отдельными функциональными требованиями и другими типами системных артефактов, включая другие функциональные требования, сценарии использования / истории пользователей, элементы архитектуры и дизайна, модули кода, тестовые примеры и бизнес-правила.
Спецификация требований к программному обеспечению
Спецификация требований к программному обеспечению (SRS) - это документ, который используется в качестве средства связи между клиентами. Спецификация требований к программному обеспечению в своей основной форме - это формальный документ, используемый для передачи требований к программному обеспечению между заказчиком и разработчиком.
Документ SRS концентрируется на WHAT нужно делать и тщательно избегайте раствора (how to do). Он служит контрактом между командой разработчиков и заказчиком. Требования на этом этапе написаны с использованием терминологии конечного пользователя. При необходимости позже на его основе будет разработано формальное техническое задание.
SRS - это полное описание поведения разрабатываемой системы и может включать набор сценариев использования, описывающих взаимодействия пользователей с программным обеспечением.
Назначение SRS
SRS - это инструмент связи между клиентом / клиентом, бизнес-аналитиком, разработчиками системы, группами обслуживания. Это также может быть договор между покупателем и поставщиком.
- Это даст прочную основу для этапа проектирования.
- Поддерживает управление и контроль проекта
- Помогает в управлении и развитии системы
Спецификация требований к программному обеспечению должна быть полной, непротиворечивой, отслеживаемой, однозначной и проверяемой.
Следующее должно быть рассмотрено в спецификации системы -
- Определите функции систем
- Определение функционального разбиения аппаратного и программного обеспечения
- Определите спецификацию производительности
- Определите разделение производительности аппаратного / программного обеспечения
- Определить требования безопасности
- Определите пользовательский интерфейс (руководство пользователя)
- Предоставьте установочные чертежи / инструкции
- Шаблон спецификации требований к программному обеспечению
лист регистраций изменений
Свидание | Описание | Автор | Комментарии |
---|---|---|---|
<дата> | <Версия 1> | <Ваше имя> | <Первая редакция> |
Утверждение документа
Следующая спецификация требований к программному обеспечению была принята и одобрена следующими организациями:
Подпись | Напечатанное имя | заглавие | Свидание |
---|---|---|---|
<Ваше имя> | Lead Software Eng. | ||
Дэвид | Инструктор | ||
Бизнес-анализ - сценарии использования
Одна из девяти диаграмм UML - это диаграмма вариантов использования. Это не только важные, но и необходимые требования для программных проектов. Он в основном используется в жизненных циклах программного обеспечения. Как мы знаем, в цикле разработки есть различные фазы, и наиболее часто используемая фаза для вариантов использования - это фаза сбора требований.
Что такое вариант использования?
Вариант использования описывает последовательность действий, выполняемых системой, которая обеспечивает ценность для субъекта. Вариант использования описывает поведение системы в различных условиях, когда она отвечает на запрос от одного из заинтересованных сторон, называемыйprimary actor.
Актер - это Кто в системе, другими словами, он конечный пользователь.
В программной и системной инженерии вариант использования - это список шагов, обычно определяющих взаимодействие между ролью (известной в UML как «субъект») и системой для достижения цели. Актер может быть человеком или внешней системой.
Вариант использования определяет поток событий в системе. Его больше волнует, что выполняет система, чтобы выполнить последовательность действий.
Преимущества варианта использования
Вариант использования обеспечивает следующие преимущества:
Это простой способ уловить функциональные требования с акцентом на добавленную стоимость для пользователя.
Варианты использования относительно легко писать и читать по сравнению с традиционными методами требований.
Сценарии использования заставляют разработчиков думать с точки зрения конечного пользователя.
Вариант использования вовлекает пользователя в процесс требования.
Анатомия варианта использования
Имя : описательное имя, которое иллюстрирует цель варианта использования.
Описание : в двух предложениях описывает, что делает прецедент.
Актер : перечислите всех участников, которые участвуют в прецеденте.
Предварительное условие : условия, которые должны быть выполнены перед запуском варианта использования.
Поток событий : Описание взаимодействия между системой и действующим лицом.
Состояние публикации : Опишите состояние системы после того, как вариант использования отработал.
Руководство по шаблону варианта использования
Документируйте каждый вариант использования, используя шаблон, приведенный в конце этой главы. В этом разделе содержится описание каждого раздела в шаблоне варианта использования.
Идентификация варианта использования
Use-Case ID- Дайте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования могут быть сгруппированы в иерархии. Функциональные требования можно проследить до помеченного варианта использования.
Use-Case Name- Назовите краткое, ориентированное на результат название варианта использования. Они отражают задачи, которые необходимо выполнить пользователю с помощью системы. Включите глагол действия и существительное. Некоторые примеры -
Просмотр информации о номере детали.
Отметьте источник гипертекста вручную и установите ссылку на цель.
Оформите заказ на компакт-диск с обновленной версией ПО.
История вариантов использования
Здесь мы упоминаем имена людей, которые являются заинтересованными сторонами документа Usecase.
Created By - Укажите имя человека, который изначально задокументировал этот вариант использования.
Date Created - Введите дату, когда вариант использования был изначально задокументирован.
Last Updated By - Укажите имя человека, выполнившего самое последнее обновление описания варианта использования.
Date Last Updated - Введите дату последнего обновления варианта использования.
Определение варианта использования
Ниже приведены определения ключевых понятий варианта использования.
Актер
Актер - это физическое или иное лицо, внешнее по отношению к указанной программной системе, которое взаимодействует с системой и выполняет сценарии использования для выполнения задач. Разные участники часто соответствуют разным классам или ролям пользователей, определенным из сообщества клиентов, которые будут использовать продукт. Назовите актера (ов), который будет выполнять этот сценарий использования.
Описание
Предоставьте краткое описание причины и результата этого варианта использования или высокоуровневое описание последовательности действий и результата выполнения этого варианта использования.
Предварительные условия
Перечислите все действия, которые должны быть выполнены, или любые условия, которые должны выполняться, прежде чем можно будет запустить вариант использования. Пронумеруйте каждое предварительное условие.
Examples
- Личность пользователя подтверждена.
- На компьютере пользователя достаточно свободной памяти для запуска задачи.
Условия публикации
Опишите состояние системы по завершении выполнения варианта использования. Пронумеруйте каждое условие сообщения.
Examples
- Документ содержит только действительные теги SGML.
- Цена товара в базе обновлена новым значением.
Приоритет
Укажите относительный приоритет реализации функций, необходимых для выполнения этого варианта использования. Используемая схема приоритетов должна быть такой же, как и в спецификации требований к программному обеспечению.
Частота использования
Оцените, сколько раз этот вариант использования будет выполняться субъектами за некоторую соответствующую единицу времени.
Нормальный ход событий
Предоставьте подробное описание действий пользователя и ответов системы, которые будут иметь место во время выполнения варианта использования в нормальных ожидаемых условиях. Эта последовательность диалоговых окон в конечном итоге приведет к достижению цели, указанной в имени и описании варианта использования. Это описание может быть написано как ответ на гипотетический вопрос: «Как мне <выполнить задачу, указанную в имени варианта использования>?» Лучше всего это сделать в виде нумерованного списка действий, выполняемых субъектом, чередующихся с ответами, предоставляемыми системой.
Альтернативные курсы
Документируйте другие, законные сценарии использования, которые могут иметь место в рамках этого варианта использования, отдельно в этом разделе. Укажите альтернативный курс и опишите любые различия в последовательности выполняемых шагов. Пронумеруйте каждый альтернативный курс, используя ID варианта использования в качестве префикса, за которым следует «AC», чтобы указать «Альтернативный курс». Пример: XYAC.1.
Исключения
Опишите любые ожидаемые условия ошибки, которые могут возникнуть во время выполнения варианта использования, и определите, как система должна реагировать на эти условия. Также опишите, как система должна реагировать, если выполнение варианта использования не удается по какой-то непредвиденной причине. Пронумеруйте каждое исключение, используя идентификатор варианта использования в качестве префикса, за которым следует «EX», чтобы указать «Исключение». Пример: XYEX.1.
Включает в себя
Перечислите любые другие варианты использования, которые включены («вызваны») этим вариантом использования. Общие функции, которые появляются в нескольких вариантах использования, могут быть выделены в отдельный вариант использования, который включается теми, кому нужна эта общая функциональность.
Специальные требования
Определите любые дополнительные требования, такие как нефункциональные требования, для варианта использования, которые могут потребоваться учесть во время проектирования или реализации. Они могут включать требования к характеристикам или другие атрибуты качества.
Предположения
Перечислите все допущения, сделанные в ходе анализа, которые привели к включению этого варианта использования в описание продукта и написанию описания варианта использования.
Примечания и проблемы
Перечислите любые дополнительные комментарии об этом варианте использования или любых оставшихся нерешенных проблемах или TBD (подлежат определению), которые необходимо решить. Определите, кто будет решать каждую проблему, срок выполнения и окончательное решение.
Управление изменениями и контроль версий
Контроль версий - это управление изменениями в документах, больших веб-сайтах и другой сбор информации. Изменения обычно обозначаются числовым или буквенным кодом, называемым номером редакции или уровнем редакции. Каждая ревизия связана с меткой времени и лицом, вносящим изменение.
Диаграммы вариантов использования
Важной частью Unified Modeling Language (UML) являются средства для рисования диаграмм вариантов использования. Сценарии использования используются на этапе анализа проекта для определения и разделения функциональности системы. Они разделяют систему на участников и сценарии использования. Актеры представляют роли, которые могут играть пользователи системы.
Этими пользователями могут быть люди, другие компьютеры, части оборудования или даже другие программные системы. Единственный критерий - они должны быть внешними по отношению к той части системы, которая разбивается на варианты использования. Они должны подавать стимулы в эту часть системы и получать от нее выходные сигналы.
Варианты использования представляют собой действия, которые субъекты выполняют с помощью вашей системы для достижения цели. Нам нужно определить, что этим пользователям (действующим лицам) нужно от системы. Вариант использования должен отражать потребности и цели пользователя и должен инициироваться субъектом. Бизнес, субъекты и клиенты, участвующие в бизнес-прецеденте, должны быть связаны с прецедентом путем ассоциации.
Рисование диаграмм вариантов использования
На рисунке ниже показано, как вариант использования может выглядеть как схематическая форма UML. Сам вариант использования выглядит как овал. Актеры нарисованы в виде маленьких фигурок. Актеры подключаются к варианту использования линиями.
Use-case 1 - Продавец проверяет товар
- Покупатель ставит товар на прилавок.
- «Использует» Swipe UPC Reader.
- Система ищет код UPC в базе данных, закупая описание и цену товара.
- Система издает звуковой сигнал.
- Система объявляет описание товара и цену через голосовой вывод.
- Система добавляет цену и тип позиции к текущему счету.
- Система добавляет цену для правильной налоговой суммы
Итак, отношение «использует» очень похоже на вызов функции или подпрограмму.
Вариант использования, используемый таким образом, называется абстрактным вариантом использования, потому что он не может существовать сам по себе, но должен использоваться другими вариантами использования.
Пример ─ Вариант использования вывода средств
Цель клиента в отношении нашего торгового автомата (банкомата) - снять деньги. Итак, мы добавляемWithdrawalвариант использования. Снятие денег в торговом автомате может потребовать от банка проведения транзакций. Итак, мы также добавляем еще одного актера -Bank. Оба субъекта, участвующие в прецеденте, должны быть связаны с прецедентом путем ассоциации.
Автомат по продаже денег предлагает вариант использования вывода средств для клиентов и сотрудников банка.
Отношения между участниками и сценариями использования
Сценарии использования могут быть организованы с использованием следующих отношений -
- Generalization
- Association
- Extend
- Include
Обобщение между вариантами использования
Могут быть случаи, когда субъекты связаны с аналогичными вариантами использования. В таком случае дочерний вариант использования наследует свойства и поведение родительского использования. Следовательно, нам нужно обобщить актор, чтобы показать наследование функций. Они представлены сплошной линией с большой полой треугольной стрелкой.
Связь между вариантами использования
Связи между участниками и вариантами использования обозначены на диаграммах вариантов использования сплошными линиями. Связь существует всякий раз, когда субъект участвует во взаимодействии, описанном прецедентом.
Расширить
Есть некоторые функции, которые запускаются по желанию. В таких случаях используется отношение расширения, и к нему прикрепляется правило расширения. Следует помнить, что базовый вариант использования должен иметь возможность выполнять функцию самостоятельно, даже если расширяющийся вариант использования не вызывается.
Отношение расширения показано пунктирной линией с открытой стрелкой, направленной от расширяющего варианта использования к расширенному (базовому) варианту использования. Стрелка помечена ключевым словом «расширить».
Включают
Он используется для извлечения фрагментов вариантов использования, которые дублируются в нескольких вариантах использования. Он также используется для упрощения большого варианта использования путем разделения его на несколько вариантов использования и для выделения общих частей поведения двух или более вариантов использования.
Включите взаимосвязь между вариантами использования, которая показана пунктирной стрелкой с открытой стрелкой от базового варианта использования к включенному варианту использования. Стрелка помечена ключевым словом «включить».
Варианты использования касаются только функциональных требований к системе. Другие требования, такие как бизнес-правила, требования к качеству обслуживания и ограничения реализации, должны быть представлены отдельно.
Диаграмма, показанная ниже, является примером простой диаграммы вариантов использования со всеми отмеченными элементами.
Основные принципы успешного применения сценариев использования
- Будьте проще, рассказывая истории
- Будьте продуктивны без совершенства
- Понять общую картину
- Определите возможность повторного использования для сценариев использования
- Сосредоточьтесь на ценности
- Постройте систему по частям
- Доставка системы поэтапно
- Адаптируйтесь под нужды команды
Шаблон варианта использования
Здесь мы показали образец шаблона варианта использования, который может заполнить бизнес-аналитик, чтобы эта информация могла быть полезна технической группе для получения информации о проекте.
ID варианта использования: | |||
Имя варианта использования: | |||
Создан: | Автор последнего обновления | ||
Дата создания: | Дата последнего обновления | ||
Актер: | |||
Описание: | |||
Предварительные условия: | |||
Условия размещения: | |||
Приоритет: | |||
Частота использования: | |||
Нормальный ход событий: | |||
Альтернативные курсы: | |||
Исключения: | |||
Включает в себя: | |||
Специальные требования: | |||
Предположения: | |||
Примечания и вопросы: |
Бизнес-анализ - Требования Mngmt
Сбор требований к программному обеспечению - это основа всего проекта разработки программного обеспечения. Запрос и сбор бизнес-требований - важный первый шаг для каждого проекта. Чтобы преодолеть разрыв между бизнес-требованиями и техническими требованиями, бизнес-аналитики должны полностью понимать потребности бизнеса в данном контексте, согласовывать эти потребности с бизнес-целями и должным образом сообщать о потребностях как заинтересованным сторонам, так и команде разработчиков.
Ключевые заинтересованные стороны хотят, чтобы кто-нибудь мог объяснить требования клиента / клиента на простом английском языке. Пойдет ли им на пользу понимание ценности на высоком уровне? Это будет основная область внимания, поскольку они попытаются сопоставить документацию с требованиями и тем, как BA может общаться наилучшим образом.
Почему проекты терпят неудачу
Есть много причин, по которым проекты терпят неудачу, но некоторые из общих областей включают следующее:
- Провал рынка и стратегии
- Организационные и плановые сбои
- Провалы качества
- Неудачи в лидерстве и управлении
- Отсутствие навыков, знаний и компетенций
- Вовлеченность, командная работа и сбои в общении
Суть проблемы заключается в том, что проекты становятся все более сложными, происходят изменения и коммуникация становится сложной.
Почему успешные команды занимаются управлением требованиями
Управление требованиями - это сохранение вашей команды in-sync и предоставление visibility к тому, что происходит в рамках проекта.
Для успеха ваших проектов крайне важно, чтобы вся ваша команда понимала, что вы создаете и почему - именно так мы определяем управление требованиями. «Почему» важно, потому что оно обеспечивает контекст для целей, обратной связи и решений, принимаемых в отношении требований.
Это увеличивает предсказуемость будущего успеха и потенциальных проблем, позволяя вашей команде быстро исправить любые проблемы и успешно завершить проект вовремя и в рамках бюджета. В качестве отправной точки для всех участников важно иметь базовое представление о том, что такое требования и как ими управлять.
Начнем с основ
Требование - это условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели. Условие или возможность, которым должна соответствовать или которыми должна обладать система или система. Компонент для выполнения контракта, стандарта, спецификации или других формально установленных документов.
Требование может быть выражено с помощью текста, набросков, подробных макетов или моделей, любой информации, которая лучше всего передает инженеру, что строить, и QA-менеджеру, что тестировать. В зависимости от вашего процесса разработки вы можете использовать разную терминологию для определения требований.
Требования высокого уровня иногда называют просто needs или же goals. В практике разработки программного обеспечения требования могут называться «сценариями использования», «функциями» или «функциональными требованиями». Даже более конкретно в методологиях гибкой разработки требования часто фиксируются какepics и stories.
Независимо от того, как их называет ваша команда или какой процесс вы используете; требования необходимы для разработки всех продуктов. Без четкого определения требований вы можете произвести неполный или дефектный продукт. В процессе определения требований может участвовать много людей.
Заинтересованная сторона может запросить функцию, которая описывает, как продукт будет иметь ценность при решении проблемы. Разработчик может определить требование на основе того, как конечный продукт должен выглядеть или работать с точки зрения удобства использования или пользовательского интерфейса.
Бизнес-аналитик может создать системное требование, которое соответствует определенным техническим или организационным ограничениям. Для современных сложных продуктов и программных приложений часто требуются сотни или тысячи требований, чтобы в достаточной степени определить объем проекта или выпуска. Таким образом, крайне важно, чтобы команда имела возможность получать доступ, сотрудничать, обновлять и тестировать каждое требование до завершения, поскольку требования естественным образом меняются и развиваются с течением времени в процессе разработки.
Теперь, когда мы определили ценность управления требованиями на высоком уровне, давайте углубимся в четыре основных принципа, понимание которых может быть полезно каждому члену команды и заинтересованной стороне:
- Планирование хороших требований: «Что, черт возьми, мы строим?»
- Сотрудничество и участие: «Просто утвердите спецификацию, уже!»
- Прослеживаемость и управление изменениями: «Подождите, а разработчики знают, что изменилось?»
- Гарантия качества: «Здравствуйте, а кто-нибудь тестировал эту штуку?»
Все знают, что мы строим и почему? В этом ценность управления требованиями.
Сотрудничество и поддержка заинтересованных сторон
Все в курсе? Есть ли у нас одобрение требований для продвижения вперед? Эти вопросы возникают во время цикла разработки. Было бы здорово, если бы все могли согласовать требования, но для крупных проектов с большим количеством заинтересованных сторон этого обычно не происходит. Попытка добиться согласия всех может привести к тому, что решения будут отложены или, что еще хуже, вообще не будут приняты. Достичь консенсуса по каждому решению не всегда легко.
На практике вам не обязательно нужен «консенсус», вам нужна «поддержка» со стороны группы и одобрение со стороны тех, кто контролирует, чтобы вы могли продвигать проект вперед. При консенсусе вы пытаетесь заставить всех пойти на компромисс и согласиться с решением. Приобретая участие, вы пытаетесь убедить людей поддержать лучшее решение, принять разумное решение и сделать все необходимое для продвижения вперед.
Вам не нужно, чтобы все соглашались с тем, что решение является лучшим. Вам нужно, чтобы все поддержали это решение. Командное сотрудничество может помочь в получении поддержки при принятии решений и в планировании хороших требований.
Совместные команды прилагают все усилия, чтобы убедиться, что все заинтересованы в проектах и предоставляют отзывы. Совместные команды постоянно обмениваются идеями, обычно лучше общаются и склонны поддерживать принятые решения, потому что существует общее чувство приверженности и понимания целей проекта.
Когда разработчики, тестировщики или другие заинтересованные стороны чувствуют себя «не в курсе», возникают проблемы с коммуникацией, люди разочаровываются и проекты задерживаются. После того, как все согласились с объемом работ, необходимо, чтобы требования были четкими и хорошо задокументированными. Отслеживание всех требований - вот где все усложняется.
Представьте, что у вас есть список дел длиной в милю, который предполагает совместную работу с несколькими людьми. Как бы вы удерживали все эти предметы в порядке? Как бы вы отследили, как одно изменение элемента повлияет на остальную часть проекта? Здесь добавляются преимущества прослеживаемости и управления изменениями.
Планирование хороших требований
Итак, что делает требование хорошим? Хорошее требование должно быть ценным и действенным; он должен определять потребность, а также указывать путь к решению. Все в команде должны понимать, что это значит. Требования различаются по сложности.
Хороший документ с требованиями может быть частью группы с высокоуровневыми требованиями, разбитыми на подзапросы.
Они также могут включать очень подробные спецификации, которые включают набор функциональных требований, описывающих поведение или компоненты конечного продукта.
Хорошие требования должны быть краткими и конкретными и должны отвечать на вопрос: «Что нам нужно?» Вместо того, чтобы «как нам удовлетворить потребность?»
Хорошие требования гарантируют, что все заинтересованные стороны понимают свою часть плана; если детали неясны или неправильно истолкованы, конечный продукт может быть неисправным или неисправным.
Предотвратить сбой или неправильную интерпретацию требований можно, если получать обратную связь от команды на протяжении всего процесса по мере развития требований. Постоянное сотрудничество и взаимопонимание со всеми - ключ к успеху.
Сбор и анализ требований
Требование - это условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения организационной цели; условие или способность, которые должны выполняться или которыми должна обладать система.
Анализ требований в разработке программного обеспечения охватывает те задачи, которые входят в определение потребностей или условий, которым должен соответствовать новый или измененный продукт, с учетом возможных конфликтующих требований различных заинтересованных сторон, анализа, документирования, проверки и управления программными или системными требованиями.
Требования должны быть:
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Требования должны быть связаны с выявленными бизнес-потребностями или возможностями и определены с уровнем детализации, достаточным для проектирования системы.
Бизнес-аналитик собирает информацию, наблюдая за существующими системами, изучая существующие процедуры, обсуждая с клиентами и конечными пользователями. Аналитик также должен обладать воображением и творческими способностями при отсутствии работающей Системы. Анализ собранных требований для поиска недостающих звеньев - это анализ требований.
Выявляющий подход
Чтобы определить цели, задайте бизнес-эксперту, менеджеру по развитию и спонсору проекта следующие вопросы:
Какие бизнес-цели компании поможет решить этот проект?
Почему мы сейчас делаем этот проект?
Что будет, если мы сделаем это позже?
Что, если мы вообще этого не сделаем?
Кому будет полезен этот проект?
Считают ли люди, которым это принесет пользу, это самое важное улучшение, которое возможно сделать в настоящее время?
Должны ли мы вместо этого делать другой проект?
Возможные цели могут заключаться в снижении затрат, улучшении обслуживания клиентов, упрощении рабочего процесса, замене устаревшей технологии, пилотировании новой технологии и многих других. Кроме того, убедитесь, что вы точно понимаете, как предлагаемый проект поможет достичь поставленной цели.
Различные типы требований
Наиболее распространенные типы требований, которые интересуют бизнес-аналитика, следующие:
Бизнес-требования
Бизнес-требования - это критически важные действия предприятия, которые должны выполняться для достижения целей организации, оставаясь при этом независимыми от решений. Документ бизнес-требований (BRD) подробно описывает бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиентов.
Требования пользователя
Требования пользователя должны определять конкретные требования, которые пользователь ожидает / хочет от программного обеспечения, которое будет построено на основе программного проекта. Требования пользователя должны быть проверяемыми, ясными и краткими, полными, последовательными, отслеживаемыми, жизнеспособными.
Документ требований пользователя (URD) или спецификация требований пользователя - это документ, обычно используемый в разработке программного обеспечения, который определяет, что пользователь ожидает от программного обеспечения.
Системные Требования
Системные требования касаются определения требований к программным ресурсам и предварительных условий, которые необходимо установить на компьютер для обеспечения оптимального функционирования приложения.
Функциональные требования
Функциональные требования фиксируют и определяют конкретное предполагаемое поведение разрабатываемой системы. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением, а также другие конкретные функции, которые показывают, как удовлетворяются требования пользователя. Назначьте уникальный идентификационный номер каждому требованию.
Нефункциональные требования
Нефункциональное требование - это требование, которое определяет критерии, которые могут использоваться для оценки работы системы, а не конкретного поведения. Системная архитектура говорит о плане реализации нефункциональных требований.
Нефункциональные требования говорят о том, как должна выглядеть система, или о том, что «система должна быть». Нефункциональные требования называются качествами системы.
Требования к переходу
Требования к переходу описывают возможности, которые должно выполнять решение, чтобы облегчить переход от текущего состояния предприятия к желаемому будущему состоянию, но это не понадобится после завершения перехода.
Они отличаются от требований других типов, поскольку они всегда временны по своей природе и не могут быть разработаны до тех пор, пока не будут определены как существующее, так и новое решение. Обычно они охватывают преобразование данных из существующих систем, пробелы в навыках, которые необходимо устранить, и другие связанные изменения для достижения желаемого будущего состояния. Они разрабатываются и определяются посредством оценки и проверки решения.
Прослеживаемость и управление изменениями
Прослеживаемость требований - это способ организации, документирования и отслеживания всех ваших требований от первоначальной идеи до этапа тестирования.
Матрица возможности отслеживания требований (RTM) предоставляет метод отслеживания функциональных требований и их реализации в процессе разработки. Каждое требование включено в матрицу вместе с соответствующим номером раздела.
По мере продвижения проекта RIM обновляется, чтобы отразить статус каждого требования. Когда продукт готов к системному тестированию, в матрице перечисляются каждое требование, какой компонент продукта отвечает ему и какой тест подтверждает его правильность.
Включите столбцы для каждого из следующих в RTM -
- Описание требования
- Ссылка на требование в FRD
- Метод проверки
- Ссылка на требование в плане тестирования
Example- Соединение точек для определения взаимосвязей между элементами в вашем проекте. Это соединитель общего нисходящего потока.
Идея Требования Дизайн Тест Бизнес-цели
Вы должны иметь возможность проследить каждое из своих требований до его исходной бизнес-цели.
Отслеживая требования, вы можете определить, какое влияние оказывают изменения, посмотреть, выполнено ли требование и правильно ли оно тестируется. Прослеживаемость и управление изменениями обеспечивает менеджерам душевное спокойствие и прозрачность, необходимую для прогнозирования проблем и обеспечения постоянного качества.
Гарантия качества
Правильное выполнение требований с первого раза может означать лучшее качество, более быстрые циклы разработки и более высокую удовлетворенность клиентов продуктом. Управление требованиями не только помогает вам сделать это правильно, но также помогает вашей команде сэкономить деньги и избавиться от многих головных болей на протяжении всего процесса разработки.
Краткие, конкретные требования могут помочь вам обнаружить и исправить проблемы на раннем этапе, а не позже, когда исправить это будет намного дороже. Кроме того, это может стоить до100 times больше для исправления дефекта на более позднем этапе процесса разработки после того, как он был закодирован, чем для исправления на раннем этапе, пока это необходимо.
Интегрируя управление требованиями в свой процесс обеспечения качества, вы можете помочь своей команде повысить эффективность и исключить переделки. Более того, доработка - это то место, где возникает большая часть проблем с затратами.
Другими словами, команды разработчиков тратят большую часть своего бюджета на усилия, которые не выполняются правильно с первого раза. Например, разработчик кодирует функцию на основе старого документа спецификации только для того, чтобы позже узнать, что требования для этой функции изменились. Такого типа проблем можно избежать с помощью передовых методов эффективного управления требованиями.
Таким образом, управление требованиями может показаться сложной дисциплиной, но если свести ее к простой концепции - она помогает командам ответить на вопрос: «Все ли понимают, что мы создаем и почему?» От бизнес-аналитиков, менеджеров по продуктам и руководителей проектов до разработчиков, менеджеров по обеспечению качества и тестировщиков, а также заинтересованных сторон и клиентов - так часто основной причиной неудач проекта является непонимание масштабов проекта.
Когда все сотрудничают и имеют полный контекст и видимость обсуждений, решений и изменений, связанных с требованиями на протяжении всего жизненного цикла проекта, тогда успех достигается постоянно, а вы поддерживаете постоянное качество. Кроме того, процесс стал более плавным, с меньшим трением и разочарованием для всех участников.
Note- Исследования показали, что проектные группы могут устранить 50-80% дефектов проекта, эффективно управляя требованиями. По данным института программной инженерии Карнеги-Меллона, «60-80% стоимости разработки программного обеспечения приходится на доработку».
Получение подтверждения требований
Утверждение требований формализует согласие заинтересованных сторон проекта о том, что содержание и представление требований, задокументированных, являются точными и полными. Формальное соглашение снижает риск того, что во время или после реализации заинтересованная сторона представит новое (ранее не встречавшееся) требование.
Получение подтверждения требований обычно включает в себя окончательный очный обзор требований, задокументированных, с каждой заинтересованной стороной проекта. В конце каждого обзора заинтересованную сторону просят официально утвердить проверенный документ с требованиями. Это разрешение может быть записано как физически, так и в электронном виде.
Получение подтверждения требований обычно является последней задачей в рамках Коммуникации требований. Бизнес-аналитик потребует выходные данные обзора (ов) формальных требований, включая учет любых комментариев или возражений, которые были высказаны в процессе проверки.
Бизнес-анализ - Моделирование
Бизнес-модель может быть определена как представление бизнеса или решения, которое часто включает графический компонент вместе с вспомогательным текстом и связями с другими компонентами. Например, если нам нужно понять бизнес-модель компании, мы хотели бы изучить следующие области, такие как:
- Основные ценности компании
- Что это служит?
- Что отличает?
- Его ключевые ресурсы
- Основные отношения
- Каналы доставки
С помощью методов моделирования мы можем создать полное описание существующих и предлагаемых организационных структур, процессов и информации, используемой предприятием.
Бизнес-модель - это структурированная модель, подобная плану разработки конечного продукта. Это дает структуру и динамику для планирования. Он также обеспечивает основу для конечного продукта.
Цель бизнес-моделирования
Бизнес-моделирование используется для проектирования текущего и будущего состояния предприятия. Эта модель используется бизнес-аналитиком и заинтересованными сторонами, чтобы убедиться, что они имеют точное представление о текущей модели предприятия «как есть».
Он используется, чтобы проверить, есть ли у заинтересованных сторон общее понимание предлагаемого «будущего решения».
Анализ требований является частью процесса бизнес-моделирования и является основной областью внимания. Функциональные требования собираются в «Текущем состоянии». Эти требования предоставляются заинтересованными сторонами в отношении бизнес-процессов, данных и бизнес-правил, которые описывают желаемую функциональность, которая будет разработана в Будущем состоянии.
Выполнение GAP-анализа
После определения бизнес-потребностей необходимо определить текущее состояние (например, текущие бизнес-процессы, бизнес-функции, особенности текущей системы и предлагаемые услуги / продукты и события, на которые система должна реагировать), чтобы понять, как люди, процессы и технологии, структура и архитектура поддерживают бизнес, запрашивая мнение ИТ-персонала и других заинтересованных сторон, включая владельцев бизнеса.
Затем выполняется анализ пробелов, чтобы оценить, есть ли какие-либо пробелы, которые мешают достижению бизнес-потребностей, путем сравнения идентифицированного текущего состояния с желаемыми результатами.
Если пробелов нет (т. Е. Текущее состояние соответствует потребностям бизнеса и желаемым результатам), вероятно, нет необходимости запускать ИТ-проект. В противном случае следует выявить проблемы / вопросы, которые необходимо решить, чтобы восполнить пробел.
Можно использовать такие методы, как SWOT-анализ (сильные и слабые стороны, возможности и угрозы) и анализ документов.
Для оценки предлагаемой системы
BA должен помочь команде ИТ-проекта в оценке предлагаемой ИТ-системы, чтобы убедиться, что она соответствует потребностям бизнеса и максимизирует ценности, предоставляемые заинтересованным сторонам. BA также должен проверить готовность организации поддержать переход к предлагаемой ИТ-системе, чтобы обеспечить плавное внедрение системы.
BA должен помочь команде ИТ-проекта определить, могут ли предлагаемый вариант системы и проект системы верхнего уровня удовлетворить потребности бизнеса и обеспечить достаточную коммерческую ценность, чтобы оправдать инвестиции. Если существует более одного варианта системы, BA должен работать с ИТ-персоналом, чтобы помочь определить плюсы и минусы каждого варианта и выбрать вариант, который обеспечивает наибольшую ценность для бизнеса.
Руководящие принципы бизнес-моделирования
Основная роль бизнес-моделирования в основном проявляется на начальном этапе и на этапах разработки проекта, и оно исчезает на этапе строительства и перехода. В основном это связано с аналитическими аспектами бизнеса в сочетании с техническим картированием приложения или программного решения.
Domain and User variation- Разработка бизнес-модели часто выявляет области разногласий или путаницы между заинтересованными сторонами. Бизнес-аналитику необходимо будет задокументировать следующие варианты модели «как есть».
Multiple work units perform the same function- Задокументируйте отклонения в модели КАК ЕСТЬ. Это могут быть разные подразделения или регионы.
Multiples users perform the same work- Различные заинтересованные стороны могут выполнять аналогичную работу по-разному. Различия могут быть результатом различных наборов навыков и подходов разных бизнес-единиц или результатом различных потребностей внешних заинтересованных сторон, обслуживаемых предприятием. Задокументируйте отклонения в модели AS-IS.
Resolution Mechanism- Бизнес-аналитик должен задокументировать, будет ли решение ToBe учитывать несоответствия в текущей бизнес-модели или решение потребует стандартизации. Заинтересованные стороны должны определить, какой подход им следует придерживаться. Модель To-Be будет отражать их решение.
Пример роли BA в моделировании ERP-систем
Бизнес-аналитик должен определить стандартный бизнес-процесс и настроить его в систему ERP, которая имеет ключевое значение для эффективного внедрения. БА также обязан определить язык разработчиков на понятном языке до реализации, а затем использовать передовой опыт и сопоставить их на основе возможностей системы.
Требование к системе - анализ соответствия GAAP, который должен балансировать между:
Необходимость технических изменений, то есть усовершенствований с целью достижения идентичности с существующей практикой.
Эффективные изменения, связанные с реинжинирингом существующих бизнес-процессов с целью реализации стандартных функций и применения моделей процессов.
Функциональный бизнес-аналитик
Опыт в предметной области обычно приобретается в течение определенного периода, когда он занимается «делом». Например,
А banking associate получает знания о различных типах учетных записей, с которыми может работать клиент (частный и корпоративный), а также подробный поток бизнес-процессов.
An insurance sales representative может понять различные этапы оформления страхового полиса.
А marketing analyst имеет больше шансов понять ключевые заинтересованные стороны и бизнес-процессы, задействованные в системе управления взаимоотношениями с клиентами.
Бизнес-аналитик, занимающийся capital marketsПредполагается, что проект имеет опыт в предметной области и глубокие знания в области акций, фиксированного дохода и деривативов. Также ожидается, что он будет заниматься бэк-офисом, фронт-офисом, практическим опытом применения моделей управления рисками.
А Healthcare Business Analyst Требуется базовое понимание финансовых показателей и показателей использования системы здравоохранения США, технический опыт и понимание EDI 837/835/834, руководящих принципов HIPAA, кодификации ICD - 9/10 и кодов CPT, знания LOINC, SNOMED.
Некоторые бизнес-аналитики получают знания в предметной области, тестируя бизнес-приложения и работая с бизнес-пользователями. Благодаря своим навыкам межличностного общения и анализу они создают благоприятную среду для обучения. В некоторых случаях они дополняют свои знания предметной области несколькими сертификатами предметной области, предлагаемыми AICPCU / IIA и LOMA в области страхования и финансовых услуг. Есть и другие институты, предлагающие сертификацию в других областях.
Прочие основные виды деятельности
После тщательного изучения текущих бизнес-процессов вы сможете предложить высокопрофессиональную помощь в определении оптимального подхода к моделированию системы.
Организация подготовки формализованного и единообразного описания бизнес-процессов таким образом, чтобы обеспечить эффективную автоматизацию в системе.
Помощь вашим командам в заполнении стандартных анкет для соответствующей системы, которые могут быть предоставлены разработчиками.
Определены требования к разработчикам для участия в рабочих встречах.
Проверить и проконтролировать, правильно ли «воспроизведены» и зафиксированы ли установленные вами требования в документах, описывающих будущую модель в системе (Blueprints).
Подготовка данных и помощь в создании прототипа системы.
Помощь в подготовке данных для переноса списков и балансов в требуемый системой формат.
Проверка прототипа сетапа на соответствие требованиям, установленным владельцами бизнес-процессов.
Выступает в качестве ресурса поддержки ваших ИТ-специалистов при подготовке данных и фактическом выполнении функциональных и интеграционных тестов в системе.
В следующем разделе мы кратко обсудим некоторые популярные инструменты бизнес-моделирования, используемые крупными организациями в ИТ-средах.
Инструмент 1: Microsoft Visio
MS-Visio - это программа для рисования и построения диаграмм, которая помогает преобразовывать концепции в визуальное представление. Visio предоставляет вам заранее определенные формы, символы, фон и границы. Просто перетащите элементы на свою диаграмму, чтобы создать профессиональный инструмент коммуникации.
Step 1 - Чтобы открыть новый документ Visio, перейдите в меню «Пуск» и выберите «Программы» → «Visio».
Step 2 - Наведите курсор на «Бизнес-процесс» и выберите «Базовая блок-схема».
На следующем снимке экрана показаны основные разделы приложения MS-Visio.
Давайте теперь обсудим основную полезность каждого компонента -
A- панели инструментов в верхней части экрана похожи на другие программы Microsoft, такие как Word и PowerPoint. Если вы использовали эти программы раньше, вы можете заметить несколько различных функций, которые мы рассмотрим позже.
Выбор галереи справочных диаграмм - хороший способ познакомиться с типами рисунков и диаграмм, которые можно создавать в Visio.
B- В левой части экрана показаны меню, соответствующие типу создаваемой диаграммы. В этом случае мы видим -
- Формы стрел
- Backgrounds
- Основные формы блок-схемы
- Границы и названия
C - В центре экрана отображается рабочее пространство схемы, которое включает в себя фактическую страницу схемы, а также некоторое пустое пространство рядом со страницей.
D- В правой части экрана показаны некоторые справочные функции. Некоторые люди могут закрыть это окно, чтобы увеличить область для рабочего пространства диаграммы, и повторно открыть функции справки при необходимости.
Инструмент 2: Enterprise Architect
Enterprise Architect - это инструмент визуального моделирования и дизайна, основанный на UML. Платформа поддерживает проектирование и создание программных систем, моделирование бизнес-процессов и моделирование отраслевых областей. Бизнес и организации используют его не только для моделирования архитектуры своих систем. Но чтобы обработать реализацию этих моделей на протяжении всего жизненного цикла разработки приложения.
Цель Enterprise Architect - определить, как организация может наиболее эффективно достичь своих текущих и будущих целей.
У архитектора предприятия есть четыре точки зрения, которые заключаются в следующем:
Business perspective - Бизнес-перспектива определяет процессы и стандарты, в соответствии с которыми бизнес работает изо дня в день.
Application Perspective - Перспектива приложения определяет взаимодействие между процессами и стандартами, используемыми организацией.
Information Perspective - Это определяет и классифицирует необработанные данные, такие как файлы документов, базы данных, изображения, презентации и электронные таблицы, которые требуются организации для эффективной работы.
Technology Prospective - Это определяет оборудование, операционные системы, программные и сетевые решения, используемые организацией.
Инструмент 3: Rational Requisite Pro
Процесс выявления, документирования, организации отслеживания и изменения Требований и передачи этой информации между проектными группами, чтобы гарантировать, что повторяющиеся и непредвиденные изменения поддерживаются на протяжении всего жизненного цикла проекта.
Мониторинг статуса и контроль изменений в базовом плане требований. Основными элементами являются контроль изменений и прослеживаемость.
Requisite Pro используется для вышеуказанных действий и целей администрирования проекта, инструмент используется для запросов и поиска, просмотра обсуждений, которые были частью требования.
В Requisite Pro пользователь может работать над документом требований. Документ представляет собой файл MS-Word, созданный в приложении Reqpro и интегрированный с базой данных проекта. Требования, созданные вне Requisite pro, можно импортировать или скопировать в документ.
В Requisite Pro мы также можем работать с трассируемостью, здесь это отношение зависимости между двумя требованиями. Прослеживаемость - это методический подход к управлению изменениями путем связывания требований, которые связаны друг с другом.
Requisite Pro позволяет легко отслеживать изменения требований на протяжении всего цикла разработки, поэтому нет необходимости просматривать все ваши документы по отдельности, чтобы определить, какие элементы нуждаются в обновлении. Вы можете просматривать и управлять подозрительными отношениями с помощью матрицы прослеживаемости или дерева прослеживаемости.
Проекты Requisite Pro позволяют нам создать структуру проекта, в которой артефакты проекта организованы и управляются. В каждый проект включено следующее.
- Общая информация о проекте
- Packages
- Общая информация о документе
- Типы документов
- Типы требований
- Атрибуты требований
- Значения атрибутов
- Межпроектная прослеживаемость
Requisite Pro позволяет нескольким пользователям одновременно получать доступ к одним и тем же проектным документам и базе данных, поэтому аспект безопасности проекта очень важен. Безопасность предотвращает использование системы, потенциальный ущерб или потерю данных из-за несанкционированного доступа пользователей к документу проекта.
Рекомендуется включить безопасность для всех проектов RequisitePro. Это гарантирует, что все изменения в проекте связаны с правильным именем пользователя, внесшим изменения, тем самым гарантируя, что у вас будет полный контрольный журнал для всех изменений.