Бизнес анализ функциональные требования

B: отклик — 0,2 с для 10 пользов., 2 с для 20 пользов.

Антитребование — это некое утверждение, что не должна делать программа. Например: «Программа не должна иметь внешнего загрузчика файлов». Хорошая спецификация должна иметь антитребования, чтобы явно описать, что программа не должна делать.

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

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Как отличать нефункциональные требования?

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Требования и прецеденты. Формат описания прецедента. Структура прецедента.

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

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

Анализ требований 6. Бизнес-объекты. Бизнес требования. Функциональные требования.

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

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

Один и тот же прецедент может быть описан с различной степенью детализации.

Исполнитель (актер, actor) — некоторая роль, которую пользователь играет по отношению

к системе: люди, организации, машины, программы.

Прецедент (вариант использования, use case) — множество взаимосвязанных сценариев, объединенных некоторой общей целью пользователя (исполнителя).

Прецеденты — текстовые описания, а не диаграммы.

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

· свободный (там же)Возврат товара

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

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

o Если у системы возникли сложности при коммуникации с внешней системой вычисления налога.

· развернутый (для представления части наиболее важных прецедентов)

o Оформление продажи

o Приложение автоматизации торговли NextGen

o пользовательские (user-geal level)

o вспомогательные (subfuncion level)

o Задача, определенная пользователем

· заинтересованные лица и их требования

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

o Продавец. Хочет получить сои комиссионные от продажи. .

o Кассир идентифицирован и аутентифицирован

· результаты или постусловия (postconditions)

o Данные о продаже сохранены. Налоги корректно вычислены. . Чек сгенерирован

· Основной успешный сценарий

· Список технологий и типов данных

· Список открытых вопросов

Дата добавления: 2018-05-13 ; просмотров: 734 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Документ о функциональных требованиях

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

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

Документ функциональных требований (FRD) имеет следующие характеристики:

• Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.
• Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.
• Это решение не зависит. ERD – это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.

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

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

Это решение не зависит. ERD – это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.

Функциональное требование должно включать следующее:

• Описания данных для ввода в систему
• Описание операций, выполняемых каждым экраном
• Описания рабочих процессов, выполняемых системой
• Описания системных отчетов или других выходов
• Кто может ввести данные в систему?
• Насколько система соответствует применимым нормативным требованиям?

Описания данных для ввода в систему

Описание операций, выполняемых каждым экраном

Описания рабочих процессов, выполняемых системой

Описания системных отчетов или других выходов

Кто может ввести данные в систему?

Насколько система соответствует применимым нормативным требованиям?

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

Функциональные требования.

Документ бизнес-требований (BRD) состоит из –

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

Модель бизнес-процесса – модель текущего состояния процесса (модель «как есть») или концепция того, каким процессом должен стать (модель «быть»)

Диаграмма контекста системы – Диаграмма контекста показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.

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

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

Модели данных – диаграммы отношений сущностей, описания сущностей, диаграммы классов

Концептуальная модель – отображение высокого уровня различных объектов для бизнес-функции и их взаимосвязи.

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

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

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

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

Источник: coderlessons.com

Бизнес анализ функциональные требования

Требование – это характеристика или условие, которому должна удовлетворять ПС.

Функциональные требования определяют действия, которые должна выполнять ПС, без учета физических ограничений. Тем самым они определяют поведение системы при вводе и выводе. Процесс выявления функциональных требований весьма сложный и трудоемкий. Это объясняется следующими причинами:
• таких требований к системе обычно много,
• заказчик не всегда способен четко сформулировать, чего он хочет от системы,
• требования в итоговом документе должны быть изложены так, чтобы они одинаково понимались заказчиком и исполнителем и не допускали неоднозначности,
• между функциональными требованиями могут быть разные зависимости, усложняющие управление ими в случае необходимости внесения изменений.

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

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

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

Цели анализа и моделирования требований

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

Роли

• Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.
• Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.
• Заинтересованные лица – люди, предоставляющие информацию.
• Эксперт – представитель заказчика, участвующий в разработке модели требований.
• Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Артефакты

Для достижения поставленных целей предусматривается создание следующих документов:
• Предварительное соглашение – текстовый документ, который описывает, что будет включено в ПС и что решено исключить, то есть, он ограничивает системную функциональность. В нем отражаются пожелания заинтересованных лиц, а также указываются основные нефункциональные требования (например, описывается платформа реализации, точность вычислений, время отклика).
• Модель требований служит для достижения соглашения между заказчиком и разработчиками, давая возможность заказчику убедиться в том, что система будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в третьих позволяет связать графическую форму представления с текстовой. Модель включает актеров и ВИ, показывает, как система взаимодействует с актерами и что она делает в каждом ВИ.
• Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.
• Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.
• Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)»).

Процесс

В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.1).

Рис.1 Технологический процесс управления требованиями.

Начало анализа

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

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

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

Построение модели требований

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

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

Верхний уровень иерархии обычно определяется, исходя из основных видов деятельности организации. Если был выполнен бизнес-анализ, то основные виды деятельности уже представлены в бизнес-модели в виде пакетов, и они могут быть просто скопированы в модель требований. Пакетов верхнего уровня не должно быть много. Целесообразно выделить пакет администрирования и пакет вспомогательных действий, и 2 – 4 пакета, основных видов деятельности. В свою очередь, пакеты верхнего уровня могут включать пакеты следующего уровня и т. д.

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

Детализация модели требований

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

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

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

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

Составление дополнительных спецификаций

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

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

Проектирование пользовательского интерфейса

Этот процесс выполняется для того чтобы заказчик мог более точно представить себе работу и возможности будущей ПС и выдать свои замечания и уточнения требований. В зависимости от сложности проекта и уровня подготовленности заказчика результаты этих работ могут быть представлены в различных формах:
• программная реализация, воспроизводящая точный вид экранных окон;
• альбом экранных форм;
• модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций – кнопок.

Создание спецификации требований

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

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

Источник: www.informicus.ru