Requirements management

from Wikipedia, the free encyclopedia

Requirements management ( AM ; English requirements management , RM ) comprises measures for the management, control and administration of requirements : risk management , change management and implementation management. It is used for the efficient and error-free development of complex systems that are worked on in a division of labor. Because problems with requirements mostly result from a lack of management of these. Simply setting up requirements is not enough; the process of requirements management is also necessary for the planning and implementation of a product or system.

Requirements management is a sub-area of ​​requirements engineering (RE) and business analysis . Their other disciplines are z. B. Requirements definition, requirements analysis , requirements documentation, requirements validation.

aims

The aim of requirements management is to achieve a common understanding of a system to be developed between the contractor and the client. This common understanding can (u. A. Through the introduction and implementation of requirements management methods scoping , requirements analysis , requirements specification , requirements modeling , requirements reviews ) can be achieved. By using these methods, the topicality and quality of the requirements documentation can be increased. Quality criteria of a requirements documentation are u. a. Comprehensibility , uniqueness , verifiability (traceability) , consistency , completeness, testability . For the semi-automatic check of some quality criteria, based on code smells , the requirements documentation can be searched for so-called requirements smells that reveal potential problems in the text. At the same time, the resulting documents are often used to create test cases and as a contractual basis for implementation.

Norms

Requirements management is one of the processes in the software and system maturity models CMMI and ISO / IEC 15504 (SPICE) as well as in the ISO / IEC 12207 standard . Requirements and characteristics for the creation of requirements are described in ISO / IEC / IEEE 29148 . Reference is also made to RFC 2119.

In Germany, a standard has been established for the uniform exchange of requirements: Requirements Interchange Format (ReqIF ™ , formerly RIF). ReqIF is defined by an XML schema and is a format and data model that contains structures for requirements, their attributes, types, access rights and relations (links).

language

The aim of a requirements specification (including the requirement specification , functional specification , technical concept ) is to formulate the requirements in such a way that a common understanding of the system to be developed is created between the client and the contractor. Natural language is used for the representation or a formalized natural language with restricted vocabulary and fixed sentence constructions, e.g. B. Set templates or requirements templates. Rules should be adhered to in order to improve the quality of the requirements. It is recommended, for example, to formulate short sentences, not to use imprecise adjectives and adverbs (so-called "weak words", such as faster, nicer, automatic, circa), as well as passive (e.g. "It can be calculated" ), but instead to name the acting system, and to avoid the subjunctive (e.g. “should” or “should”).

Requirements should not only make statements about the desired properties of a product or system, but also contain criteria for how these properties can be checked ( acceptance criteria ). These criteria serve the quality of the requirements themselves, as they stimulate a review of the content of the requirement.

In addition, artificial languages ​​are used for modeling such as B. UML or Message Sequence Charts (MSC) are used to document requirements.

Requirements management software

In order to structure a requirements management better to reduce redundancies and version / configuration management and traceability to enable (Requirements Traceability Engl.), Specialized software is used. This is usually based on a database in which the individual requirements are stored and followed up over time. The start of processing, the achievement of milestones and the (successful) completion of the work are noted for the requirements. The software usually also enables requirements to be related. For example, system requirements can be traced back to customer requirements. If this relationship is not apparent, there may be overengineering . In the same way, tests can be related to the requirements.

If standard programs for word processing or spreadsheets are used instead of specialized software, the traceability and relationships just described can often not be maintained or only with great effort.

See also

literature

  • C. Ebert: Systematic Requirements Management. 6th edition, Munich 2019. ISBN 978-3-86490-562-9 .
  • R. Fahney, Th. Gartung among others: Requirements engineering and project management. Berlin 2013. ISBN 978-3-642-29431-0 .
  • C. Hood, S. Wiedemann et al: Requirements Management: Interface Between Requirements Development and All Other Systems Engineering Processes. Berlin 2008. ISBN 978-3-540-47689-4 .
  • A. Naumann: Business Analysis - Systematic Requirements Management for User-Oriented Solutions. Giessen 2018. ISBN 978-3-945997-11-6 .
  • K. Pohl , C. Rupp : Basic knowledge of requirements engineering. 4th edition, Munich 2015, ISBN 978-3-86490-283-3 .
  • Chris Rupp & Die SOPHISTen: Requirements engineering and management: From practice from classic to agile. 6th edition, Munich 2014. ISBN 978-3-446-43893-4 .

Web links

Individual evidence

  1. ^ Karl Wiegers, Joy Beatty: Software Requirements . 3. Edition. Microsoft Press, US 2013, ISBN 978-0-7356-7966-5 .
  2. ^ Henning Femmer, Daniel Méndez Fernández, Stefan Wagner, Sebastian Eder: Rapid quality assurance with Requirements Smells . In: Journal of Systems and Software . tape 123 , 2017, p. 190–213 , doi : 10.1016 / j.jss.2016.02.047 , arxiv : 1611.08847 .
  3. ↑ ISO / IEC / IEEE 29148: 2011 - Systems and software engineering - Life cycle processes - Requirements engineering. Retrieved February 8, 2018 .
  4. ↑ Scott Bradner: Key words for use in RFCs to Indicate Requirement Levels. Retrieved June 5, 2020 .
  5. ↑ International Requirements Engineering Board (IREB): RE for Testers - Requirements Engineering Magazine. Retrieved on August 16, 2019 .