Logo
NeoArc Studio

FRD Block

Define functional requirements with IDs, priorities, categories, and acceptance criteria. Bridge business needs and technical implementation with structured requirements.

The FRD (Functional Requirements Document) block structures functional requirements with unique identifiers, MoSCoW priorities, categories, and acceptance criteria. It provides the detail needed for development teams to implement features correctly.

When to Use

Block Properties

PropertyRequiredDescription
TitleYesFRD document title
VersionNoDocument version number
StatusNoDraft, In Review, Approved, or Obsolete
AuthorNoDocument author
DateNoCreation or last update date
IntroductionNoPurpose and scope of the FRD
System ContextNoHigh-level system boundaries
RequirementsNoArray of functional requirements
AssumptionsNoConditions assumed to be true
DependenciesNoExternal dependencies
GlossaryNoTerm definitions

Requirement Properties

PropertyRequiredDescription
IDYesUnique requirement identifier
CategoryNoFunctional area or module
PriorityNoMust, Should, Could, or Won't (MoSCoW)
DescriptionYesWhat the system shall do
Acceptance CriteriaNoHow to verify the requirement

MoSCoW Priority Levels

Example: User Authentication FRD

Functional requirements for a user authentication module.

Best Practices

PracticeDescription
Consistent ID NumberingUse consistent ID numbering (FR-001, FR-002) for traceability
System Shall FormatWrite requirements in 'The system shall...' format
Testable CriteriaMake acceptance criteria specific and testable
Category GroupingGroup requirements by category for easier navigation
Glossary TermsInclude glossary terms for domain-specific language
Source LinkingLink requirements to source (BRD, user story, stakeholder)
Stakeholder ReviewReview priorities with stakeholders before finalising