Документ о функциональных требованиях (FRD) является формальным заявлением о функциональных требованиях приложения. Он служит той же цели, что и контракт. Здесь разработчики соглашаются предоставить указанные возможности. Клиент соглашается найти продукт удовлетворительным, если он обеспечивает возможности, указанные в FRD.
Функциональные требования отражают предполагаемое поведение системы. Это поведение может быть выражено в виде услуг, задач или функций, которые система должна выполнять. Документ должен быть адаптирован к потребностям конкретного проекта. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением.
Документ функциональных требований (FRD) имеет следующие характеристики:
-
Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.
-
Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.
-
Это решение не зависит. ERD — это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.
Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.
Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.
Это решение не зависит. ERD — это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.
Функциональное требование должно включать следующее:
-
Описания данных для ввода в систему
-
Описание операций, выполняемых каждым экраном
-
Описания рабочих процессов, выполняемых системой
-
Описания системных отчетов или других выходов
-
Кто может ввести данные в систему?
-
Насколько система соответствует применимым нормативным требованиям?
Описания данных для ввода в систему
Описание операций, выполняемых каждым экраном
Описания рабочих процессов, выполняемых системой
Описания системных отчетов или других выходов
Кто может ввести данные в систему?
Насколько система соответствует применимым нормативным требованиям?
Функциональная спецификация предназначена для чтения широкой аудиторией. Читатели должны понимать систему, но для понимания этого документа не требуется никаких технических знаний.
Функциональные требования.
Документ бизнес-требований (BRD) состоит из —
Функциональные требования — документ, содержащий подробные требования к разрабатываемой системе. Эти требования определяют функциональные особенности и возможности, которыми должна обладать система. Убедитесь, что любые предположения и ограничения, выявленные в ходе бизнес-кейса, все еще точны и актуальны.
Модель бизнес-процесса — модель текущего состояния процесса (модель «как есть») или концепция того, каким процессом должен стать (модель «быть»)
Диаграмма контекста системы — Диаграмма контекста показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.
Блок-схемы («как есть» или «быть») — диаграммы, графически отображающие последовательность операций или движение данных для бизнес-процесса. Одна или несколько блок-схем включены в зависимости от сложности модели.
Бизнес-правила и требования к данным. Бизнес-правила определяют или ограничивают некоторые аспекты бизнеса и используются для определения ограничений данных, значений по умолчанию, диапазонов значений, количества элементов, типов данных, расчетов, исключений, обязательных элементов и реляционной целостности данных.
Модели данных — диаграммы отношений сущностей, описания сущностей, диаграммы классов
Концептуальная модель — отображение высокого уровня различных объектов для бизнес-функции и их взаимосвязи.
Логическая модель — иллюстрирует конкретные сущности, атрибуты и отношения, вовлеченные в бизнес-функцию, и представляет все определения, характеристики и отношения данных в деловой, технической или концептуальной среде.
Словарь данных и глоссарий . Сборник подробной информации об элементах данных, полях, таблицах и других объектах, которые составляют модель данных, лежащую в основе базы данных или аналогичной системы управления данными.
Карта заинтересованных сторон — определяет всех заинтересованных сторон, на которых влияет предлагаемое изменение, и их уровень влияния / полномочий для требований. Этот документ разработан на начальном этапе методологии управления проектами (PMM) и принадлежит менеджеру проекта, но должен быть обновлен командой проекта, так как новые / измененные заинтересованные стороны идентифицируются на протяжении всего процесса.
Матрица отслеживаемости требований — таблица, которая иллюстрирует логические связи между отдельными функциональными требованиями и другими типами системных артефактов, включая другие функциональные требования, сценарии использования / пользовательские истории, элементы архитектуры и дизайна, модули кода, тестовые случаи и бизнес-правила.