Skip to main content
Zimei TechnologyEnterprise AI · Development and delivery
EnglishEN
Discuss a project
Discuss a project

Enterprise AI Project Wiki · Requirements and business scenarios

Functional requirement

Also calledFunctional requirements · Functional specification · System functional requirement · FR

Definition

A functional requirement is a normative statement allocated to a named system level that specifies what the system must receive, validate, transform, store, retrieve, calculate, decide, control, present, transmit, record, prevent, or recover under explicit conditions, with a result observable or verifiable at its boundary. It should be necessary, atomic, unambiguous, feasible, verifiable, and bidirectionally traceable.

A functional requirement says what the system must do, not merely which features it has

Approval, search, knowledge Q&A, and report export are capability labels, not yet constraints on behaviour. A requirement names the system level bearing the obligation, the trigger, permission, data state and mode, the input and externally meaningful action, and the output or state that results or must be preserved on failure.

Functional requirements can exist at system, subsystem, software, service, or component level. A parent may require a service to receive and process an application, while children govern identity, evidence checks, rules, state changes, and notices. Those levels are not duplicates, but every child needs an upstream reason.

Function and performance must be coordinated. Function says what is done; performance says how quickly, accurately, at what scale, or how consistently under a named load and environment. They may appear together, but both behavioural and quantitative obligations must remain identifiable.

Behaviours commonly governed by functional requirements

Function does not begin and end with a button click. A system receives events, validates material, changes state, calls external services, creates notifications, and preserves or restores business objects after failure. Describing these behaviours separately shows whether a business task really closes from beginning to end.

Input and validation

Receive forms, files, events, sensor data, or messages and check format, presence, provenance, signature, authority, and applicable state; rejection of invalid input is also behaviour.

Transformation and calculation

Normalise, aggregate, classify, calculate, or derive facts under versioned rules, including treatment of rounding, nulls, time, units, and rule conflict.

Storage, retrieval, and records

Create, read, update, archive, or delete business information with object, condition, version, relationship, history, and immutable records defined.

Decisions and rule execution

Assess eligibility, choose a path, block an action, request review, or provide an authorised recommendation, separating the conclusion, explanation, and operational side effect.

State and mode control

Perform permitted transitions when events and conditions hold, block illegal transitions, and govern normal, degraded, maintenance, suspended, and recovery modes.

Presentation, notification, and interaction

Display, explain, request confirmation, prompt correction, or notify a named role with governed content source, recipient, trigger, acknowledgement, and duplicate behaviour; layout is normally design.

Interface interaction and orchestration

Call or answer services and orchestrate steps with semantics, order, idempotency, timeout, retry, compensation, and partial-success behaviour, while protocol detail can sit in an interface specification.

Access, protection, and audit actions

Authenticate, authorise, separate duties, mask data, record consent, and emit audit events. These implement some security and privacy objectives but do not exhaust protection requirements.

Exception, degradation, and recovery

Detect missing evidence, dependency failure, duplicate requests, conflict, and timeout and then refuse, preserve state, alert, hand over, compensate, retry, or recover—not merely show an error.

What to record in an actionable functional requirement

“Support procurement requests” is a feature name. It tells neither developers what follows a trigger nor testers which result is correct. An actionable requirement identifies actor, pre-state, input, processing, output, and failure result while linking applicable rules and permissions.

Stable ID and responsible level

Identify whether the service, system, subsystem, software item, or component bears the obligation so decomposition, verification, and change target the correct object.

Normative subject and one action

Use the system plus shall or the project's convention and carry one principal obligation. Support and provide capability do not replace a precise verb.

Trigger and requester

Name the event, schedule, message, or authorised role initiating the behaviour. If not everyone may trigger it, do not leave authority for testers to infer.

Precondition, state, and mode

State object and dependency status, existing data, time window, and normal or degraded mode. Cover unmet preconditions here or in linked requirements.

Input, provenance, and validity

Identify required input, authoritative source, format, version, permission, and validation boundary, distinguishing user claims, system facts, and external references.

Processing rule and order

Reference approved rules or algorithm objectives and required sequence, atomicity, and precedence. If a method or product is mandated, retain why design must be constrained.

Output and end state

State returned object, recipient, persisted record, notice, state change, or state that must not change so the result is observable at the boundary.

Exception, fallback, and prohibited side effect

Govern missing, unauthorised, conflicting, duplicate, timed-out, and partial failures, including decisions, payments, messages, or disclosures that must not occur.

Source, rationale, allocation, and trace

Trace upward to scenarios, stakeholder or system requirements, rules, and risks, and downward to functions, interfaces, design, implementation, and evidence; justify derived behaviour.

Verification method and decision

Name inspection, analysis, demonstration, or test with environment, role, initial state, input classes, expected result, and severe failures, linking separate performance requirements.

How to derive functional requirements from scenarios and upstream requirements

An upstream requirement states the outcome a stakeholder needs; a functional requirement identifies the system behaviours that reliably produce it. Walk through normal, exceptional, and insufficient-information scenarios to find each state change, external interaction, and human takeover instead of copying functions from a screen sketch.

  1. Confirm the upstream outcome and boundary

    Start from approved stakeholder, user, and system requirements, business rules, and risks; identify what belongs to the system rather than reverse-engineering needs from a current screen or supplier product.

  2. Walk end-to-end scenarios

    Traverse normal, exceptional, insufficient, cancelled, duplicate, dependency-failure, human-takeover, and recovery paths, recording roles, triggers, inputs, decisions, hand-offs, records, and end states.

  3. Identify functions the system must perform

    Find receipt, validation, transformation, persistence, retrieval, judgement, presentation, transmission, control, record, and recovery as logical functions before selecting screens or microservices.

  4. Model input, process, output, and state

    For each function identify inputs, controls, outputs, transitions, preconditions, postconditions, failure modes, and consequences. Activity, sequence, and state models expose gaps but are not automatically approved requirements.

  5. Apply rules, authority, and data constraints

    Map business rules, identity, data classification, and interface contracts to behaviour, distinguishing functional controls from performance, quality, and engineering constraints.

  6. Decompose, derive, and allocate

    Break parent functions into children that can be designed and verified, check collective sufficiency, and mark new functions arising from interfaces, architecture, or failure analysis as justified derived requirements.

  7. Validate with counterexamples and boundaries

    Business, user, operations, engineering, test, security, and interface owners walk legal and illegal states, nulls, duplicates, reversed order, permission change, and dependency failure to reveal hidden decisions.

  8. Approve and preserve bidirectional traceability

    Baseline named versions of requirements, models, rules, and TBDs; a function change must expose effects on upstream outcomes, adjacent states, interfaces, data, qualities, tests, and operations.

How far to decompose a functional requirement

Too large, and one failure implicates an entire workflow; too small, and the behaviour loses its business result and context. A useful unit can be allocated, verified, and changed independently while still pointing to the scenario step it serves.

Keep the externally meaningful result at the parent

A parent retains why the function exists and what outcome is observable, remaining linked to its scenario rather than becoming a list of internal calls.

Make children separately allocatable and verifiable

Split when actions belong to different elements or interfaces, have distinct failure treatment, or need distinct verification, assigning each child accurately.

Atomic does not mean context-free

One principal decidable obligation may still need conditions. Excessive splitting separates conditions from outcomes and creates fragments that cannot stand alone.

Test parent-child sufficiency and necessity

Children together must satisfy the parent; each child must trace to the parent, a constraint, or a derivation. Untraced convenience is scope and maintenance risk.

Functional decomposition is not component decomposition

First identify logical functions, then allocate them through architecture to people, software, hardware, or services. A function may span components and one component may perform several functions.

Stop when allocation and verification are credible

The current level is sufficient when statements are unambiguous, feasible, allocatable, designable, finitely verifiable, and their interfaces and failure behaviours are understood—not after an arbitrary number of levels.

Quality gates before baselining functional requirements

Functional requirements move directly into implementation and test, so vague words quickly become individual guesses. Review the normal path and also confirm that unauthorised use, duplicate requests, external failure, and no valid result cannot silently change business state.

  1. Necessary and supported upstream?

    Every function supports an approved result, rule, risk, or documented derivation rather than existing because a product offers it.

    Inspect upstream requirements, scenarios, rules, and derivation rationale.

  2. One subject, condition, behaviour, and result?

    Readers agree who does what, when, to which object, and with which end state; one statement does not hide several principal obligations.

    Use independent paraphrase, counterexamples, and glossary.

  3. Normal, exceptional, and prohibited outcomes complete?

    Null, invalid, duplicate, unauthorised, conflicting, timed-out, failed-dependency, human, and recovery paths are explicit.

    Inspect scenario-function and state coverage.

  4. Right level and appropriately solution-independent?

    It is allocated without prematurely mandating a control, product, component, or algorithm; necessary constraints have sources.

    Inspect boundary, architecture decisions, and constraints.

  5. Consistent with rules, data, interfaces, and qualities?

    Decisions, states, terminology, semantics, authority, and errors do not conflict, and linked performance, security, reliability, and usability obligations exist.

    Conduct cross-requirement and interface review.

  6. Feasible and verifiable?

    It can be realised with available technology, data, people, and dependencies, and finite inputs, initial states, and observable results can decide compliance.

    Inspect feasibility evidence and verification method.

  7. Bidirectionally traced and changeable?

    Every necessary parent behaviour has coverage and every child has a source; changes reveal affected scenarios, interfaces, states, qualities, tests, and operations.

    Inspect trace, orphan, and impact reports.

Constructed functional requirements for a procurement-request service

This customer-independent procurement service decomposes “find missing material before submission” into observable behaviours. It includes not only guidance on screen but rule retrieval, access protection, draft-state preservation, and failure handling. The identifiers and conditions illustrate writing, not an actual policy or default product design.

FR-101: check readiness

When an authorised applicant requests submission from draft state, the system shall use the approved rule version applicable at request time to inspect required facts and evidence and return every satisfied item, missing item, and rule ID without changing approval status.

FR-102: reject unauthorised submission

If the requester lacks valid authority to submit for the organisation or the request is not in an allowed state, the system shall refuse, preserve state, and record subject, request, policy version, reason code, and time.

FR-103: route insufficiency to a person

If required evidence is unreadable, the authoritative rule version is uncertain, or materials conflict, the system shall stop automated judgement, preserve confirmed facts, route to the designated review queue, and explain the pending matter.

FR-104: create the formal submission

Only if FR-101 is satisfied and FR-102 and FR-103 do not apply shall the system atomically create a distinct submission version, move draft to submitted, record rule and evidence versions, and issue one confirmation.

FR-105: handle duplicate requests

For a repeated request with the same application version and idempotency key, the system shall return the first result without creating another submission, changing state twice, or sending a duplicate confirmation.

FR-106: preserve the decision boundary

Completeness checks, evidence summaries, and AI explanations may support submission readiness but shall not approve procurement, select a supplier, or reserve budget; only separately authorised processes may do so.

Connecting functional requirements to design, test, acceptance, and operations

A functional requirement truly enters the system only when design identifies responsible components, tests return evidence, and operations leave observable records. That relationship remains useful after acceptance: during an incident, the team can follow the requirement to implementation, logs, dependencies, and recent changes.

Requirement-model consistency

Activity, state, sequence, use-case, or data-flow models show relationships across functions; model elements trace to normative requirements and model changes trigger impact review.

Requirement-design allocation

Architecture records which person, process, software, hardware, or external service realises each function and its cross-element interfaces and transaction boundaries.

Requirement-verification coverage

Each item has a method and normal, boundary, invalid, unauthorised, duplicate, failure, and recovery coverage. A test case is an evidence instance, not the source requirement.

Requirement-acceptance boundary

Acceptance criteria select pass rules for the delivery, version, environment, and business samples. Internal children may not each be customer-accepted, but evidence supports the parent decision.

Requirement-defect and waiver

Failures link requirement ID and version, environment, reproduction, severity, disposition, and retest. Deferral requires authority; rewriting a requirement to match a defect is not acceptance.

Requirement-operational monitoring

Critical functions expose governed evidence of triggers, success, failure, refusal, takeover, and side effects so real behaviour can be checked after release without violating privacy.

Enterprise AI functional requirements separate generation, tool action, and human authority

One AI response may retrieve evidence, generate text, and then call a tool that changes business state. Those steps have different risks and failure modes and cannot be compressed into “AI completes the task.” State where evidence comes from, which step only advises, and which step needs permission or human confirmation.

Context assembly and access filtering

Specify how subject, task, and object are identified and unauthorised data is removed before retrieval or model calls, recording actual input and version. Prompts do not replace server-side access control.

Retrieval and evidence selection

Govern query construction, allowed sources, version and freshness filters, deduplication, conflict flags, and citations, with an explicit insufficiency path when evidence is inadequate.

Generation and structured output

Define allowed content, mandatory fields, provenance, fact/advice separation, parse-failure treatment, and prohibited invention of approval, authority, state, or evidence.

Rules and model responsibility

Deterministic eligibility, access, transitions, and hard stops are executed by verifiable rules or code. A model may extract, summarise, or explain but not silently assume formal decision authority.

Insufficiency, conflict, and refusal

Define behaviour for missing or conflicting evidence, stale knowledge, prompt attack, invalid output structure, and high risk: stop, preserve state, state limitations, and route to a human or non-AI path.

Tool calls and side effects

Specify query, draft, send, write, delete, and approve separately with parameter checks, least privilege, confirmation, idempotency, timeout, rollback, and result validation. Intent to call is not permission.

Human review and takeover

State when a human task is created, which source material and rationale are shown, how correction and override work, how decisions return, and the safe state if nobody responds.

Audit, feedback, and version change

Record composite version, input class, evidence, rule result, tools, human decision, and severe failure, using these paths for regression and reapproval after model, knowledge, or prompt change.

Wording may vary; critical controls must not drift with it

When several phrasings are acceptable, govern structure, required content, and prohibited results and observe variation across repeated runs. Whether access is allowed, state changed, or insufficient evidence caused a stop must still produce a deterministic and repeatably testable result every time.

How functional requirements differ from neighbouring concepts

Features, screens, user stories, business rules, and test cases often share one work item but answer different questions: what the system does, why a user needs it, how the organisation constrains it, and how satisfaction is proved. Separating them retains business rationale without freezing today's interface as the requirement itself.

ConceptBoundary from a functional requirement
Feature or capability nameReport, search, and AI assistant group communication and planning; a functional requirement continues to conditions, behaviour, and an observable result.
System requirementThe complete baseline also contains performance, interfaces, data, qualities, operations, and constraints; functional requirements are its behavioural class.
User requirementDerived from user needs and capabilities for interaction and quality in use; it may derive functions but is not every internal system behaviour.
User storyA short role-goal-value narrative supporting conversation and planning; one story can need many functional and quality requirements and does not replace formal trace.
Use case or business scenarioDescribes a multi-step path across roles and systems; functional requirements extract atomic normative obligations allocated to a named system level.
Business processShows end-to-end organisational work across people, systems, and decisions; a functional requirement governs only behaviour allocated to the target system.
Business ruleDefines business meanings, permissions, duties, prohibitions, and decisions; a functional requirement says how the system applies or supports the authoritative rule.
Non-functional or performance requirementGoverns how well a function is delivered and other qualities or constraints. Returning a result and how quickly under a specified load are separate decisions.
Interface requirementGoverns both sides' interaction semantics, protocol, timing, and responsibility. Calling or responding is functional behaviour, but the interface contract is broader.
Algorithm and designExplain how behaviour is realised. A method should be mandated only with a standards, risk, or interoperability basis recorded as a constraint or derivation.
Acceptance criterion and test caseThe criterion governs a deliverable's pass decision; the case supplies inputs, steps, and expected result. They verify the function rather than replace its specification.
Backlog item or taskSchedules analysis, design, development, or verification work for an increment; a functional requirement belongs to the product baseline and may span tasks and releases.

Sources and scope

This entry explains a functional requirement in systems and software requirements engineering: a normative statement of the function, behaviour, or transformation that a clearly bounded system, subsystem, software item, or service must perform under stated triggers, preconditions, states, and modes, including observable results it must produce, preserve, or prevent. It answers what the system must do, but is not a feature name, product claim, user story, use case, business process, business rule, algorithm, interface or screen design, performance or non-functional requirement, complete system or software specification, acceptance criterion, or test case. Organisations classify data, security, error, and interface behaviours differently, so the project must state its taxonomy and authorised parties must approve actual content, priorities, thresholds, and applicability.