METHOD ENGINEERING
Master of Business Informatics
Utrecht University
A METHODOLODY FOR THE SELECTION OF
REQUIREMENTS ENGINEERING TECHNIQUES
Process-Deliverable Diagram
Fabio Kornek (3548872)
PROCESS DESCRIPTION
The in the next section presented Process-deliverable diagram (PDD) of the MRETS methodology is
constructed based on Method Engineering (ME) principles and notations (Brinkkemper, 1996; Weerd &
Brinkkemper, 2008).
Although ME can be used to design, construct and adapt methods for the development of information
systems to suit specific project conditions, the PDD below is a mere representation of the MRETS
methodology; a so-called meta-model. In this respect, ME meta-modeling can be used for describing the
procedural and representational characteristics of methods, techniques and tools (Brinkkemper, 1996).
Process View
The below illustrated PDD is divided in two integrated parts. The left-hand side of the diagram resembles
the process view. Based on UML activity diagrams (OMG, 2003) it consists of activities and transitions.
Activities can have sub-activities. In Figure 1 the activity Perform clustering analysis is decomposed into
the three sub-activities: Derive techniques, Select technique attributes and Perform clustering. For both,
activity and sub-activity a certain role (i.e. by whom the process is to be carried out) can be defined. This
information is written in the lower right corner. The activity Perform clustering analysis for example has to
carried out by requirements engineers because their expert knowledge is required. The activity Analyse
project on the other hand does not need to be carried explicitly by requirements engineers, although this is
not prohibited.
The activities Refine technique selection and Select prospective techniques can be performed in parallel.
These concurrent activities are marked with a synchronization bar.
Another element that can be seen in the diagram is the conditional statement after the last sub-activity of
Determine final recommendation. After review the FINAL RECOMMENDATION can be approved (in
which the end-state is reached) or rejected (which means the sub-activity Select technique combination has
to be performed again).
Detailed explanations on each activity can be found in Table 3.
Deliverable View
On the right-hand side of the diagram the deliverables for the corresponding activities are depicted. This
side is based on UML class diagrams (OMG, 2003) and consists of concepts. Although this is not
compulsory, every activity in Figure 1 results in a deliverable (connected by the striped lines). To some
concepts properties have been added to better illustrate the nature of the concept.
The concepts are connected by associations which show a structural relationship between connected
concepts. Names for associations are provided to give meaning to them. Furthermore, multiplicities state
how many objects of a certain concept can be connected across the instance of an association. The following
multiplicities are shown in the diagram: 1 for exactly one, 0..1 for one or zero, 0..* for zero or more, 1..* for
one or more.
A detailed description on the concepts and how they were derived from literature can be found in Table 4.
PROCESS-DELIVERABLE DIAGRAM
Figure 1 Process-deliverable diagram
ACTIVITY AND CONCEPT TABLES
Activity
Subactivity
Score Project
Attributes
Perform Clustering
Analysis
Construct
Recommendation
Space
Determine final
recommendation
Description
For the TECHNIQUE INITALLY RECOMMENDED and the derivation of
TECHNIQUE ATTRIBUTES the major characteristics of the project need
to be established. As input serve 21 software project attributes that have
been identified and defined in details in previous research of Jiang et. al
(2007). The resulting PROJECT DEFINITION contains the serves as the
foundation for all subsequent activities.
Derive
techniques
By using case-based reasoning mechanism, the initial TECHNIQUE
INITALLY RECOMMENDED is derived based on the scored attributes of
the current project. Another input are the so-called recommendation rules
which are part of the RE process knowledge base (REPKB). The REPKB is
created as a preparatory activity (not shown in the diagram) It contains
detailed guidelines for each step, a collection of RE techniques gleaned
from previous research including knowledge about RE techniques and their
usage to provide support for technique selection. The REPKB is used as a
support and reference tool whenever needed. (Jiang et al., 2007).
Select techniques
attributes
Selection of a suitable sub-set of TECHNIQUE ATTRIBUTES for the
given project. The sub-set is selected from 31 RE technique attributes which
are a result of previous research (Jiang, 2005). The subsequent clustering
will be only based only those identified attributes.
Perform clustering
Analysis of the RE techniques in the REPKB is performed by using the
Fuzzy set clustering algorithm. The clustering is based on the important
TECHNIQUE ATTRIBUTES selected in the previous step, not on the
whole collection of 31 RE technique attributes.
Refine technique
selection
To ensure compatibility with the project the initial TECHNIQUE
INITALLY RECOMMENDED is reviewed by requirements engineers.
Incompatible techniques are removed and new ones might be added if
pertinent. As well, certain techniques can be compared by requirements
engineers based on certain attributes in this step.
Select prospective
techniques
Based on requirements engineers’ expertise a set of prospective techniques
may be selected. PROSPECTIVE TECHNIQUE LIST can as well be an
empty set if the requirements engineers are content with the existing
selection.
Identify comparable
& complementary
techniques
This sub-activity involves the identification of all functionally comparable
or complementary techniques. The resulting ALTERNATIVE
TECHNIQUE LIST is derived based on the results of TECHNIQUE
CLUSTER. This step supports the process of finding more suitable
technique for the specific project.
Combine techniques
Combination of the techniques identified in TECHNIQUE INITALLY
RECOMMENDED, ALTERNATIVE TECHNIQUE LIST and possibly
PROSPECTIVE TECHNIQUE LIST to form the RECOMMENDATION
SPACE.
Apply objective
function
Based on the objective function, various combinations of RE techniques
from RECOMMENDATION SPACE are scored on their overall ability and
cost to provide a means for evaluation.
Select technique
combination
Based on the scores calculated during the previous step requirements
engineers select the most promising techniques combination (those with the
highest score). This results in the FINAL RECOMMENDATION.
Review
recommendation
The FINAL RECOMMENDATION is once more reviewed by
requirements engineers. Based on their expertise and experience the FINAL
RECOMMENDATION is rejected or approved. In case of rejection the step
select technique combination is performed again to find a more suitable
selection.
Table 3 Activity table
Concept
Description
PROJECT DEFINITION
A PROJECT DEFINITION contains a short description of the project and the most relevant
attributes for RE technique selection (Jiang & Eberlein, 2007).
TECHNIQUE
INITALLY
RECOMMENDED
TECHNIQUE INITALLY RECOMMENDED is the initially recommended combination RE
techniques. This selection is based on requirements engineers experience from previous projects
(Jiang et al., 2007). TECHNIQUE SET can be in status initial or refined.
TECHNIQUE
ATTRITBUTE
A TECHNIQUE ATTRIBUTE provides a means to measure different aspect of a RE technique
(Jiang, 2005). Jiang separates attributes in two categories: Attributes that describe the ability of
a technique and attributes that describe economic factors. The selection of suitable sub-set of
technique attributes should be geared to the particular project characteristics and attributes
(Jiang et al., 2007). Weights are assigned to each attribute based on PROJECT DEFINITION.
TECHNIQUE CLUSTER
A TECHNIQUE CLUSTER is a grouping of RE techniques according to their characteristics
allowing for the analysis of the similarity of various techniques (Jiang et al., 2007). The
clustering itself is based defined technique attributes.
PROSPECTIVE
TECHNIQUE LIST
A PROSPECTIVE TECHNIQUE LIST is a set of techniques recommended by requirements
engineers which is included in the RECOMMENDATION SPACE. The purpose is to give
requirements engineers the opportunity to bring in their expertise in the selection process
(Jiang, 2005).
ALTERNATIVE
TECHNIQUE LIST
A ALTERNATIVE TECHNIQUE LIST contains all techniques that are functionally
comparable and functionally complementary to each technique of the derived TECHNIQUE
INITALLY RECOMMENDED. This is done by using the results of TECHNIQUE CLUSTER
(Jiang et al., 2007).
RECOMMENDATION
SPACE
A RECOMMENDATION SPACE is defined as a set of techniques from which the FINAL
RECOMMENDATION of techniques can be derived. The RECOMMENDATION SPACE is
an aggregation of the initial TECHNIQUE INITALLY RECOMMENDED, ALTERNATIVE
TECHNIQUE LIST and (if defined) PROSPECTIVE TECHNIQUE LIST. Various technique
combinations within RECOMMENDATION SPACE are rated on their ability by using the
objective function algorithm (Jiang et. al, 2007).
FINAL
RECOMMENDATION
A FINAL RECOMMENDATION resembles the final technique selection from
RECOMMENDATION SPACE based on overall ability scores calculated in the previous step.
FINAL RECOMMENDATION can have the status accepted (stop state) or rejected. In case of
rejection after the final review the activity select technique combination has to be performed
again (Jiang et. al, 2007).
Table 4 Concept table
REFERENCES
Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and
tools. Information and Software Technology, 38(4), 275-280. doi: 10.1016/0950-5849(95)01059-9
Weerd, I. v. d, and Brinkkemper, S. (2008). Meta modeling for Situational Analysis and Design Methods, p.
38–58. Hersey: Idea Group Publishing.
Object Management Group. (2004). UML 2.0 superstructure specification (Technical Report ptc/04-10-02)
Jiang, L. (2005) A framework for requirements engineering process development, PhD thesis, University of
Calgary
Jiang, L., Eberlein, A., Far, B. H., & Mousavi, M. (2007). A methodology for the selection of requirements
engineering techniques. In Software & Systems Modeling, 7(3), 303-328. doi: 10.1007/s10270-0070055-y
Jiang, L., & Eberlein, A. (2007). Selecting Requirements Engineering Techniques Based on Project Attributes A Case Study. In 14th Annual IEEE International Conference and Workshops on the Engineering of
Computer-Based Systems (ECBS'07) (269-278). Tucson, AZ, USA. doi: 10.1109/ECBS.2007.65