User:Metteduijnhouwer

Functional requirements capture the system’s intended behavior in software engineering and systems engineering. It defines a function of a system or its component, where a function is described as a specification of behavior between inputs and outputs. This behavior may be expressed as services, tasks, or functions the system is required to perform.

"A Procedure for Requirements Analysis" indicates that functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases.

Use case
Use cases have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented community where they originated, but their applicability is not limited to object-oriented systems. Use cases capture the functional requirements of the system. Since the architecture must support the functional requirements of current and planned systems, it is important that the architects understand what is required, at least at the level of abstraction relevant to architecture.

Each use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system. An actor may be a class of users, roles users can play, or other systems. These can be separated into primary and secondary actors. A primary actor has a goal requiring the assistance of the system and the secondary actor is one from which the system needs assistance. Thus, use cases capture who (actor) does what (interaction) with the system, and for what purpose (goal), without dealing with system internals.

The use case structure is graphically summarized in a use case diagram, which also shows which actors interact with which use cases. Use case diagrams (UCDs) are widely used to describe software product requirements and desired functionality. UCDs are employed in UML (Unified Modeling Language), a standard notation for modeling real-world objects and systems.

Functional vs non-functional requirements
As said before, functional requirements define a function of a system or its component. Functional requirements are supported by non-functional requirements (also known as "quality requirements"), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form "system must do ," while non-functional requirements take the form "system shall be ". The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture.

As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements, which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system.