Requirements analysis (IT)

from Wikipedia, the free encyclopedia

The requirement analysis (English requirements analysis is) in the computer science a part of the system development process (u. A. In addition to the request management ), and a part of the business analysis . The aim is to determine, structure and check the requirements of the client for the system to be developed . The result of a requirements analysis is usually documented in a specification or, in the case of agile software development , a product backlog results .

Components

Leading organizations name the following components for the requirements analysis:

According to IEEE

According to the IEEE , requirements engineering can be divided into:

These activities overlap and are often carried out several times - iteratively .

According to CMMI

The Software Engineering Institute (SEI) at Carnegie Mellon University distinguishes integration in its Capability Maturity Model

  • the development of requirements and
  • the management of requirements.

After Volere

In the process model developed by the Robertsons, Volere exist

  • Requirement specification,
  • Stakeholder analysis,
  • Needs analysis,
  • Analysis of the prioritization and
  • Recording of the elementary requirements.

According to IIBA

The International Institute of Business Analysis lists three chapters on this topic in the Business Analysis Body of Knowledge :

  • Requirements elicitation: Identify stakeholder requirements,
  • Requirements management & communication: manage and communicate requirements, identify reusable requirements, compile requirements, prepare requirements for approval, manage requirement changes,
  • Requirements analysis: prioritize and structure requirements, document requirements in text form, document requirements with graphics / models, check for quality of content, check for compliance with goals.

According to IREB

The International Requirements Engineering Board lists four chapters on this subject in the textbook for certification as a Certified Professional for Requirements Engineering:

  • Determine: When determining the requirements, various techniques are used to extract, detail, and refine the requirements of stakeholders and other sources.
  • Documentation: The documentation adequately describes the requirements that have been developed.
  • Check and coordinate: Documented requirements must be checked and coordinated at an early stage in order to ensure that they meet all required quality criteria.
  • Manage: Requirements management takes place alongside all other activities and includes all measures that are necessary to structure requirements, to prepare them for different roles and to change and implement them consistently.

Action

In all of the above models, the following steps exist in one form or another. Requirements are collected (English elicitation ); a common understanding is to be established through analysis; the requirements are documented in text form or in models, d. H. specified. Then it is usually checked whether the whole thing is still correct (English validation ). Administration and management of the process exists around these steps.

Investigation, analysis

When collecting the requirements (elicitation), the translation process between the technical side and the developer is of particular importance. The following criteria must be met:

Completely
All customer requirements must be explicitly described; the customer must not make any implicit assumptions about the system to be developed.
clearly defined / delimited
Precise definitions help to avoid misunderstandings between developer and client.
clearly described
So that both the client and the developer can read and understand the entire requirements with reasonable effort.
atomic
Only one requirement per section or sentence may be described. The criterion for an “atom” should be whether a requirement can be decided.
identifiable
Each requirement must be clearly identifiable (e.g. via an identifier or number).
uniformly documented
The requirements and their sources should not be in different documents or have different structures.
verifiable
The requirements should be linked to acceptance criteria so that it can be checked during acceptance whether the requirements have been met. Test cases are derived from the acceptance criteria. See also verification .
traceable backwards and forwards
It must be possible to trace whether a requirement has been fully met (forwards). It should also be possible to control for each implemented functionality the requirements based on which it is created (backwards) in order to avoid superfluous things. See traceability (requirements management) .
consistent
The defined requirements do not contradict one another.

The result of the requirements recording is a list of requirements. This can e.g. B. be transferred to a specification sheet .

Structuring and coordination

After recording, the requirements must be structured and classified. This makes the requirements clearer. This in turn increases understanding of the relationships between the requirements. The criteria here are:

dependent
Requirements must be checked to see whether one requirement is the prerequisite for another, whether they are mutually dependent or whether they can be implemented independently of one another.
belonging together
Requirements that belong together technically and logically should not be realized alone.
role-related
Each user group has its own view of the requirements that are to be supported, see user role .

Further structuring options are functional and non-functional requirements as well as professionally motivated (professional and technical) and technically motivated (only technical) requirements. The requirements structured in this way must then be coordinated between the customer and the developer. This coordination can possibly become an iterative process that leads to the refinement of the requirements.

Testing and evaluation

After the structuring, in some cases in parallel, the quality assurance of the requirements takes place according to quality characteristics:

correctly
The requirements must be free of contradictions. See correctness .
makeable
The requirement must be realizable. See feasibility .
necessary
What is not required by the client is not a requirement.
prioritized
It must be clear which requirements are the most important. The aim of prioritization is to provide functions that are frequently required or that are particularly important to the customer before those that are less frequently required. It is achieved by quantifying the functional branches.
usable, useful
Even with partial implementation, a productive system should already be created.

The result of the test forms the basis for the specifications . The evaluations are partly in competition with one another. A productive system does not automatically result in the implementation of tasks that only have high priority. In the evaluation, not only the individual functions are to be considered, but also their effects in the overall system.

literature

  • Christof Ebert : Systematic Requirements Engineering and Management . 4th edition. dpunkt.Verlag, Heidelberg 2012, ISBN 978-3-89864-812-7 .
  • Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz: Requirements Management: Interface Between Requirements Development and All Other Engineering Processes . Springer, Berlin 2007, ISBN 3-540-47689-X .
  • Helmuth Partsch: Systematic requirements engineering . 2nd Edition. Springer, Heidelberg 2010, ISBN 978-3-642-05357-3 .
  • Klaus Pohl : Requirements engineering: basics, principles, techniques . dpunkt.Verlag, Heidelberg 2008, ISBN 3-89864-550-9 .
  • Suzanne Robertson, James Robertson: Mastering the Requirements Process . 2nd Edition. Addison-Wesley Professional, Boston, Massachusetts 2006, ISBN 0-321-41949-9 .
  • Chris Rupp & the SOPHIST: Requirements Engineering and Management. Professional, iterative requirements analysis for practice . Hanser, 2009, ISBN 3-446-41841-5 .
  • Bruno Schienmann: Continuous requirements management: processes - techniques - tools . Addison-Wesley, Munich 2001, ISBN 3-8273-1787-8 .
  • Götz Schmidt: Organization and Business Analysis - Methods and Techniques . 15th edition. Giessen 2015, ISBN 978-3-921313-93-0 .
  • Karl E. Wiegers: Software Requirements . 2nd Edition. Microsoft Press, Redmond, Washington 2003, ISBN 0-7356-1879-8 .

Web links

Individual evidence

  1. ↑ Alain Abran, James W. Moore (Ed.): SWEBOK: Guide to the Software Engineering Body of Knowledge . IEEE Computer Society, Los Alamitos, California, USA 2004, ISBN 0-7695-2330-7 , pp. 2-2 .
  2. ↑ CMMI Product Team: CMMI® for Development, Version 1.2, Improving processes for better products . Ed .: Software Engineering Institute, Carnegie Mellon. Pittsburgh, Pennsylvania 2006.
  3. ↑ http://www.volere.co.uk/books.htm
  4. ↑ Rupp, Chris 1967-, International Requirements Engineering Board: Basic knowledge of requirements engineering training and further education to become "Certified Professional for Requirements Engineering"; Foundation level according to the IREB standard . 4th, revised. Edition dpunkt-Verl, Heidelberg 2015, ISBN 978-3-86490-283-3 .

See also