Processes in Requirements Engineering

1. Processes in Requirements Engineering Raimundas Matulevičius SIF 8060 - Modellering av informasjonssystemer, 2003

2. Overview • Loucopoulos P., Karakostas V., “System Requirements Engineering, McGraw-Hill, 1995. Chapter 2. • Nguyen L., Swatman P. A., “Managing the Requirements Engineering Process”., in proc. REFSQ’2001

3. A Framework for describing RE Processes • Three fundamental concerns of RE: • Understanding of a problem. • Formally describing a problem. • Agreement on the nature of the problem. • The proposed framework focuses on the dynamics (‘how’) as opposed to the deliverables (‘what’) of RE. • Framework consists of 3 sub-processes: • Elicitation, Specification, Validation.

4. Framework for RE processes

5. How to understand process? • Each process is described in terms of the following: • The purpose of the process; • The input to the process and its origins; • The activities which take place during the process and techniques used; • The final and intermediate deliveries; • The interaction with other requirements engineering processes.

6. Requirements elicitation Purpose: • At the beginning, an analyst knows very little about the software problem to be solved. • Gain knowledge relevant to the problem, which can be used to produce a formal specification of the software need solve the problem. Input • Domain experts, literature about the domain, existing software systems, similar applications, national and international standards, other stakeholders. Activities • Identifying all the sources of requirements knowledge. • Acquiring the knowledge. • Deciding on the relevant of the knowledge to the problem in hand. • Understanding the significance of the elicited knowledge and its impact on the software requirements. • Reuse knowledge acquired in similar problem domains.

7. Requirements elicitation (cont.) Deliverables • Model creation process: start with conceptual models and end with the requirements specification model. • The analyst starts formulating models of the problem domain in the early stages of RE. • As the RE process progresses, the conceptual model s become more software oriented than problem domain oriented. Interactions • Elicitation can be viewed as providing ‘the raw material’ to other processes.

8. Requirements specification A specification can be viewed as a contract between user and software developers which defines the desired functional behavior of the software artifact, without showing how such functionality is going to be achieved. Purpose: • Agreement between the software developers and the users on what constitutes the problem which must by solved by the software system. • A blueprint for the development of the software system Input • From elicitation - ‘Raw knowledge’ should be converted into meaningful information in order to produce a formal specification model. • From validation – what is valid and what is not in the formal specification and as such it acts as a force for changing the formal requirements model. Activities • Analysis and assimilation of requirements knowledge. • Synthesis and organization of the knowledge into a coherent and logical requirements model.

9. Requirements specification (cont.) Deliverables • The majority of RE approaches assume that the outcome of this process is the requirements specification model: • User oriented models specifying the behavior, non-functional characteristics, etc., of the software which serve as point of understanding between the analyst, the customer and the user. • Developers-oriented models specifying the behavior, non-functional properties of the software system as well as constraints on resources, design constraints, etc, which act as blueprints for further development stages. Interactions • To elicitation - during specification it might apparent that more information about the model is required. • To validation –completion of some part of the specification model can cause the need for validation.

10. Requirements validation Requirements validation is an ongoing process of RE which aims to ensure that the right problem is being tackled at any time. Purpose: • Requirements validation certifies that the requirements model is consistent with customers’ and users’ intentions. • The need for validation: when a new piece of information is assimilated in the current requirements model and when different pieces of information are integrated into coherent whole. Input • Any (formal, semi-formal or informal) requirements model. Activities • Prepare the settings for an experiment. • Performing the experiment and analysis its results.

11. Requirements validation (cont.) Deliverables • Validation delivers a requirements model which is consistent and in accordance with the user’s expectations. Interaction • The need for validation is triggered by the acquisition of new knowledge about the problem domain (elicitation) or by the formulation of a requirements model (specification).

12. Comparison of terminology • Elicitation: • Requirements identification, requirements determination, requirements acquisition. • Specification: • Software requirements analysis, requirements analysis, problem analysis, problem definition, requirements definition. • The synthesis phase of specification contains activities: • external product description (specification of the functionality of software), • requirements presentation (in which the results of requirements identification are portrayed) • software requirements specification (complete documentation of what the software does externally) • Validation: • Requirements communication

13. Software development models • The waterflow model; • The spiral model; • The prototyping model; • The operational model; • The transformational model; • The knowledge-based model; • The domain analysis model.

14. The waterflow model • Software development consist of stepwise transformation from the problem domain to the solution through a number of phrases which are wholly satisfied before their successors begin. • Critics: • Lack of user involvement in the development after requirements specification has ended. • Inflexibility to accommodate prototypes. • Unrealistic separation of specification from design. • Inability to accommodate reused software. • Maintainability problems. • Complicated system integration. • Waterflow model takes a static viewpoint of RE by ignoring issues such as inherently dynamic nature (volatility of requirements and its impact on earlier and later phrases of development)

15. The spiral model • Organizes the iterative nature of development and the need to plan and assess risk at each iteration. • Activities: • Plan next stage; • Determine objectives, alternatives, constraints; • Evaluate alternatives, identify and resolve risks; • Develop, verify next level product • The spiral model introduces additional sub-processes of RE known as requirements risk analysis, using techniques such as simulation, prototyping.

16. The prototyping model • Constructs and experiments with a mock-up version of the software system, in order to gain some understanding of the functionality and behavior required from it. • Prototyping has to be constructed for one of the following reasons: • To understand the requirements for the user interface • To examine the feasibility of proposed design approach. • To understand system performance issues. • After several revisions: • Refine the prototype into a complete system • Begin a conventional development process having benefited from developing the prototype. • RE framework in prototyping context: • Elicitation of requirements is achieved by involving the user in experimental use of the prototype. • Analysis of requirements is done by analyzing the structure and behavior of the prototype. • Formal specification coincides with prototype development. • Validation is achieved by validating the prototype against the users’ intentions.

17. The operational model • System model, that can be evaluated or executed in order to generate the behavior of the software system. Purpose is to analyze not only required behavior but also required structure. • How to decompose the problem domain functions into succession of lower-level functions. • How to introduce features such as information hiding and abstraction into the design. • How to take into account implementation issues. • Decisions about the structure should be made early in the development lifecycle. • RE framework in operational context: • Elicitation is carried out at an initial stage (the construction of the operational specification) • Specification coincides with the construction of an executable specification model. • Validation coincides with the exercise of the operational specification model.

18. The transformational model • Attempts to automate labor-intensive stages of development such as design and implementation by using the concept of transformation. • A transformation is defined as mapping from a more abstract object (such as specification) to a less abstract one (such as design or piece of code). • In order to make transformations – object should be represented in abstract way. • RE framework in transformational context: • Requirements elicitation is the phase which derives an initial informal and incomplete requirements model, prior starting transformational development. • Requirements specification produces the formal specification model. • Requirements validation is the transformational phase where the formal model is validated by the user.

19. The knowledge based model • “Intelligent” implies that the tools incorporate a knowledge-base: • Knowledge about how to perform some aspects of RE. • Knowledge about the characteristics of some problem domain, which can be employed in RE. • The major difference between knowledge based and non-knowledge-based approaches exist in the degree of intelligent tool usage in a process within RE.

20. The domain analysis model • An activity, that takes place prior to RE. While RE is concerned with analysis and specifying the problem of developing of a application, domain analysis has been concerned with identifying commonalities between different applications under the same domain. • Phases such as problem understanding which are traditionally considered in RE are reduced to ‘selecting and retrieving the contents of the appropriate library which contains the analysis of the domain under consideration. • The effort for requirements elicitation is significantly reduced since to a large extent elicitation has already be done as part of domain analysis. • Requirements specification consist of selection of an appropriate component from the reusable analysis of components library with possible adaptation if necessary. • The need for validation is reduced since the library components have already been validated as part of domain analysis.

21. Managing RE process • A formal requirements specification is the end-product of a large number of decisions, negotiations and assumptions made throughout RE process and such a specification is valid as the assumptions and decisions which underlie it. • It is important to be able to recreate the rationale behind some specification item in order to question its appropriateness and validity in the light of changed circumstances. • This not possible without assistance from rationale recording process which runs throughout RE: • Provides a communication mechanism among the members of the development team • The effort required to produce the rationale behind a specification forces requirements engineers to deliberate more carefully about their decisions. • IBIS – Issue-based Information System

22. Conclusions • Requirements elicitation - the process of acquiring all the necessary knowledge which is used in production of formal requirements specification model. • Requirements specification – the process which receives input the deliverables of requirements elicitation in order to create a formal model of requirements. • Requirements validation – the process which attempts to certify that the produced formal requirements model satisfies the users’ needs.

23. Some other RE approaches • Pohl (1994) dimensions • Representation, Agreement, Specification • Kotonya, Sommerville (1998) activities • Elicitation, Analysis and negotiation, Documentation, Validation • Management – is the process of managing changes to a system’s requirements. • Ferdinandi (2002) activities • Requirements process/development • Allocation, Elicitation, Analysis, Specification, Validation, Approval • Requirements management • Configuration identification, Baseline Management, Change Control, Library control, Status control, Reviews and Audits.

24. Managing the Requirements Engineering Process • Nguyen L., Swatman P. A., “Managing the Requirements Engineering Process”., in proc. REFSQ’2001

25. Overview of research project • Design explanation, which represents and explains the rationale behind the design activities can provide the system developer and the project manager with many potential benefits in understanding and monitoring the RE process. • Action research: • involves a conscious effort of the researcher to apply a theory in a real-world situation to test the theory and in turn, provide practical outcomes for theory building. • Limitations - the difficulty in generalization of the results, the subjectivity of the approach. • Setting – systematic documentation of the requirements model and underlying arguments could be useful in understanding the evolution of requirements and in monitoring and improving RE processes. • FOOM (Formal Object Oriented Method) is based on a synthesis of socio-organizational theory, the object-oriented approach, and mathematical formal specification.

26. Research process • The RE process was cyclic with each cycle consisting of the elicitation, modeling and validation of requirements. • Requirements discussions, analyses and decisions were captured and documented using design explanation. • Issue-Based Information System (IBIS) • Question-Option-Criteria notation.

27. Interpretation of Research Findings • These cycles resulted in a new, significant understanding of the RE process and a new approach to using design explanation within it. • The process of RE was found not to be a smooth and incremental evolution, but the one which involved occasional “crisis” points at which the requirements model was reconceptualised, restructured and simplified. – FIG.3. • During the process, the problem space was continuously explored and structured Components of the requirements model were introduced as new information was being acquired, accumulated and represented. The overall complexity grow in time. • At the critical point, the problem was reconceptualised, the problem space was reshaped and the model was simplified and restructured. The complexity of the requirements model was reduced significantly.

28. Implications of Research Findings • New Challenges • Since current systems development life cycle models, approaches and tools tend to impose an incremental evolution of the requirements model, they should be critically reviewed whether they assist or handicap the systems developer and project manager. • Based on new understanding of the RE process, how best can we monitor and manage it? • Understanding complexity • The essential complexity reflects the intrinsic understanding of the problem. This complexity increases as the problem space is explored and our understanding is expanded. • The incidental complexity represents the complexity of expression/representation rather than of substance in the model. • Findings: • RE is creative and opportunistic. • Extends the understanding by revealing the effects of creative and opportunistic insights in problem understanding and solving activity. • Suggests a way of increasing these effects using a post hoc examination of the problem space.

29. Implications of Research Findings • The system developers: • continually explore and develop their understanding of requirements problem • radically reconceptualize the problem of different perspectives at some stages. • The complexity of the requirements model, if being well monitored, would signal the project/process manager when managerial actions might be needed. • There is a need to document the rationale behind the RE process: • The IBIS base describes in chronological order, how requirements evolve over time. • IBIS arguments need to be reviewed and converted into QOC analyses to aid the evolution of the requirements model as a whole. • Supporting Creativity of the RE process • IBIS: reflection-in-action; QOC: reflection-on-action

30. Implications of Research Findings • Most current CASE tools are neither syntax directed or based on form of orderly editor which support the cumulative and incremental model of specification development. • Future CASE tools need to provide the requirements engineer with flexible environment, which promotes design reflectivity and creativity and supports reconceptualization of the problem and major restructuring of specification. • How we can (and should) train requirements engineers to work effectively in an environment, where insight and creativity are required, now becomes a central issue in Information Technology education.

31. Conclusions and Future Research • New understanding of RE process: • The complexity in the RE over time should be monitored. • Design explanation can be used to provide the rationale behind the dynamics of the complexity in requirements model. • The design explanation base and the complexity of the model being monitored enable to understand the on-going creative process. • Future research: • Consolidating theory; • Further developing the new understanding; • Testing the catastrophe-cycle model and evaluating the new approach to using design explanation.

32. Summary • Requirements engineering: • Elicitation, Specification, Validation; • Software development models; • Requirements management: • Maintain rationale behind requirements; • Look for new methods for RE process.