RE Methods

Requirements engineering, as discussed in Software Development, is the first phase within the development of a software system. The following phases are based on the information gathered and documented within requirements engineering. The output of the requirements engineering phase is the requirements model and the specification document.

The picture on the left shows the requirements engineering part of the system family development. Requirements engineering is divided in two main parts.

Domain analysis is part of the domain engineering activities and is focused on finding and organizing the relevant domain information. Here the family is evaluated according to business issues and domain relevant requirements are elaborated. The resulting information is used to decide wether or not it is worth continuing with the development of the familiy.

All informations about the family and the domain are stored in the Family Requirements Model. This model is the data storage for all kinds of information from simple hand drawings, meeting protocols up to UML diagrams to support the explanation of specific requirements.

Based on this model and thus based on the family, new applications will be analysed to check their applicability to the family. Is it possible to build a new application based on the family? Are the requirements of the new application inside the scope of the family? How many of the needed features can be taken out of the existing family and what features would have to be developed? ... These are the questions within the first phase of the application development.

Requirements enginineering addresses two major issues within software development. For both parties, the software company with the developers of the system and the customers together with the users of the system, requirements engineering has a vital impact on the success of the software project and the future product.

Requirements Engineering, according to [Hofm 2000] and [Somm 1997], can be devided into three main activities, which will be processed iteratively. The table below shows a brief overview of the current methods and technologies.

Elicitation What are we going to develop?	Modeling What will our system look like?	Verification / Validation Does the solution meet our needs?
Document Analysis Reading all available documents related to our domain and thus our problem. Interviews Talking to customers and people who will use the system to find out their requirements. To get compareable results the interview can be based upon a set of questions (-> Questionaire, Survey). Brainstorming Thinking about a specific problem and collecting all possible solution ideas without assessing them. Observation Observe how people do their job and how their behaviour can be transfered into a software system. RAD - Rapid Application Development / JAD - Joint Application Design Prototyping CREWS project Goal oriented and scenario based approach for eliciting and analysing requirements. Repertory Grid RUP - Rational Unified Process A use-case centered development method for single systems. Rational announced system family support for the next version of the RUP.	ODM - Organization Domain Modeling / Enterprise Modeling Understand how the organization is working, the product is developed for. DFD - Data Flow Diagrams How is the data organized, that will be processed by the system SADT - Structured Analysis and Design Technique ERM - Entity Relationship Modeling Petri Nets / Statecharts Object Models as used in the UML - use-cases (scenarios) - class diagrams SDL KAOS - Goal Models Viewpoint Models Prototyping	Peer Reviews Audits Walkthrough SFMEA - Software Failure Mode and Effects Analysis Tracing of Requirements, Artifacts and Arguments QFD - Quality Function Deployment SCR Win-Win approach
System Family related FAST - Family-Oriented Abstraction, Specification and Translation A system family development methodology using a domain specific language as the key concept. FeatuRSEB - Feature Oriented Reuse Driven Software Engineering Business A use-case centered development method for system families.	System Family related FODA - Feature Oriented Domain Analysis Organizes the domain engineering output in terms of features of the system. CARDS FRAMES A way of modelling variable systems with an extended version of the UML and, as the core idea, a way to "put together" several pieces of text - the frames - (code or other documents). Nokia's approach ... ... captures prioritzed design decisions and design objectives and offers a way to select needed requirements.	System Family related To be continued ...
Output The output is a list of interrelated requirements, information about the domain and information about the project itself.	Output Several models holding parts of the information of the elicitation phase. Each model represents a specific view.	Output For each requirement a procedure has to be defined, how to verify that a future implementation will satisfy the requirement. In addition developers and/or customers need to define procedures to validate that the developed and delivered software system meets the initially defined requirements.

The inhomogeneous picture drawn by the above table reflects the imature state of requirements enginereering for system families. The patchwork of methods, technologies and research ideas needs to be put together to form a consistent picture.

With the given importance of requirements engineering the quality of the data gathered throughout this development phase is strongly influenced by its consistency. A consistent data pool out of many pieces of information can only be fromed with a predefined data model . Throughout requirements engineering data of different types is elicited. With a predefined data model the developer knows where to put each piece of information and how all pieces fit together. The data model has to be ...

With a data model the developer knows "what" has to be elicited but "how" to elicit the data is still unclear. In addition to the data model a requirements engineering method is needed to support the approriate usage of the data model. The method has to be ...