Functional requirement

In the ( software ) technology is a requirement (often English requirement ) a statement about a settled property or service to be provided of a product, system or process.

Requirements to be included in the requirements elicitation, analysis, specified and verified. The process is in the Requirements Management, which manages the requirements embedded. Requests are typically (eg specifications ) in a single document.

Types of requirements

There are different approaches to classification of requirements.

Requirements, understood as a quality criterion for systems and software products that can be classified according to ISO 25010 / IEC 25000, or according to the quality models from ISO / IEC.

The most common is the subdivision into functional and non-functional requirements. Non-functional requirements represent quality properties

A functional requirement specifies what to do the product. An example:

A non- functional requirement (English non-functional requirement, NFR ) specifies which properties should have the product. An example:

Often, in addition to these two types, boundary conditions (english constraints ) can be described as requirements. Common constraints are a cap on costs and be maintained, a date for the completion of the project.

Classification of non-functional requirements

While functional requirements are rated differently depending on the project, there is for non-functional requirements typical subdivisions, such as Volere or DIN 66272nd The following list shows typical types of non-functional requirements.

• Reliability ( system maturity, recoverability, fault tolerance)
• Look and feel ( look and feel )
• Usability ( understandability, learnability, operability )
• Performance and efficiency ( response times, resource requirements, cost-effectiveness )
• Operating and ambient conditions
• Maintainability, changeability ( analyzability, stability, testability, extensibility )
• Portability and ( adaptability of installation, compliance, interchangeability )
• Security requirements (confidentiality, information security, data integrity, availability)
• Correctness ( error-free results )
• Flexibility (support for Standards)
• ( Cope with changes in scope of the problem ) Scalability
• Boundary conditions

Structure of a requirement

Typically, a single request from the following ingredients.

• Identifier ( Requirement Number): Identifies the requirement clearly.
• Description ( Description): Describes the requirement short and concise. Schienmann separates short and long description ( " Description of Requirement "), while Robertson and Robertson provide only a field that corresponds to the short description.
• Problem description ( rationale ): Describes the requirement causing problem.
• Source ( originator ): Identifies the requesting person or a document from which there is a requirement, for example, a piece of legislation.
• Acceptance criterion ( Fit Criterion): Describes a measurable condition is checked with the later, whether the requirement is met.

In addition to these standard components, various authors suggest additional structural elements. An important role is played by the prioritization of competing demands to the order of realization set or to make a selection when the available resources (time, money and people) are not sufficient to meet all requirements. Here beat Robertson and Robertson in their process model Volere the following properties before.

• Customer satisfaction (Customer Satisfaction): A numeric value that specifies how the fulfillment of the requirement has a positive effect on the satisfaction of the client.
• Customer dissatisfaction (Customer Dissatisfaction ): A numeric value that specifies how the non-fulfillment of the requirement has a negative effect on the satisfaction of the client.
• Priority (Priority): a numerical value, which defines the priority of this application, and then becomes important, if all requirements can not be met.
• Conflicts ( conflicts): Here requirements can be listed that are inconsistent with this requirement, so that has to be balanced between them.

Schienmann proposes the following properties to assign the specific requirements (software ) products.

• Product Type: Identifies the version of the product to be created in which the request is to be fulfilled.
• Block: Identifies the portion of the product to be created, with the request to be fulfilled.

The actual description of the requirement can be supported by the following elements, thus promoting understanding and misunderstandings are avoided.

• Further reading material ( Supporting Materials ): documents that are necessary to understand the request.
• Objective: Define the objective of the request destination.
• Note: Provides space for additional comments and clarifications.
• Nomenclature: Refers to formally defined terms that are used in the request.

Because requirements do not remain constant, but evolve over the course of a project, including information about their life cycle are required.

• History (History ) of the request: When it was first formulated by whom, when and who set etc.
• Status: Identifies the current status of the request, such as whether it has already been accepted by the contractor.
• Open point: Accommodates yet to be clarified matters.

In the course of requirements analysis and business processes and business objects to be modeled, which can be used for the formulation of requirements. In addition, requirements related to each other.

• Business object: Renames a business object to which it refers the request.
• Business Process: Identifies a affected by the request business process.
• Relationship: Refers to other requirements. For example, can be refined to more accurate a rough requirement.