The requirement analysis (English: Requirement engineering, RH) is a part of the software and system development process. It serves for it to determine the requirements of the client to the system which can be developed (multiple an application program). These requirements become thereby in a document which so-called requirement catalog, in writing fixes. Here the software requirement Specification can be used.

The requirement analysis effected in an early phase of the software development process and has crucial influence on the trial process and on the quality and productivity of the system developing thereby, in the long run thus on its suitability and acceptance from view of the user and on the maintenance from view of the developer. Therefore here special care is recommended.

The requirement analysis normally becomes in the dialogue between the customer (in the best case the final user) and the developers provided. It requires an obligingness on both sides, since the customer (client) in the rarest cases with the technical terms of the developer can begin somewhat, and turned around the developer not had profound knowledge in the field of activity of the customer. Thus a kind is "„translation process "“between the language of the customer and that of the developer of emergencies, that takes place in the dialogue as iterative as possible.

The analysis consists of the steps requirement admission, requirement structuring and requirement evaluation. In order to obtain a good result of analysis, it is advisable to consider the following criteria:

Admission and collection

In the step of the requirement admission, thus the collection, description and documentation of the requirements, is the translation process between specialized technical and developer of special importance. The following criteria are to be fulfilled:

completely - all requirements of the customer do not have to be explicitly described, it may implicit acceptance of the customer over that system which can be developed give.

clearly defines/defined - precise definitions help to avoid misunderstandings between developers and clients.

understandably described - thus both the client and the developer at justifiable expenditure the entire requirement to read and understand can.

atomically - it may be described only one requirement per section or sentence. The criterion for a "“atom"” should be the Entscheidbarkeit of a requirement.

identifiably - each requirement must be clearly identifiable (e.g. over an identification or a number).

uniformly documents - the requirements and their sources should not have in different documents or different structures.

necessarily - laws are indispensable.

verifiably - the requirements should be linked with acceptance criteria, so that with the acceptance it can be examined whether the requirements were fulfilled (derivative of cases of test from the acceptance criteria).

back and forward-actionable - thus is on the one hand recognizable, whether each requirement was completely fulfilled and on the other hand for each implemented functionality is recognizable, from which requirement it results, thus not redundant is developed.

The result of the requirement admission is the work statement.

Structuring and tuning

After the collection a structuring and a classification of the requirements must be made. With the fact one reaches that the requirements become clearer. This again increases the understanding of the relations between the requirements. Criteria are here:

dependently - requirements must thereupon to be examined whether they can be realized only together or whether a requirement the condition for another is.

matching - requirements, which belong technical-logically together, should not be realized alone.

roll-referred - each user group has its own view on the requirements, which is to be supported thereby.

Further structuring possibilities are

Functional and not-functional requirements

Technically motivated (technical and technical) and technically motivated (only technical) requirements.

In such a way structured requirements must be co-ordinated then between customer and developer. This tuning can become if necessary an iterative process, which leads to the refinement of the requirements.

Examination and evaluation

After the structuring, partially also parallel to it, the quality assurance of the requirements takes place after these quality criteria:

correctly - the requirements must be in particular assertible.

feasiblly - the requirement must be realizable.

- which is not demanded by the client, no requirement is necessary.

priorisiert - it must be recognizable, which are most important to requirements. A goal of the prioritization is it to make frequently needed functions available before the fewer frequently needed. One reaches it by means of a quantification of the branches of function.

usable, useful - also with partial realization a productive system is to already develop.

user friendly - the user friendliness of the system must be guaranteed.

The result of the examination represents the basis for product requirement specifications.

Related links

• Working group "“requirement"” the GI/GChACM Regionalgruppe Munich

Literature

• Christof Ebert: Systematic requirement management. Dpunkt publishing house, Heidelberg 2005, ISBN 3898643360
• Colin Hood: Optimize from requirements management & engineering with the HOOD Capability Model. Springer publishing house, Berlin 2005, ISBN 3540211780
• Suzanne Robertson, James Robertson: Mast ring the requirements Process. Addison-Wesley Professional, Boston, Massachusetts 2nd edition 2006, ISBN 0321419499
• Chris Rupp: Requirement engineering and - management. 3. Edition. Hanser technical book publishing house, Munich 2004, ISBN 3446228772
• Bruno seeming man: Continuous requirement management: Processes - techniques - tools. Addison-Wesley, Munich 2001, ISBN 3827317878
• Karl E. Wiegers: Software requirement. Microsoft press, talking moon, Washington 2nd edition 2003, ISBN 0735618798

Articles in category "Requirement analysis"

We found here 5 articles.

Related Websites

We found here 4 related websites.

• 13 common objections against user requirements analysis
  Sim D'Hertefelt, 9 June 2000. Why user experience disasters happen at the start of web projects explains that before designing an interactive solution, ...


• Online and Distributed Learning :: Hot Topics ::
  Requirement Analysis. The best approach to design, delivery and evaluation of courses involves a requirements driven approach. ...


• Requirement Analysis
  Requirement Analysis. Contents. 1 Scope of this Document ... 2 GridLab Requirements and User Scenarios. 3. 3 Requirement Analysis for WP8 ...


• Requirements analysis - Wikipedia, the free encyclopedia
  Requirements analysis is an important part of the system design process, whereby requirements ... Requirements analysis is also known under other names: ...