 |  |  | FAQ Requirements Engineering
|
 |  |  |  |  |  |  |  |  |  |
 |  |  | What does „RE“ mean? |  |  |  |  |  |  |
 |  |
|  |  |  |  |  |  |
 |  | RE is short for Requirements Engineering.
Requirements Engineering includes requirements analysis, that is eliciting, phrasing and validating of requirements as well as requirements management, both with engineers attitude. |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Which other concepts belong to this field? |
 |  |  |
|  |  |  |  |  |  |
 |  |  | > System Analysis
> Requirement Specifications, Customer
> Requirement Specifications, Supplier
> Concepts
> Requirements Document
> Acceptance Criteria
> Glossaries
> Knowledge |  | > Requirements Management
> Stakeholders
> Non formal, partialy formal and formal models
> Prototypes
> Use Cases
> UML-Diagrams |
 |  |  |
|  |  |  |  |  |  |
 |  |  | How is „RE“ defined? |  |  |  |  |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Our own definition: Requirements Engineering includes the requirements analysis and the requirements management with engineering like procedure.
Whereas IEEE writes: Requirements Engineering (RE) is the branch of systems engineering concerned with managing desired properties and constraints of software-intensive systems and with goals to be achieved in the environment. It is concerned with these aspects from the problem analysis stage to the implementation and maintenance stages of a system. Additional variety is added because of differences in issues that arise in different domains, ranging from public administration software to workflow systems, groupware and embedded systems and control software. |
 |  |  |
|  |  |  |  |  |  |
 |  |  | RE, necessary for what? |  |  |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Requirements Engineering is needed to define requirements of accomplishments of a product, a process, or the persons involved. Next to this rather technical aspect, the social goal should not be forgotten: toward the end of the RE-activities the stakeholders should agree with the developers about the requirements. Requirements engineering includes eliciting , phrasing, validating and managing of requirements and has decisive consequences on the quality of the evolving systems. The results of requirements engineering, meaning the various requirements documentations, are guidelines for the system producer, indicating the functionalities and which quality the system has to possess after completion. |
 |  |  |
|  |  |  |  |  |  |
 |  |  | In which situation is RE used? |  |  |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Actually, requirements engineering is used already with first thoughts about how a system is supposed to function. The larger the system to be developed, the more demanding are expectations to the defined requirements engineering process and to the documentation of results. The same goes for the changes in an existing system. In general, the requirements are defined by internal or external system analysts together with the stakeholders.
|
 |  |  |
|  |  |  |  |  |  |
 |  |  | What can happen if RE is not applied? |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | If Requirements Engineering is not applied, it may be that: |
 |  |  | > the system is not accepted by the users, because they were not taken into consideration
> the system is faulty, because the system was build on presumptions of the developers alone
> the time of project maturity is prolonged, because of missing coordination, due to missing requirements documents from various departments
> the project fails completely, because the system was not implemented in time or in budget, due to missing or inadequate requirements |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Who would, typically, use RE? |  |  |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | Requirements Engineering has an impact to every system development process. There is only the question in which detail is this process defined in the respective project. If small changes can be discussed directly between two people, it may be, that an RE process is only slightly in demand. However, for requirements analysis for a safety critical system, a more defined RE process is essential, due to the need for more documentation and cooperation. |
 |  |  |
|  |  |  |  |  |  |
 |  |  | How much does RE cost, what does it deliver? |  |  |
 |  | |  |  |  |  |  |  |  |
 |  |  | If an RE process is taken seriously, in order to describe the requirements to the system unambiguous, consistent, complete and testable, RE will rise the cost of the project in the early phases of system development. However, by having a good requirements analysis, many errors in the system may be noticed and avoided in the very beginning whereby, in the long run, the total project time is reduced substantially. Assume, to correct a found error during the requirements analysis, one man day is needed. The same would use up about 10 man days in the design phase, and would use up about 100 man days in the phase of implementation and beyond. |
 |  |  |
|  |  |  |  |  |  |
 |  |  | What kind of training is needed for using RE? |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | It is necessary to have the knowledge to describe technical issues unambiguous, consistent, complete and readable. Another point is to have the capability of good communication, in order to phrase requirements as they are presented by other persons. In case of missing knowledge of how to write requirements to a system, the recommendation is to take a few days of introductional training in order to acquire these techniques.
|
 |  |  |
|  |  |  |  |  |  |
 |  |  | Which website/books are providing additional information? |  |  |
 |  |  |
|  |  |  |  |  |  |
 |  |  | > www.sophist.de
> The German Association for Information Technology – Requirements Engineering Chapter: www.iese.fhg.de/gi_fgrq
> The RE-Online-Mailing-List of the University of Technology Sydney:
http://research.it.uts.edu.au/re/ |  |
> www.systemsguild.com
> Requirements-Engineering Research Group – Uni Zurich:
www.ifi.unizh.ch/groups/req |
 |  |  | > Gause, D.C.; Weinberg, G.M.: Software Requirements Munich, Hanser Verlag 1993, ISBN 3-446-17113-4
> Partsch, H.: Requirements-Engineering systematisch - Modellbildung für softwaregestützte Systeme. Berlin – Heidelberg, Springer 1998, ISBN 3-540-64391-5
> Robertson, S.; Robertson, J.: Mastering the Requirements Process. Reading/MA, Addison Wesley 1999, ISBN 0-201-36046-2 |  | > Rupp, C.: Requirements Engineering und –Management, Hanser Verlag 2002, ISBN 3-446-21960-9
> Schienmann, B.: Anforderungsmanagement, Munich, Addison-Wesley 2002, ISBN 3-8273-1787-8
> Sommerville, I.; Kantonya, G.: Requirements Engineering Processes and Techniques, Chichester, New York, Wiley 1997, ISBN 0-471-97208-8
> Sommerville, I.; Sawyer, P.: Requirements Engineering, John Wiley & Sons 1997, ISBN 0-471-97444-7 |