User:Metteduijnhouwer/Functional requirement

Functional requirements capture the system’s intended behavior in software engineering and systems engineering. It describes what kind of service the software must offer. This is done by defining a function of a system or its component. A function is nothing but inputs to the software system, its behavior, and outputs. This behavior may be expressed as services, tasks, or functions the system is required to perform.

By prescribing what services the software-to-be should provide, functional software requirements help you to capture the intended behaviour of the system and the intended software effects on the environment. Functional requirements are a type of software requirement. Software requirements are used to describe the software-to-be and the statements describe shared phenomena. This differs from system requirements, which are related to environmental phenomena and describe the software-to-be together with other system components.

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.

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.

Behavioral-and functional requirements
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. 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).

The intended behavior of the system is expressed in the functional requirement as services, tasks or functions the system is required to perform. Software product developers make a distinction between necessary functionalities for a system or features which can differentiate the system from competitors’.

A common way to specify the behavior of the system is by generating use cases. In use cases, the behavior between the actors can easily be visualized by generating actions and relationships. Later on, more information will be given about use cases.

Functional vs non-functional requirements
Functional requirements define a function of a system or its component. Functional requirements are in contrast with 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.

In the table underneath there are a few differences between functional and non-functional requirements.

Advantages
Using functional requirements comes with benefits for the software engineering process.


 * Defining functional requirements helps to clearly decide what the expected system behavior should be.
 * While gathering functional requirements, errors can be caught. In this stage, it is the cheapest to fix errors.
 * After all functional requirements have been documented, it helps to define the functionality of the (sub)system.
 * Writing down functional requirements helps with checking if all the required functionalities are provided by the system.

Disadvantages
Using functional requirements can also come with disadvantages to the software engineering process.


 * Unclear requirements lead to a poorly defined scope, which can cause difficulties from the beginning of the project. This could lead to delays and increasing costs.
 * Most of the time, visualizations are necessary to make it understandable for non-technical stakeholders.

Writing functional requirements
Functional requirements must always be written down in detail; they cannot simply be assumed by developers or managers as part of their everyday work activities. If you don’t write down your functional specifications explicitly, you risk missing important details that could later lead to misunderstandings between stakeholders and developers or even bugs in the final product. Therefore, all stakeholders involved in software development projects must agree on exactly what functionality their products should have before starting actual development work. This process is called specification definition. Once specification definitions have been agreed upon among all stakeholders involved in a project, they can then serve as guidelines for developers who are tasked with implementing.

Functional specifications are written down as text documents. These documents contain descriptions of all scenarios that must be implemented in a product together with preconditions and postconditions for each scenario. A software requirement specification document is therefore essentially a set of scenarios describing how a product should behave when it is used by its intended users.

Functional requirements are typically captured in the form of user stories or use cases. These terms are sometimes used interchangeably, but they actually mean slightly different things.

User stories
User stories are a lightweight method for quickly capturing the “who”, “what” and “why” of a product’s requirements. User stories are short, and each element usually contains less than 10 or 15 words. User stories are “to-do” lists that help you identify the steps along the project path. They help ensure that your process, and the resulting product, meet your requirements. It is also important to state that a user story is singular, only one element is mentioned.

How to make a user story?
User scenario's are set up in a specific way:


 * Who it is for?
 * What it expects from the system?
 * Why it is important (optional?)?

User story consist of 3 different parts:


 * Role – The user should be an actual human who interacts with the system.
 * Action – The behavior of the system should be written as an action.
 * Benefits – The benefit should be a real-world result that is non-functional or external to the system.

Examples
To create a better understanding of a functional requirement written down as a user story, a few examples are given:


 * Example #1: "As a customer, I want to view items, so I can have an overview of the possible items to buy."
 * Example #2: “As a customer about to make a purchase, I need to be able to submit my credit card details and get authorization so that I can complete my checkout.”
 * Example #3: "As a customer, I need to authenticate myself so that I can see my account details and past orders."
 * Example #4: "As a security engineer, I want all all customers to authenticate themselves, so that it reduces the chance of security breaches."
 * Example #5: "As someone from the management team, I want my customers to be able to search for products, so that they can find the ones they want to buy."

Use cases
Functional requirements can also be written down as use cases. 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. Use cases are often visualized in a use case diagram. Later on, use case diagrams are explained.

Examples
To create a better understanding of a functional requirement written down as use cases, a few examples are given:

The examples show that a functional requirement is a specific statement of what the system should do.
 * Example #1: A customer shall be able to log into the system using their username and password. The function of this requirement is ‘to log into the system’ and the behavior is “The system shall allow a user to log in using their username and password.”
 * Example #2: The customer shall be able to make a purchase on the webshop. The function of this requirement is 'to be able to buy something' and the behavior is "The system shall allow the user to buy something".
 * Example #3: The system shall send a confirmation email to the user after they have successfully placed an order. The  function is “send confirmation email” and the behavior is “The system shall send a confirmation email to the user after they have successfully placed an order.”

SMART
It doesn't matter in what way you write functional requirements, it is important to adhere to the SMART principles. This means that the requirements should:


 * Specify exactly what you want the system to do
 * Be measurable
 * Be achievable within a given timeframe
 * Be relevant to the business goals
 * Be time-bound

Following the guidelines set by the SMART principle will help to make clear functional requirements, to make sure the development team can build the correct product.

Visualization
In some cases, a requirements analyst generates use cases after gathering and validating a set of functional requirements. The hierarchy of functional requirements collection and change, broadly speaking, is: user/stakeholder request → analyze → use case → incorporate. Stakeholders make a request; systems engineers attempt to discuss, observe, and understand the aspects of the requirement; use cases, entity relationship diagrams, and other models are built to validate the requirement; and, if documented and approved, the requirement is implemented/incorporated.

Underneath, a few of these visualizations of the functional requirements are mentioned.

Use case diagram
When the use cases are made, the 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.

UML class diagram
UML (Unified Modeling Language) is the de-facto standard formalism for the analysis and design of the software. One of the most important components of UML are class diagrams, which model the information on the domain of interest in terms of objects organized in classes and relationships between them.

Entity Relationship Diagram (ERM)
An entity relationship diagram (ERD), also known as an entity-relationship model, is a graphical representation that depicts relationships among people, objects, places, concepts, or events within an information technology (IT) system.