Functional Design Specification (FDS)
- Functional Design Specification (FDS) is a requirements artifact that defines system functions, interactions, and constraints without delving into technical implementation.
- It consolidates fragmented elicitation data from tools like Confluence and Jira into unified, structured documents used across industrial and safety-critical projects.
- FDS supports automated and human-in-the-loop drafting, enhancing traceability and clarity for subsequent verification, security, and architectural design.
Functional Design Specification (FDS) denotes a requirements artifact that outlines the functional requirements and features of a system, application, or process. In industrial use, it describes the intended functionalities and behaviors of the target system from a functional perspective, answers what the system should do, how components interact, and how user needs are fulfilled, without going into implementation-level technical details. Depending on organizational context, closely related artifacts such as an Epic FDS, a final FDS, a Software Requirements Specification (SRS), or a Functional Requirements Specification (FRS) can occupy substantially the same documentary role (Pasquale et al., 25 Jul 2025, Al-Msie'deen et al., 2021, Collaboration et al., 2012).
1. Position within requirements and design documentation
In one documented industrial workflow at Fincons Group, the FDS is the main requirements specification artifact and the final outcome of the specification phase. Analysts do not write it directly from raw elicitation notes; instead, they first prepare an Epic FDS in Confluence and a User Stories document in Jira, and the final FDS incorporates and organizes that material while linking to the user stories maintained in Jira. The upstream sources include presentation decks, meeting minutes, email-like discussions, and other elicitation artifacts, so the FDS functions as a consolidation layer between fragmented requirements knowledge and development-oriented documentation (Pasquale et al., 25 Jul 2025).
Research on SRS construction shows that this role is not unique to documents explicitly labeled “FDS.” The electronic IT news magazine study presents an SRS and design package whose contents map naturally to common FDS sections such as system overview, actors, functional decomposition, process flows, user interfaces, data movement, constraints, architecture, and validation. The IUfA Unified University Inventory System SRS is similarly organized around overall system description, functional requirements, non-functional requirements, use cases, a data dictionary, mock user interface design, and projected cost estimate, with a separate document carrying the design specification (Al-Msie'deen et al., 2021, Ahmad et al., 2010).
In safety-critical development, the same documentary function appears within other standards vocabularies. The ISO 26262-oriented automated-driving method does not use the term “FDS,” but its output maps directly to common FDS content and is used as a basis for generating a Preliminary Architecture and for building up argumentation for verification of the Functional Safety Concept. This positions the FDS-like artifact as an interface between early hazard- and function-level reasoning and later architectural allocation (Mohan et al., 2019).
2. Canonical contents and internal organization
The recurring contents of an FDS can be reconstructed from several concrete templates and case studies. In the Fincons workflow, the Epic FDS template includes glossary, overview, product perspective, and high-level process flows; within product perspective, the document is expected to cover the problem, objectives, constraints, and assumptions. The final FDS template is broader and includes at least glossary, executive summary, overview, scenarios, assumptions, and user requirements. In the automated-driving safety study, FDS-like content is explicitly aligned with system purpose and functional scope, operating assumptions and constraints, functional decomposition, subsystem responsibilities, interfaces and interactions, fault handling and degraded behavior, safety mechanisms, traceability and rationale, and verification considerations (Pasquale et al., 25 Jul 2025, Mohan et al., 2019).
| Document stratum | Explicitly identified contents | Example context |
|---|---|---|
| Epic FDS | Glossary, overview, product perspective, high-level process flows | IT consulting workflow |
| Final FDS | Glossary, executive summary, overview, scenarios, assumptions, user requirements | IT consulting workflow |
| FDS-like safety artifact | Functional scope, assumptions, interfaces, fault handling, degraded behavior, verification rationale | Automated driving |
Case-study SRS documents add further recurrent elements. The IMMITN study contributes a context-level data flow model, a use case model and use case description, a sequence diagram, interface mockups, a conceptual architecture stance, and a small set of non-functional requirements. The UUIS SRS adds a large data dictionary, mock UI design, logging and audit concepts, bulk import and export functions, and explicit access-control structures. Taken together, these documents indicate that an FDS is typically not a flat list of “shall” statements, but a compound artifact combining textual requirements, interaction models, data definitions, and reviewable interface descriptions (Al-Msie'deen et al., 2021, Ahmad et al., 2010).
A persistent boundary condition is that an FDS remains function-oriented rather than implementation-oriented. The Fincons study states this directly: the document describes intended functionalities and behaviors from a functional perspective and is meant to bridge business-side requirements discussions and actual software development. This boundary is also visible in the RAVENS neuroprocessor specification, which defines implementation-independent behavior while leaving storage realization, HDL structures, bus definitions, and circuit-level details outside scope (Pasquale et al., 25 Jul 2025, Foshie et al., 2023).
3. Functional modeling, decomposition, and representation
A central problem in FDS work is the ambiguity of the term “function.” The Thing Machine (TM) framework addresses this by distinguishing function realization from function execution. Function realization is the static description of a function: the relevant things or thimacs, the five operations, the flows among them, and the arrangement that grounds system capability. Function execution is the dynamic description expressed through events and their chronology. Within TM, the elementary function types are the primitive operation set
and behavior is represented through event chronologies such as
The practical implication for FDS construction is that a functional requirement should specify not only that a system performs a named function, but also the structure, flows, actors, and preconditions necessary to realize and execute that function (Al-Fedaghi, 2020).
This modeling stance has direct consequences for decomposition. Instead of treating high-level verbs such as “deliver,” “submit,” or “transport” as atomic, TM decomposes them into explicit creates, processes, releases, transfers, and receives. The framework therefore supports a system-wide functional view, subcomponent functional view, input/output transformation view, behavioral or scenario view, and interaction view. It also supports analysis of missing, duplicate, or connected functionality by forcing the specifier to make all things, flows, and triggers explicit (Al-Fedaghi, 2020).
A related distinction concerns the boundary between functional and non-functional content. TM explicitly critiques the routine treatment of desirable qualities as if they were functions. In the pump example, “operate with little noise” is not an independent function unless it is explicitly modeled inside the processing requirement; otherwise it is a byproduct quality. This is highly relevant to FDS practice because it cautions against filling functional sections with properties that are actually quality constraints or side effects (Al-Fedaghi, 2020).
Natural-language requirement authoring research reaches a similar conclusion from a different angle. EasyFR treats feature-to-requirement translation as constrained generation rather than free-form text production. The paper argues that high-level features omit many details needed for implementable and testable requirement clauses and that the target output must follow the conventional semantic structure of functional requirements. This aligns with the FDS requirement that functional statements be traceable, reviewable, and eventually verifiable (Lian et al., 18 May 2025).
4. Architecture-oriented and safety-critical use
In safety-critical systems, an FDS cannot remain nominal-function-centric. The automated-driving study addresses a practical ISO 26262 gap: OEMs must architect the Functional Safety Concept while reusing many legacy subsystems, yet the standard gives limited methodological support for extracting the right architectural information at the right abstraction level. The proposed heuristics-based method uses an existing subsystem artifact—the diagnostic specification—to analyze how failures are detected, what assumptions are embedded about the human driver, which failures require handling beyond the subsystem, and what dependencies and constraints are imposed on the wider vehicle architecture and on the Autonomous Driving Intelligence (ADI) (Mohan et al., 2019).
For FDS purposes, this produces a particularly rich content model. The method surfaces assumptions and constraints such as the presence or absence of a human driver, reliance on driver perception or intervention, required startup tests before automated mode activation, timing, frequency, and granularity constraints on electronic commands, network limitations such as CAN load, and variant dependencies and minimum subsystem configurations. It also supports decomposition into braking request generation, braking request transmission, brake actuation, status or availability monitoring, fault detection, degraded operation control, and inter-subsystem coordination. Interfaces are treated explicitly, including replacement interfaces for removed driver interfaces, machine-readable substitutes for warning-lamp-based notifications, and information the ADI must receive to detect or compensate for failures (Mohan et al., 2019).
The method is also fault-centric. It identifies failures handled inside the subsystem, failures requiring vehicle-level handling, degraded modes enabled by intra-subsystem redundancy, inter-subsystem fallback options, and startup-only versus drive-cycle-critical failures. Traceability is preserved from monitor to failure, current reaction, driver assumption, effect of removing the driver, required changes, and resulting ADI requirement. In the Scania C.V. AB braking-subsystem case, the reported benefits include reuse of pre-existing work products, gathering requirements for automated driving functions while designing the Preliminary Architecture and Functional Safety Concept, parallelization of work across the organization on the basis of expertise, and applicability across all types of subsystems (Mohan et al., 2019).
This suggests that, in safety-critical domains, an FDS is not merely a feature specification. It is also an argument structure for subsystem reuse, failure abstraction, interface replacement, degraded operation, and early verification planning. The paper’s explicit recommendation to use an abstraction of ECU systems as Preliminary Architecture elements and to define their failure modes as unavailability of function further indicates a concrete abstraction level for function-oriented specification in complex E/E platforms (Mohan et al., 2019).
5. Automation, structured generation, and human-in-the-loop drafting
Recent work treats FDS authoring as a partially automatable synthesis problem. EasyFR addresses the transition from abstract features to functional requirements by inserting a semantic middle layer based on Semantic Role Labeling (SRL). Its pipeline has three phases: template induction, template recommendation, and draft generation. From 10 open requirements datasets, the authors filtered 768 single-sentence requirements, applied PropBank-style SRL using AllenNLP, identified recurring SRL sequences, and derived two variable templates:
[Arg2]*[Arg0] [shall] [V] [Arg1] [variable part]*
and
[Arg2]*[Arg1] [shall] [V] [variable part]*.
The approach then uses Key2Temp to select the appropriate template family and assign SRL roles to feature tokens before a fine-tuned ChatGLM-6B expands the scaffold into a cohesive functional requirement sentence. The stated contribution is to reframe requirement generation as a structured slot-filling problem rather than an open-ended NLG task (Lian et al., 18 May 2025).
Security extension work pushes this further by deriving security requirements from functional specifications. F2SRD operates in two phases: retrieval of relevant OWASP ASVS verification requirements for each functional requirement, followed by GPT-4 generation of security requirements guided by those retrieved clauses. The method therefore creates an explicit trace chain
with the verification requirement acting as a standards-based bridge between functionality and security control. The paper emphasizes that the generated security requirement is neither a paraphrase of the functional requirement nor a copy of the verification requirement; it is a system requirement written to satisfy the security expectation associated with the function (Lian et al., 17 May 2025).
Industrial LLM studies place these generation techniques inside an end-to-end documentation workflow. In the Fincons Group case, the process is staged as Data Summarization, User Story Generation, Epic FDS Generation, and LLM-Based FDS Generation. LLMs are provided with summaries of elicitation documents and shortened company templates, then asked to generate Epic FDS content and user stories, which are subsequently compiled into a complete FDS document. The reported conclusion is explicitly synergistic: LLMs can help automate and standardize requirements specification and reduce time and human effort, but the quality of LLM-generated FDS highly depends on inputs and often requires human revision. Human analysts remain responsible for contextual and technical oversight, coverage validation, ambiguity resolution, and addition of project-specific depth (Pasquale et al., 25 Jul 2025).
Two misconceptions are therefore rejected by the current literature. First, FDS generation is not equivalent to generic text generation; EasyFR argues that it is constrained generation with a recognizable semantic form (Lian et al., 18 May 2025). Second, LLM-based FDS drafting is not autonomous requirements engineering; the Fincons study shows that structurally correct outputs can still be too generic, too shallow, or incomplete when elicitation material omits tacit knowledge (Pasquale et al., 25 Jul 2025).
6. Variants across domains and nomenclature
The term “Functional Design Specification” is not tied to a single industry or representational style. Representative examples include the TENNLab research group’s functional specification for the RAVENS neuroprocessor, Fermilab’s Project X functional requirements specification, the IMMITN electronic magazine SRS and design package, and the IUfA UUIS SRS. These documents vary in naming and granularity, but each serves as a function-centered statement of what the target system must do, the contexts in which it operates, and the structures through which those functions are allocated and reviewed (Foshie et al., 2023, Collaboration et al., 2012, Al-Msie'deen et al., 2021, Ahmad et al., 2010).
| Domain | Artifact characterization | Salient emphasis |
|---|---|---|
| Neuromorphic computing | Functional specification | Implementation-independent neuron, synapse, and cycle semantics |
| Accelerator facilities | Functional requirements specification | Facility-level performance criteria, staging, and upgrade capability |
| Web publishing | SRS/design package with FDS-like contents | Story, scenario, DFD, use cases, sequence diagram, UI mockups |
| University inventory systems | SRS with separate design specification | Use cases, access control, data dictionary, audit and error management |
The RAVENS specification is explicitly implementation-independent and should apply to all implementations of the neuroprocessor, including memristive or mixed CMOS-memristor, all-digital CMOS, FPGA, microcontroller, and software simulation or CPU simulation. It specifies neuron state and firing semantics, synapse delay and weight behavior, refractory period behavior, leak behavior, STDP potentiation and depression behavior, charge injection, hardware constants, network settings, and a discrete-cycle execution model, while leaving physical storage and low-level bus or RTL details unspecified (Foshie et al., 2023).
Project X illustrates the facility-scale end of the spectrum. Its Functional Requirements Specification establishes performance criteria for a multi-megawatt proton facility, defines simultaneous mission support for long-baseline neutrino experiments and 1–3 GeV precision experiments, and explicitly embeds staging and upgradeability as functional provisions. The document is strongest on top-level mission, beam capability, staging, and upgrade intent, and weaker on subsystem acceptance criteria, protection functions, and interface detail, which is characteristic of a facility-level FRS rather than a fully elaborated subsystem FDS (Collaboration et al., 2012).
The IMMITN and UUIS studies show the opposite extreme: prototype-driven, interface-rich software specification. IMMITN combines story, scenario, DFD, use case model, sequence diagram, GUI mockups, and non-functional requirements for a web-based interactive multimedia magazine. UUIS combines use cases, a detailed data dictionary, mock UI, audit and logging mechanisms, error management, import and backup functions, and a bit-based permission model. These examples suggest that, in software practice, an FDS often operates as a mixed textual-diagrammatic artifact whose completeness depends on explicit treatment of users, data, workflows, and validation points rather than on terminology alone (Al-Msie'deen et al., 2021, Ahmad et al., 2010).
Across these domains, the stable core is the same: an FDS specifies intended functions, interacting components or actors, relevant assumptions and constraints, and the documentary basis for later design, verification, and review. The variable elements are naming convention, abstraction level, and the proportion of prose, diagrams, templates, and formalized trace links used to express that core.