Исходными данными для определения бизнес требований являются потребности в модернизации процессов организации выявленные в главе 1 — «Анализ узких мест». К ним можно отнести:
— Сокращение сроков оформления документов,
— Повышение производительности труда сотрудников,
— Сокращение времени реагирования на запросы заявителей,
— Уменьшение вероятности потери данных об участниках дела,
— Сокращение времени оформления одного дела,
— Хранение информации в единой базе,
— Снижение доли ошибок сотрудников,
— Сохранение порядка выполнения процесса.
Бизнес-проблема, которая разрешается посредством нового ИТ решения заключается в следующем:
— Длительный срок оформления документов,
— Низкая производительность труда сотрудников,
— Длительное время реагирования на запросы заявителей,
— Большая вероятность потери данных об участниках дела,
— Длительное время оформления одного дела,
— Хранение информации в разных местах,
— Большая доля ошибок сотрудников.
Некоторые из представленных бизнес-проблем могут быть решены путем внедрения системы электронного документооборота, но в этом случае не учитываются специфические бизнес-процессы предприятия, а это необходимо. Соответственно представленной организации необходима информационная система, которая будет учитывать все нюансы бизнес-процессов Мирового суда. Это решение соответствует развитию технологий, тенденциям рынка и стратегии развития предприятия.
Бизнес-цели и критерии успеха
— Достигнуть показателя удовлетворенности заявителей, равного 4.5, в течение 6 месяцев (показатель высчитывается по пятибалльной шкале с помощью голосования размещенного на сайте Мирового суда).
— Увеличить производительность обработки транзакций на 15 %
— Снизить уровень ошибок данных до величины не более 5%
— Сократить срок оформления документов на 20%
— Сократить срок времени оформления одного дела на 13%
— Сократить время на поиск документов и сопутствующей информации на 25 %.
— Порядок выполнения процесса должен соответствовать административному регламенту по ведению гражданского судопроизводства.
Потребности клиентов или рынка
Потребности типичных клиентов (в данном случае заявителей):
— Сокращение времени оформления каждого дела;
— Сокращение времени реагирования на запросы заявителей;
— Сокращение вероятности потери данных;
— Сокращение доли ошибок сотрудников.
Проектирование, разработка, внедрение и настройка информационной системы могут занять некоторое время, соответственно, недостатки, которые были выявлены ранее, не будут устраняться до тех пор, пока система не будет введена в эксплуатацию полностью или не будут найдены другие пути решения.
Приемлемость для пользователя:
Существует вероятность того, что секретарей Мирового суда придётся обучать работе на данной информационной системе. Это вопрос может быть решен путём проведения консультаций.
Проблемы, связанные с реализацией:
Существует вероятность того, что на этапе анализа были выявлены не все бизнес-правила и какие-то функции будут искажены, но на этапе второй или последующей итерации можно отследить неучтенные бизнес-требования или бизнес-правила и внести их реализацию в функционал системы.
Существует необходимость сертификации систем, разработанных для государственных органов. Эту проблему можно решить, подготовив все необходимые документы для прохождения сертификации.
Источник: studentopedia.ru
Что такое Business Requirements Document
Business Requirements Document (BRD) — это формальный документ, который содержит детальное описание бизнес-требований проекта. BRD определяет, какие функции должны быть реализованы в проекте, каким должно быть поведение системы в различных сценариях, и каким образом должны быть удовлетворены потребности заказчика и пользователей.
BRD является одним из наиболее важных документов, используемых при разработке проекта. Он служит основным источником информации для всех участников проекта, включая бизнес-аналитиков, разработчиков, тестировщиков и заказчиков.
BRD должен содержать информацию о том, что должно быть достигнуто в результате проекта, а также описывать функциональные и нефункциональные требования к системе. Документ должен быть достаточно подробным и точным, чтобы не оставлять места для неоднозначностей и недопонимания.
BRD может включать в себя различные секции, включая общее описание проекта, описание бизнес-процессов и бизнес-правил, описание требований к функциональности системы, описание требований к качеству и производительности системы, а также описание требований к интерфейсам и архитектуре системы.
Правильно составленный BRD помогает всем участникам проекта понимать, что должно быть достигнуто в результате работы. BRD предоставляет одну из основных точек отсчета для оценки успешности проекта.
Структура
- Введение. В этой секции обычно описывается контекст проекта, его цели и ценности, а также причины, по которым проект был инициирован. Эта секция также может включать информацию о ключевых участниках проекта и ограничениях, с которыми проект должен работать.
- Обзор проекта. В этой секции описывается общая концепция проекта и его цель. Также обычно приводится описание текущего бизнес-процесса и проблем, которые должен решать проект.
- Описание бизнес-процессов и бизнес-правил. Эта секция описывает существующие бизнес-процессы, которые будут затронуты проектом, а также любые бизнес-правила, которые должны быть учтены. В этой секции могут быть приведены блок-схемы или диаграммы, чтобы визуализировать бизнес-процессы.
- Требования к функциональности системы. Эта секция описывает функциональные требования к системе. Она может включать в себя описание конкретных функций и возможностей, которые должны быть реализованы в системе, а также взаимодействие между различными функциями.
- Требования к нефункциональным характеристикам системы. Эта секция описывает нефункциональные требования к системе, такие как производительность, безопасность, масштабируемость и т.д.
- Требования к качеству системы. В этой секции определяются критерии, по которым будет оцениваться качество системы.
- Требования к интерфейсам и архитектуре системы. Эта секция описывает требования к пользовательскому интерфейсу и к архитектуре системы, включая аппаратные и программные компоненты.
- Обзор рисков и проблем. В этой секции рассматриваются потенциальные риски, связанные с проектом, и проблемы, которые могут возникнуть в процессе его реализации. Важно определить эти риски заранее, чтобы разработать планы и стратегии по их управлению.
- План тестирования и проверки качества. Эта секция описывает план тестирования и проверки качества системы, который будет использоваться для проверки соответствия системы требованиям. Она может включать в себя описание методов тестирования, тестовых сценариев, средств тестирования и оценки качества.
- План внедрения и миграции. В этой секции описывается план внедрения и миграции системы в производственную среду, включая описание процесса внедрения и миграции, а также план обучения пользователей.
- Заключение. В этой секции обычно подводятся итоги документа BRD. Описывается, как будет происходить дальнейшая работа над проектом.
Источник: itonboard.ru
Определение бизнес-требований
Бизнес-требования представляют высший уровень абстракции в цепи требований: они определяют концепцию решения и границы проекта, в котором оно будет реализовываться. Пользовательские и функциональные требования к ПО должны находиться в соответствии с контекстом и целями, устанавливаемыми бизнес-требованиями.
Требования, не содействующие достижению бизнес-целей проекта, реализовываться не должны. Проект, в котором нет четко определенного и согласованного направления, можно смело назвать кандидатом на провал. Участники проекта могут, сами того не осознавая, решать прямо противоположные задачи, если у них разные бизнес-цели и приоритеты.
Лица, заинтересованные в проекте, никогда не смогут договориться о составе требований, если они не выработали общего понимания бизнес-целей. Без четкого понимания с самого начала график и бюджет проекта скорее всего выйдут за намеченные рамки. В этой части описывается документ концепции и границ — результирующий документ, содержащий бизнес-требования проекта.
Формулировка бизнес-требований
Термин бизнес-требования (business requirements) относится к информации, которая в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. В основе бизнес-требований лежат бизнес-возможности, бизнес-цели, критерии успеха и положение о концепции.
Вопросы бизнес-требований должны решаться до окончательного определения функциональных и нефункциональных требований. Положение о рамках и ограничениях проекта сильно помогает в обсуждениях предлагаемых функций и целевых выпусков. Бизнес-требования являются отправной точкой для принятия решений о предложенных изменениях и улучшениях требований. Мы рекомендуем представлять бизнес-цели, концепцию и границы на всех семинарах по сбору требований, чтобы в команде могли быстро понять, находится ли предлагаемое требование в рамках проекта.
Определение требуемых бизнес-преимуществ
Бизнес-требования определяют контекст и позволяют измерять преимущества, которые организация ожидает получить от реализации проекта. Организации не должны инициировать проект без ясного понимания пользы, которую он принесет для бизнеса.
Определяйте измеряемые ориентиры на основе бизнес-целей, после чего определяйте критерии успеха, который позволят оценивать, находитесь ли вы на пути достижения этих целей. Бизнес-требования могут исходить от финансирующих проект заказчиков, топ-менеджеров, менеджеров по маркетингу или ответственных за концепцию продукта.
Однако определить и донести бизнес-преимущества бывает непросто. Члены команды не всегда уверены в том, какова задача проекта. Иногда кураторы не хотят определять цели в поддающемся измерению виде, чтобы потом не нести ответственность за их достижение. Может быть несколько заинтересованных лиц, которые не согласны с целями.
Бизнес-преимущества должны представлять реальную пользу для кураторов и клиентов проекта. Например, слияние двух систем в одну не является разумной бизнес-целью. Клиентам все равно, используют ли они одну, пять или десять систем — их интересуют задачи, такие как повышение доходов или снижение издержек.
Слияние двух систем может быть частью решения, но само по себе оно редко является бизнес-целью. У проектов по обеспечению выполнения требований регулирующих органов также есть ясные бизнес-цели. Часто цели формулируются как задача избежать рисков, например риска судебного преследования или прекращения работы компании.
Концепция продукта и границы проекта Концепция и границы — два базовых элемента бизнес-требований. Концепция продукта (product vision) сжато описывает конечный продукт, который достигнет заданных бизнес-целей. Этот продукт может полностью удовлетворять бизнес-требования или быть только частью решения.
Концепция описывает, что продукт представляет собой сейчас и каким он станет впоследствии. Она обеспечивает контекст для принятия решений на протяжении жизненного цикла продукта и выстраивает работу всех заинтересованных лиц в одном направлении. Границы проекта (project scope) показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация. В положении о границах определена черта между тем, что входит в проект и тем, что остается вовне.
Источник: studfile.net
