Requirement (computer science)

from Wikipedia, the free encyclopedia

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

Requirements are recorded, analyzed, specified and verified in the requirements elicitation. The process is embedded in the requirements management , which manages the requirements. Requirements are usually summarized in a document (e.g. specifications ).

Types of requirements

There are different approaches to classifying requirements.

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

The most common is the division into functional and non-functional requirements.

A functional requirement defines what the product should do. An example:

"The product should calculate the balance of an account on a key date."

A non-functional requirements (English non-functional requirement , NFR) is not uniformly defined in the literature. The common denominator is that it goes beyond the functional requirement. The non-functional requirements describe how well the system should perform; they are often understood as boundary conditions and quality properties. An example:

"The product should answer the user within a second."

Apart from these two types, constraints (English are often constraints ) as described requirements. Frequent boundary conditions are an upper limit for costs and a deadline to be met for the completion of the project.

Classification of non-functional requirements

While functional requirements are arranged differently depending on the project, there are typical structures for non-functional requirements, for example Volere or DIN 66272 .

Non-functional requirements can be divided into two main categories:

Execution quality

This can be observed during operation (at runtime).

Further development quality / evolution quality

This is embodied in the static structure of the system.

  • Operation and environmental conditions
  • Maintainability , changeability (analyzability, stability, testability, expandability)
  • Portability and transferability (adaptability, installability, conformity, interchangeability)
  • Flexibility (support of standards)
  • Scalability (coping with changes in the scope of the problem)
  • boundary conditions

Structure of a requirement

A single requirement typically consists of the following components.

  • Identifier ( Requirement Number ): Uniquely identifies the requirement.
  • Description ( Description ): Describes the request short and concise. Schienmann separates short and long description ("requirements description"), while Robertson and Robertson only provide one field that corresponds to the short description.
  • Problem Description ( Rationale ): Describes the problem causing the request.
  • Source ( originator ): Identifies the requesting person or a document from which the request results, e.g. a legal regulation.
  • Acceptance criterion ( Fit Criterion ): Describes a measurable condition that is later used to check whether the requirement has been met.

In addition to these standard components, various authors propose additional structural elements. The prioritization of competing requirements plays an important role in order to determine the order of implementation or to make a selection if the available resources (time, money and people) are not sufficient to meet all requirements. Here Robertson and Robertson propose the following properties in their Volere process model .

  • Customer satisfaction ( Customer Satisfaction ): A numeric value that indicates how the fulfillment of the requirement has a positive effect on the satisfaction of the client.
  • Customer dissatisfaction ( Customer Dissatisfaction ): A numeric value indicating how the non-fulfillment of the request has a negative effect on the satisfaction of the customer.
  • Priority ( Priority ): A numeric value that defines the priority of this application and then becomes important when all requirements can not be met.
  • Conflicts ( Conflicts ): Here requirements are listed that contradict this requirement, must be so weighed between them.

Schienmann suggests the following properties in order to assign the requirements to certain (software) products.

  • Product Release: Identifies the version of the product to be created in which the requirement is to be met.
  • Building block: Identifies the part of the product to be created with which the requirement is to be fulfilled.

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

  • Additional material ( Supporting Materials ): documents that are needed to understand the requirement.
  • Objective: Defines the objective pursued with the requirement.
  • Note: Provides space for additional comments and clarifications.
  • Nomenclature: Refers to formally defined technical terms that are used in the requirement.

Since requirements do not remain constant, but rather develop in the course of a project, information on their life cycle is also required.

  • History ( History ) of the request: When was she who first formulated by when and by whom changes, etc.
  • Status: Identifies the current status of the request, for example whether it has already been accepted by the contractor.
  • Open point: Provides space for issues that have yet to be clarified.

In the course of the requirements analysis, business processes and business objects are also modeled, which can be used to formulate requirements.

  • Business Object: Names a business object to which the requirement applies.
  • Business process: Identifies a business process affected by the requirement .

In addition, each other and with other artifacts are requirements of the development process in relationship (engl. Requirements traceability).

  • Relationship (English Trace Link): Refers to other requirements. For example, a rough requirement can be refined into several more precise requirements or requirements conflict with one another.

See also

Individual evidence

  1. ISO / IEC 25010 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models FINAL DRAFT. Accessed March 24, 2014 (PDF; 4.0 MB).
  2. ^ Suzanne Robertson, James Robertson: Mastering the Requirements Process . 2nd Edition. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9 , pp. 9-10 .
  3. Chris Rupp: Requirements engineering and management: From practice from classic to agile , Carl Hanser Verlag GmbH Co KG, 2014, ISBN 9783446443136 , pp. 268–269 [1]
  4. ^ System development in business informatics: vdf Hochschulverlag AG, 2002, ISBN 9783728127624 , p. 139 [2]
  5. Martin Eigner, Florian Gerhardt, Torsten Gilz, Fabrice Mogo Nem: Information technology for engineers , Springer-Verlag, 2012, ISBN 9783642248931 , p. 52 [3]
  6. ^ Suzanne Robertson, James Robertson: Mastering the Requirements Process . 2nd Edition. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9 , pp. 171-201 .
  7. Chris Rupp, Sophist Group: Requirements Engineering and Management . Hanser, Munich 2001, ISBN 3-446-21664-2 , p. 264 .
  8. a b c d e f g h i j k l m n Bruno Schienmann: Continuous requirements management . Addison-Wesley, Munich 2002, ISBN 3-8273-1787-8 , pp. 151 .
  9. a b c d e f g h Suzanne Robertson, James Robertson: Mastering the Requirements Process . S. 264 .
  10. Orlena Gothel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Traceability Fundamentals . In: Software and Systems Traceability . Springer London, 2012, ISBN 978-1-4471-2238-8 , pp. 3–22 , doi : 10.1007 / 978-1-4471-2239-5_1 ( springer.com [accessed December 19, 2016]).