A Proposal for a Requirements Engineering Process Focused on the User Need Oscar Dieste Software Engineering Dep. Madrid Technical University
[email protected]
Marta López Computer Science Dep. A Coruña University
[email protected]
Ana María Moreno Software Engineering Dep. Madrid Technical University
[email protected]
The growing importance of the Requirements Engineering phase in global software product development gives rise to the need to define process models suited for this phase. This paper describes a process model, now under development, that we believe will solve some of the problems detected in the earlier process models proposed for the Requirements Engineering phase.
more detail than the traditional approaches, because the activities they define for performing the RE phase are already excessively generic. More new and elaborated processes, such as Pohl’s [10], or the new framework proposed by the SWEBOK project [11], have been recently defined, but our position is that the above-mentioned goals are not yet achieved. So, our research is based on the hypothesis that all these processes now in use have significant shortcomings with regard to RE phase performance.
1. Introduction
2. Working Hypothesis
The need to define a detailed process for the Requirements Engineering (RE) phase is relatively new [1]. The process models that have been defined to date, such as the waterfall [2], prototyping [3] and spiral [4] models or the more modern IEEE model [5], encompass the entire development process and provide no more insight into the content of the RE phase than a division into the generic activities of Analysis and Specification [6]. Gradual recognition of the importance of the RE phase in software development has called for the definition of a more detailed process for this phase. Below the definition of such new processes, there exists two goals: first, to provide suitable support to software engineers for performing their job; and, second, to make it easier for managers to plan, monitor and control the RE phase. The processes defined by Loucopoulos [7], Wieringa [8] or Jalote [9] fall into this category. Generally, these processes are composed of three tasks: Elicitation, where information is acquired about the user needs and environment; Modelling, where one or more conceptual models (CM) are built to represent the problem under analysis; and, finally, Validation, where the faithfulness of the model is tested by means of interaction with the user. Nevertheless, all these processes do not provide much
A series of deficiencies have been identified in current RE process models from the literature and on the basis of our experience. These deficiencies are rooted in three different domains: theory, practice and education. In the theoretical domain, theoreticians have been convinced for some time that the different approaches to the RE phase are defective. The deficiencies centre on two points:
Abstract
• In the first place, as we said above, RE process models are excessively generic, and thus they do not help analysts for doing their work. This is especially evident when the analyst is a novice software engineer [12]. • In the second place, the methods and techniques used in the RE phase tend to anticipate the structure of the software system, thereby distorting the purpose of the RE phase. Several authors have pointed this out. For example, Høydalsvik [13] establishes that the techniques used in OO are Oriented to the Software System, as they are directly related to the OO development approach. Høydalsvik stresses the need for the use of analysis techniques that are independent of the development
approach in software systems development. He refers to such analysis techniques as Problem-Oriented Methods. The same approach has been proposed by Loucopoulos [7], who claims that the analysis process should necessarily output two product types: User-Oriented Models that describe the behaviour and non-functional characteristics of the software and serve as a basis for software engineers, customers and users to understand each other; followed by Developer-Oriented Models that specify the functional and non-functional system features and the different types of applicable constraints. Beringer [14] and Jackson [15] pursue a similar line, stating that current analysis methods focus on the characteristics and structure of the solution rather than on the problem to be solved. This idea has been supported by [16], who claims: “...there is a need for a new class of specification, one that is more oriented to the world of the user than is permitted by current specification methods”. Furthermore, this dependence between techniques and development approaches means that the same philosophy has to be used throughout all the development phases and, therefore, determines the manner in which the software system is to be built [9] [17]. Accordingly, and bearing in mind that each development approach is better suited for addressing a particular spectrum of problems [6], there is little prospect of the software engineer switching to a different approach after having analysed the problem, even if the approach selected originally proves not to be the best suited for the need raised at the end of this activity. All this means that the user need is often adapted to a particular way of building software rather than the artefacts that are best suited for the need rose being used. This redounds upon the quality of the software products developed, as it gratuitously raises software construction complexity, with the resulting impact on both development and maintenance time and costs. In the practical domain, our research team have found, from their experience in development projects, that the current RE processes are deficient in that they do not allow software engineers to understand the user need independently of the development process and thus, having understood the above need, to select the development approach best suited to satisfy such need (Structured Analysis –SA-, Object Oriented Analysis – OO-, real-time systems –RT-, etc.). Note that models of any class act as filters of the real world they represent: they stress the interesting points and hide unimportant details. This essential feature of modelling is also present in the techniques used in
software development. Each technique stresses particular attributes of the information that it represents. So, during problem analysis, software engineers are led by the relationship of dependence between analysis techniques and development approaches. In that way they represent the user need according to the concepts supported by the chosen analysis technique. Thus, these techniques acts as a filter, allowing particular problem issues to be represented and, particularly, those that will be used to develop the system, that is, the representation is conditioned by the peculiarities of each individual approach (SA, OO, RT, etc.). Finally, in the educational domain, Software Engineering students at our school find it very difficult to make the transition from the user need to the construction of the CM’s to be developed during the RE phase, in a sense very close to the stated in the work of Sutcliffe and Maiden [12]. There exist problems, too, for making the transition from the CM’s to a software design, because both concepts are strongly interleaved in student’s minds. Students do not differentiate between CM construction and software design, and thus they often introduce design considerations in the CM’s, making harder the development of such models. On the basis of the above observations, the following working hypotheses have been established with the goal of defining a new process for the RE phase: 1. It is essential to understand the need raised by the user before considering an approach for developing a software system that satisfies the above need. 2. This process must be implemented independently of the selected problem-solving approach, that is, it must not precondition the use of a development approach. 3. It would be advisable, once the user need has been understood, that there will be criteria for selecting the best development approach. This solution was arrived at by taking into account that the development process can be considered as related to both the user need space and the machine space, that is, the space of the software that will meet the need raised by the user, as shown in figure 1. This idea was also expressed by Blum [18], who stated that the software construction process must be composed of two completely separate moments: the moment of orientation to the user and his/her need and the moment of orientation to the machine and the software solution. This is the philosophy that we intend to employ in order to redefine the software construction process, clearly separating the moment of orientation to the need and the moment of orientation to the software system. So, the RE phase should be directly related to the need space, whereas
later phases will be related to the system space. This philosophy is described in the next section. User Need Space Real-World Objects and Operations
Real-World Algorithm
Real-World Objects
Problem Representation
Machine Objects and Operations
Results Interpretation
Computer Algorithm
Output Data
Machine Space
Figure 1. Problem space versus machine space.
3. Proposed Process Restructuring the development process involves making a series of alterations to its phases and, particularly, to RE and, as a result, to design. The first change is motivated by the abolition of the traditional
distinction between RE and design. As viewed traditionally, the RE phase establishes what the user requires and design establishes how to build software that meets that need [6] [7]. The reason for eliminating this separation is that the what and how of the process in the user world has to be known in order to understand a problem (which is the goal of the RE process). That is, we need to know what tasks the need involves and how they are implemented in the user world. In this sense, the division between the RE and design phases does not refer to what and how, but to the distinction between the user world and the machine world. Figure 2 illustrates the process, showing the RE and design phases, and the products to be outputted in each phase. Specifically, research within the RE phase should centre on the activity of Problem Analysis, or what other authors refer to as Modelling, as discussed in section 1. We have centred our research on the activity of Analysis, because the problems, specified in section 2, which we intend to address, refer to the understanding and representation of user needs, tasks that are proper to the analysis. Before describing figure 2 in detail, the meaning of some terms related to the different types of models is explained:
REAL WORLD UN DE RS TA ND IN G
N O TI TA N E ES PR RE
----------
----------
DESCRIPTIVE MODEL OF THE CURRENT SITUATION
A N
-----
-----
A
-----
L
-----
Y COMPUTATIONAL REQUIREMENTS
SOFTWARE ENGINEER
S I PROSPECTIVE MODEL OF THE FUTURE SITUATION
-----
S
-------------
COMPUTER WORLD AC TIO N
D ENTRY
E PRESCRIPTIVE MODEL OF THE SOLUTION
S I G N
Figure 2. Diagram of the new development process, showing the analysis and design phases.
• Descriptive models: represent a given reality that exists prior to the model. • Prospective models: explore future possibilities based on present evidence. • Prescriptive models: describe a reality that does not exist and will have to be created on the basis of the respective model. The difference between descriptive, prospective and prescriptive models stems from the fact that, in the case Activity Environment Analysis Analysis
Design
of descriptive and prospective models, if there is a difference between the product represented and the model, the model is incorrect. On the other hand, should any such difference exist in the case of prescriptive models, it will be the future reality, and not the models, that is incorrect. Table 1 details the activities to be performed during both analysis and design, and the inputs and outputs of each phase. We will discuss each activity, but the details provided are variable, because we are already researching on this topic.
Input Output − Information from reality − Descriptive Model (structure and behaviour) Current Situation
of
the
Customer Problem − Descriptive Model of the − Prospective Model of the Future Analysis Current Situation Situation − Problems − New Needs Software Solution − Prospective Model of the Future − Solution Characterisation Conception Situation System Mapping − Prospective Model of the Future − Prescriptive Software System Situation Model − Solution Characterisation Table 1. Activities to be performed during the new analysis and design process.
3.1. Customer / user environment analysis The first task within analysis is what is called Customer and/or User Environment Analysis. The goal of this task is to delimit and represent the customer environment so that it can be understood. For this purpose, the current user situation is represented in what is called a Descriptive Model of the Current Situation (DMCS), in accordance with the hypotheses described in section 2. Modelling techniques that are independent of the software development approach (OO, SA, RT, etc.) have to be applied to build this model. We are now researching into possible techniques that could be applicable to this activity, with positive results. The first step was to study the existing analysis techniques. These were characterised and their usefulness for this phase was examined [19]. The results of this evaluation can be summarised as the identification of three technique types: 1. Solution-oriented techniques: Oblige analysts to address computational issues during analysis. The models thus developed prescribe a particular design. It will take, at best, a lot of time and effort to transfer the concepts outputted by the analysis
phase to an alternative design. This transformation is often out of the question. 2. Isolated techniques: Do not determine which sequence of activities has to be performed to derive a design. Their use in the subsequent software development process phases is limited, since, while they provide software engineers with an understanding of the problem, they offer no support for deciding which design to adopt, nor do they allow the above design to be derived. Most of the techniques used in RE phase fall into the above two groups. This means that these techniques are not suitable for performing the analysis phase, as they either do not allow a design to be generated or they prescribe the use of a single design type, ruling out exploration of alternative development approaches, but there is a fraction that cannot be classed in either of the above groups. These techniques have been considered as "problem-oriented" techniques. These techniques have the following characteristics: 3. Problem-oriented techniques. The techniques included in this group are really effective for analysing a real-world problem without bringing in clearly computational issues or introducing
constraints too early on in the development of a computerised solution. Unfortunately, they can only be used partially in the development process, or they provide a limited capability for deriving a particular design from the information contained in their models.
A resume of this evaluation is shown in figure 3.The next step will be to define, a set of problem-oriented techniques that could be used on the whole development process, and not only partially, and test their usefulness in real projects.
Isolated TELOS
Decision Tree
Finite-state machine
Use cases
Problem-oriented
Declarative Dynamic Models
KAOS EM
Decision Table
EER FDM
Hipergraph SADT
ER Scenarios
Solution-oriented
State-Transition Diagram
Minispecification DFD/RT
Operational Dynamic Models
DFD
CFD
Data Dictionary
Object-Oriented Models PSL/PSA
PDL
Event traces
Figure 3. Classification included in [19]. [19].
3.2. Customer problem analysis The goal of the second analysis task, Customer Problem Analysis, is to modify the DMCS, inputting future needs. This task will output the Prospective Model of the Future Situation (PMFS) that will represent the future structure of the domain. The techniques to be applied to represent the PMFS will be basically the same as are used to represent the DMCS, since the goal in both cases is to understand the user needs in order to later select the best approach for developing the software system that will meet the above needs. Note that both the what and the how of the user need has to be represented for the need to be understood, which means that these models will have to allow both types of information to be represented.
3.3 Software Solution Conception Having understood the user need, we have to determine how it can be satisfied by software. This activity falls into what we have termed the machine world. This world can
be divided into design, implementation and testing activities, etc. Specifically, the study will centre on design, for which two tasks have been identified. The first, called Software Solution Conception has the goal of conceiving the type of software solution that is, determining the overall appearance of the system. For example, a street guide for the blind could be a narrator or a tactile map; the invoicing system of a corporation will be either a simple application that manages income and expenditure or a strategic system that will consider multiple participants and logistic and financial operations. Having defined the overall appearance of the system, it will then be divided into subsystems, and the development alternatives (purchase, contract out, develop, etc.) for each subsystem will be evaluated. The best approach (OO, SA, RT, etc.) for implementing any subsystems that are to be developed will have to be determined. A series of metrics are being studied as an aid for making this decision. Depending on the characteristics of the need represented in the PMFS, these metrics determine the best approach for developing the subsystem concerned.
3.4. System Mapping The next design activity is what is called System Mapping. The tasks specified in the development approach selected in the Characterisation task will be applied to each subsystem during System Mapping. This activity involves the use of methods and techniques proper to each development approach and it outputs what have been called Prescriptive Software System Models (PSSM).
3.5. Other considerations Apart from the model hierarchy, figure 2 also shows the transition between the Characterisation and Mapping activities. For example, if it is discovered during Characterisation that the system can be implemented more easily by means of a module hierarchy, SA methods and techniques, like DFD and Constantine diagrams, will be used in the Mapping activity; on the other hand, if the subsystem can be better implemented as a set of classes, OO and its associated techniques, like use cases, object diagrams or interaction diagrams, will be used. The Characterisation activity is not exclusive, and each subsystem can be implemented according to a different development approach (OO, SA, RT, etc.) during Mapping. We plan to develop a set of rules to allow the information described in the PMFS to be transformed into the most commonly used PSSMs, particularly, OO, SA and RT systems, which will support the Mapping activity. Note that the proposed process is based on the DeMarco’s original ideas of studying the current and the future situations [20]. However, there is a fundamental difference. In this paper, we propose to use techniques that do not stipulate particular development approaches, whereas DeMarco proposes the use of DFD from the outset, thereby committing software engineers to structured development of the future system.
4. Final Summary The proposed model is divided into four activities, not including validation and management issues, as only the constructive points of software development have been considered. These activities are: Environment Analysis, Customer Problem Analysis, Software Solution Conception and System Mapping. In each of these activities, a series of specific techniques are used that are oriented to the problem in the early development stages and gradually move closer to the machine as development progresses. The goal of this process is to provide greater visibility in the RE phase and lays the foundations for
providing software engineers with proper support for addressing the RE phase.
5. References [1] J. Siddiqi, “Challenging Universal Truths of Requirements Engineering”, IEEE Software, vol. 11, no. 2, 1994. [2] W.W. Royce, “Managing the Development of Large Software Systems”, 9th International Conference on Software Engineering, IEEE Computer Society, 1987. [3] R. Balzer, “Transformational Implementation: An Example”, IEEE Transactions on Software Engineering, vol. 7, no. 1, 1981. [4] B.W. Boehm, “An Spiral Model of Software Development and Enhancement”, ACM Software Engineering Notes, vol. 11, no. 4, 1986. [5] IEEE, IEEE Standard Software Life Cycle Processes, 1989. [6] A.M. Davis, Software Requirements: Objects, Functions and States, Prentice-Hall International, 1993. [7] P. Loucopoulos, V. Karakostas, System Requirements Engineering, McGraw-Hill, 1995. [8] R. Wieringa, Requirements Engineering: Frameworks for Understanding, John Wiley & Sons, 1995. [9] P. Jalote, An Integrated Approach to Software Engineering, New York. Springer-Verlag, 1997. [10] K. Pohl, “The Three Dimensions of Requirements Engineering”, 5th International Conference on Advanced Information Systems Engineering, Paris, France, June 1993. [11] SWEBOK. Guide to the Software Engineering Body of Knowledge. http://www.swebok.org. [12] A.G. Sutcliffe, N.A.M. Maiden, “Analysing the Novice Analyst: Cognitive Models in Software Engineering”, International Journal of Man-Machine Studies, vol. 36, no. 5, 1992. [13] G.M. Høydalsvik, G. Sindre, “On the Purpose of Object Oriented Analysis”, OOPSLA’93. [14] D. Beringer, “The Goals of the Analysis Model”, Technical Report 96/216, Swiss Fed. Inst. of Technology, 1996. [15] M. Jackson, “Defining a Discipline of Description”, IEEE Software, vol. 15, no. 5, 1998. [16] A. Borgida, S. Greenspan, J. Mylopoulos, “Knowledge Representation as the Basis for Requirements Specifications”, IEEE Computer, vol. 18, no. 4, 1985. [18] B.I. Blum, Beyond Programming. To a New Era of Design. New York. Oxford University Press, 1996. [19] B. Henderson-Sellers, J. Edwards, “The Object Oriented Systems Life Cycle”, Communications of the ACM, vol. 33, no. 9, 1990. [19] O. Dieste, M. López, A.M. Moreno, “On the Capability of Analysis Techniques in Requirements Engineering”, EMMSAD’99. [20] T. DeMarco, Structured Analysis and System Specification, New Jersey. Prentice-Hall, 1979.
