Документ с функциональными требованиями
Документ функциональных требований (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 - Таблица, иллюстрирующая логические связи между отдельными функциональными требованиями и другими типами системных артефактов, включая другие функциональные требования, сценарии использования / истории пользователей, элементы архитектуры и дизайна, модули кода, тестовые примеры и бизнес-правила.