Performance measurement of different requirements engineering

International Journal of Computer and Technology (IJCET), ISSN 0976 – 6367(Print),
International Journal of Computer Engineering Engineering
ISSN 0976 – 6375(Online) Volume 1, Number 2, Sep - Oct (2010), © IAEME
and Technology (IJCET), ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online) Volume 1 IJCET
Number 2, Sep - Oct (2010), pp. 01-15 ©IAEME
© IAEME, http://www.iaeme.com/ijcet.html

PERFORMANCE MEASUREMENT OF DIFFERENT
REQUIREMENTS ENGINEERING PROCESS MODELS: A
CASE STUDY
Dhirendra Pandey
Department of Information Technology
Babasaheb Bhimrao Ambedkar University
Lucknow (U.P.) - 226025
E-Mail: prof.dhiren@gmail.com

U. Suman, A. K. Ramani
School for Computer Science & IT
Devi AhilyaVishwavidyalaya, indore (M.P)

ABSTRACT:
Numerous requirement engineering models have been proposed to find out the
good requirements for development of quality software product. In this paper we use
different requirements engineering process model which are linear to iterative in
structure. In this paper, we also examine the performance of our requirements
engineering processes model as well as existing model at two Indian companies.
Structured interviews were conducted with the aid of a qualitative questionnaire. The
results from the interviews are discussed, with particular focus on requirements
engineering activities and the high-level descriptive process models of the requirements
engineering processes that were constructed from the data. These models are then
compared with the performance of our RE process model.
Keywords: Requirements engineering process models, Indian companies,
requirements elicitation, project management.
1. INTRODUCTION
The objectives of RE is to extract the quality requirements from the stakeholders
for engineering principles and the development of information systems analysis and

1

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),

designing of system [1, 2]. Requirement engineering is one of the most important tools
for gathering requirements, which is concerned with analyzing and documenting the
requirements [3, 8]. Furthermore, the cost of repairing requirements-related problems
dramatically increases as the software development process progresses [4]. It is therefore
evident that the RE process has important results for the overall success of the project. In
order to improve RE processes, the current practices need to be examined. Understanding
and modelling current RE processes is an important step towards improving RE practice
and therefore increasing the success of software projects [5]. Studies of current RE
practices and the areas for improvement have concluded that the issues were
organisational and non-technical in nature, for example, document management and
managing uncertainty [6].
Some of the existing software process definition studies have focused on
constructing prescriptive models, rather than first examining the descriptive models in
current practice [5]. This paper examines the performance of our model with existing
model and model this RE process models in actual RE practice. Before modelling current
RE practices, a review of existing descriptive RE process models in literature provides an
indication of common RE activities and their sequence. However, these models are
different and sometimes conflicting in their nature, ranging from linear and incremental
to cyclical and iterative in structure. Results from previous studies of RE practice have
indicated that the RE process models in practice differ from commonly accepted RE
process models in literature [7, 8]. Further complication arises with the idea that RE
process models are situation dependent, affected by the customer-developers relationship
[9, 10], the product, technical maturity, disciplinary involvement and culture of the
organisation [11]. This paper also provide insight into the gap between descriptive RE
process models in literature and practice by constructing high-level data analysis of the
RE processes at two Indian companies and comparing these to the performance of our RE
process models. The models represent the activities in the RE process and not additional
factors, such as the three dimensions of RE identified by one of the researcher [12, 13].
Requirement engineering is a very important activity, which can affect the entire
activity of software development project [15]. In this paper we present literature review
in Section 2. The research methodology of this research paper is presented in section 3.

2


Section 4 describes finding of our research presented in this paper. In continuation,
section 5 present our research boundary and future work and finally section 6 presents the
concluding remarks.
2. LITERATURE REVIEW ON RE PROCESS MODELS
Quality of requirement engineering process model plays a key role in
development of software products. In this paper we use some existing RE process models
for the comparisons with our RE process model. These three models were selected for
their different structures: linear, linear with iterations between some activities, and linear
with iterative. Within these models, common RE activities, such as elicitation and
analysis, are combined under different headings, but still follow a similar linear
transition. Two such linear models were selected for use in this research. Two of the
researchers have suggested a conceptual linear RE process model, which indicates
iterations between some activities. They state that the activities in the model overlap and
are often performed iteratively [11]. One of the researchers provides a purely linear RE
process model. It does not indicate the overlapping or iterations of activities [9]. The RE
activities are categorised under different headings, however the linear progression
resulting in documentation is common to both models. One of the researchers
acknowledges that the RE process is situation dependent and discusses different
customer-developer relationships and their corresponding RE processes [9]. While
literature tends to portray the RE processes as linear, non-linear/iterative models have
also been suggested [12].
The third model selected for use in this research is our RE process model, which
depicts the RE process as iterative and cyclical in nature [15]. Existing model
demonstrates the interactions between elicitation, specification, validation, the user and
the problem domain [9, 11]. While similar activities to the two models already discussed
appear in our model, the order in which they occur is non-linear and suggests a cause and
effect relationship between them. Our RE model provides a purely iterative RE process
model which is shown in figure 1. It does not indicate the overlapping or iterations of
activities, suggested by the existing RE model [11]. It consists of mainly four phases,

3


namely; requirement elicitation and development, documentation of requirements,
validation and verification of requirements, and requirement management and planning.
Requirement elicitation and development phase includes requirement analysis and
allocation and flow down of requirements. Documentation of requirements includes
identification of requirements and software and system requirement specification.
Validation and verification of requirements phase is concerned with conforming the
documented requirements. The requirement management and planning phase controls the
continuously changing requirements. Each of these activities is further detailed in the
following sub sections. The proposed process describes requirements engineering for
software development systems in which requirement engineering must be a part of the
software development process [15].

Customer
Business requirement Information
requirements
Requirements
Security requirements
User requirements

Constraints Standards

Requirement Elicitation Documentation Validation and
of Verification of
and development Requirements Requirements
Requirement analysis
Requirement

Identification
Validation
Allocation and flow down
Software
Requirement
Software requirements Specification
Verification
System
Requirement
Hardware requirements specification

Modified
Requirement Management & Software development
Planning phases

Figure 1 Requirement Engineering Process Model [15].
Existing studies of RE processes in practice have indicated that the systematic and
incremental RE models presented in literature do not reflect the RE processes in current
practice. For example, some researcher found that the RE process in their case study did
not occur in a systematic, smooth and incremental way, but was opportunistic, with
irregular simplification and restructuring of the requirements model when it reached
points of high complexity [7]. Furthermore, some of the researchers performed a case
study in the field but could not produce a massive RE process model of RE activities, as

4


they were too heavily intertwined and not seen as separate tasks by the participants of the
study [8]. RE field studies have also gathered conflicting results as to the status of RE
process standards in organisations. Two of the researcher examined the 15 RE processes
in industry and found that most participants saw RE as an ad hoc process, with only some
using an explicitly defined RE process or customising a company standard RE process
[16]. Furthermore, studies of web development projects have also shown that RE is
occurring an adhoc manner [17, 18]. In contrast to these findings, concluded that
organisations tend to use standard RE processes, as they are thought of as best practices
[5].
2.1 RE PRACTICES
The following seven common activities that occur during the RE process are
referred to in this research paper. These RE activities were used in the questionnaire to
allow separate tasks to be identified, hence preventing the issue of merged activities [8].
Project Creation: Project creation is the activity of setting up a project to develop a
new product or to modify and existing product.
Elicitation: Elicitation refers to gathering the requirements of the system from different
stakeholders. Boundaries, identification of stakeholders, goals and tasks performed are
discovered in this phase [21].
Interpretation and Structuring: Following the elicitation of the requirements, they
are interpreted, structured and analysed. The requirements are then documented. This
phase is discussed separately; however it is often interleaved with requirements
elicitation, as some analysis invariable takes place in the elicitation process [11].
Negotiation: The negotiation phase consists of the requirements engineers negotiating
with the stakeholders to agree about the requirements definitions in the requirements
documentation [11].
Verification and Validation: Verification and validation of requirements aims to
check that the requirements accurately represent the needs of the system and that they are
complete, correct and consistent [3]. The technical experts or quality assurers also review
the requirements.

5


Change Management: Change management makes certain that similar information is
gathered for each change and that the overall costs and benefits of proposed changes are
reviewed [11]. Therefore, change management involves evaluation of risks and impacts
[21].
Requirements Tracing: Requirements tracing is used to track the origins of each
requirement, so that if a change has to be made to a design component, the original
requirement can be located [22].
3 METHODOLOGIES
3.1 RESEARCH METHOD
The basic goal of this paper is to discover and understand RE models in practice
and compare performance measurement between existing models and our proposed
models. For this, a questionnaire instrument was selected in order to collect the large
amount of data required to gain a comprehensive understanding of the RE process [19,
20].
The questionnaire consists of (1) background details of the participant, company
and project, (2) the RE process, and (3) RE techniques used. Many closed-ended
questions were used to minimise the length of the questionnaire. Open-ended questions
were used where it was important for participants to answer in their own words. The
questionnaire was administered to each participant in an interview session, with the
researcher and one participant present. The participant was asked to complete the written
questionnaire and add any additional verbal information. The use of interview sessions
allowed for participants to clarify meanings of the terms and questions used, ensuring that
they had a clear understanding of what was being examined.
The duration of the interviews was between 60 and 90 minutes, with the
differences in time resulting from the amount of additional information added verbally by
the participant and the use of contingency questions in the questionnaire. The interviews
took place at prearranged times in private meeting rooms at the companies’ premises to
maintain a quiet, undisrupted environment, which was consistent for every interview. A
total of six interviews have been conducted at two companies, operating in the
manufacturing and financial industries. Three interviews were conducted respectively.

6


The participants were primarily in a project management or business analyst role, with
responsibility for RE activities on the relevant project.
3.2 CASE STUDY
Company A is a large company in the manufacturing industry. Less than 1% of
staff works in the information technology (IT) department. Three projects conducted by
the IT department were examined. The objective of project α1, a large project, was to
implement an enterprise resource planning (ERP) system. Project α2, a medium project,
had the aim of upgrading all systems, particularly the ERP system, for the introduction of
the Goods and Services Tax (GST). Project α3, a small project, had the purpose of
implementing enhancements to an existing sales promotions management system. All
three projects produced a customer-specific business system for an internal customer and
had direct contact with the customer throughout the project. The customer-developer
relationship for these projects is considered to be similar to the scenario, ‘responding to a
business centre within the same organisation’, suggested by some researchers, however
there is no specific RE process model identified for this scenario.
Our study summarises the project characteristics which shows the project α1 is
large project having near about 75 project members in which 60% of members are
technical and this project is easily accessible by the user. The project α1 having medium
non-RE tool support. In this way project α2 is medium project and it has 25 project
members in which there are 16 members having technical skills. Project α2 is easily
accessible to the user and it has low non- RE tool support. In project α3, that is small
project. It has 10 project members in which 8 persons are technical hand. It is easily
accessible and this project having low non- RE tool support (Table-1).

7


Table 1. Characteristics of Projects at Company A and Company B
Project Size Project Effort Technical Special Customer Non-RE
Members per background quality Access tool
Month of Project requirements support
Members
α1 Large 30-115 621 60% High Easy Medium
Performance
α2 Medium 15-29 28 35% Legal Easy Low
Compliance
α3 Small 5-15 5 78% High Easy Low
Performance
β1 Medium 10-15 114 95% System Easy Medium
Availability
β2 Small 5-15 12 65% High Normal Low
Performance
β3 Medium 10-15 26 95% System Easy Medium
Availability

Company B is a large company in the finance industry. Approximately 20% of
staff works in the IT division. Time was a priority for all three projects. For projects β2
and β3 this is attributable to the recent move towards iterative, shorter development
cycles with fixed deadlines. Project β1 had the aim of developing a customised website
for institutional clients and asset consultants, with content such as interactive
performance data. The objective of project β2 was to replace an existing customer
relationship management (CRM) system with a new version from the same vendor. The
existing system was so customised that it was more cost-effective to start again, than to
upgrade the existing system. Project β3 implemented a new equities trading system
vendor solution. As for Company A, the customer-developers relationship for these
projects is considered to be alike the scenario, ‘responding to a business centre within the
same organisation’, suggested by some of the researchers.
Our analysis summarises the project characteristics which shows the project β1 is
medium project having near about 12 project members in which 95% of members are
technical and this project is easily accessible by the user. The project β1 having medium
non-RE tool support. In this way project β2, a small project has 10 project members in
which there are 65% of members having technical skills. Project β2 is normal accessible
to the user and it has low non- RE tool support. In project β3, that is medium project and

8


in which all of the members are technical hand. It is easily accessible and this project
having medium non- RE tool support.
4 PRELIMINARY FINDINGS
The results from the questionnaire were used to describe the state of the art of RE
practices at the companies. Brief discussions of the findings are as follows: company A
had no standard RE process documentation, therefore the RE practices differed between
each process. There was a medium level of RE process awareness in the larger projects,
α1 and α2, with many RE activities performed explicitly or implicitly. The RE process
awareness in the small project, α3, was low, with only some of the RE activities
explicitly or implicitly performed. The processes in the large and medium projects, α1
and α2, were structured, as several RE phases occurred with allocated documentation. It
was evident that the RE process in the smallest project, α3, was ad hoc, with a low level
of RE process awareness and no dedicated role for RE. The results indicated that this role
was influenced by the size of the project, since the larger project allowed for greater
separation of tasks between the roles of business analyst and project manager. Projects
and α2 both had a medium level of tool support, as no specific requirements management
or modelling tools were available at Company A. Project α3 had a low level of tool
support, which is consistent with the unstructured, ad hoc nature of the RE process.
Projects α1 and α2 had a high level of documentation awareness, as all the suggested RE
documentation was produced where relevant. Project α3 was classified as having a
medium level of documentation awareness, as only three of the suggested RE documents
were produced.
General project methodology did exist at Company B. There was a company
standard methodology; however, there had been a move towards the Microsoft Solutions
Framework (MSF) methodology. There was an inconsistent response to whether
company standard documentation existed for the RE process, with two respondents
indicating that no such standard existed and two indicating that standards did exist,
however the size of these documents differed dramatically. Therefore, even if a company
standard exists, it is not widely used. The RE process awareness for projects β1 and β2
were medium, with many RE activities performed explicitly and implicitly. Project β3

9


had a high level of RE process awareness with most RE activities performed explicitly
and the others implicitly.
The RE process for all three projects was structured, with several RE phases
occurring with allocated documentation. All three projects had the role of business
analyst defined for RE. In project β2 the business analyst was also performing the project
management role. This is similar to project α2, in which the project manager was also
performing the RE activities. In both instances, having a smaller project team resulted in
the merging of roles, that may have been separated in a larger team. All three projects had
a medium level of tool support for the RE activities. No project used specific
requirements management or modelling tools. Participant β1 commented that they had
used a requirements tracing tool at their former company. The documentation awareness
level was generally high, with projects β2 and β3 having a high level and β1 at a medium
level. One of the participants commented on the lack of time available to maintain the
documentation, due to the move towards three-month cycles.
4.1 REQUIREMENTS ENGINEERING ACTIVITIES
Participants were asked whether each of the seven RE activities were performed
explicitly (required and definite), implicitly (performed but indefinite) or not at all in
their projects. The variance between the ways RE activities are performed is consistent
with the lack of RE process standards in Company A and B. There were clear differences
between the projects at Company A. Elicitation was the only activity performed explicitly
in every project. Negotiation was performed implicitly in every project. Interpreting &
Structuring was performed in all projects, but differed between implicit and explicit.
Project Creation, Verification & Validation, and Tracing ranged from being performed
explicitly, implicitly to not at all. Company B revealed a more consistent performance of
RE activities, but differences still occurred between projects.
Elicitation and Negotiation were performed explicitly in approximately in all
projects. Change management was performed implicitly in all projects. Project Creation
and Interpreting & Structuring were performed in all projects, but changed between
explicit and implicit. Verification & Validation was either explicitly or not performed.
Tracing varied between explicitly, implicitly and not performed. Of the seven suggested

10


activities, Elicitation was the only RE activity performed explicitly in every project.
Interpreting & Structuring, and negotiation were also performed in every project, but
varied between implicitly and explicitly performed. It was established that there was
some doubt whether project creation was seen part of the RE process.
4.2 PERFORMANCE MEASUREMENT
The RE process models for each project were compared to the three models
selected from this paper. As detailed in section 2, one of the RE model depicts the RE
process as linear, but with iterations occurring between individual activities [11]. Second
RE model presents the RE process as linear, with no iterations occurring [9]. Our RE
model represents the RE process as a completely iterative and linear process, with
activities depicted with cause and effect relationships, as opposed in a sequence [15].
In our study we found that, project α1 is iterative in nature and company has
decided to use continuous RE process to complete the project. The company A used the
RE model that is linear but iterative between some activity [11]. The project α1 give
average performance. In Project α2, RE process is just start in project lifecycle. RE model
is used is linear in structure, project α2 is also give average performance. Project α3
provide good performance to the company because in this project company used RE
model that is linear than iterative. Project β1 has produced same result. In project β2,
linear RE model is used which gave average performance. Lastly β3 project uses
continuous RE process in throughout project life cycle, and company B used RE model
that is linear then iterative. This project is also give good performance same as project α3
and β1 (Table-2).
Table 2. Requirements Engineering Activities Performed at Company A and B
Project Project Elicitation Interpreting& Negotiation Verification Change Tracing
Creation Structuring & Management
Validating
α1 No Explicit Explicit Implicit Explicit Explicit Implicit
α2 Explicit Explicit Implicit Implicit Implicit Implicit Implicit
α3 Implicit Explicit Explicit Implicit No No No
β1 Implicit Explicit Explicit Explicit No Implicit No
β2 Explicit Explicit Explicit Explicit Explicit Implicit Implicit
β3 Implicit Explicit Explicit Explicit Explicit Implicit Explicit

11


4.3 DISCUSSION AND FUTURE WORK
One of the RE model was a good representation of generally linear RE process
models that had some iteration of activities [11]. The purely linear nature RE process
model did not indicate any iteration of activities [9]. Projects that made use of
prototyping required a more iterative depiction of that part of the process. Most of these
projects followed a generally linear process until the prototyping phase, which then
resulted in an iterative process. Our model was a good representation of a linear process
and the iterative nature of prototyping [15] . By analysis of above study it is clearly stated
that the project using iterative as well as linear approach was successful in business
context (Table-3).

Table 3 Performance Measurement of Requirements Engineering Processes in different
projects.

Project RE in Project Model Structure RE Model Performance
Lifecycle used
α1 Continuous Iterative (K) Average
performance
α2 Start Linear (M) Average
performance
α3 Continuous Iterative (P) good performance
β1 Continuous Linear then iterative (K), (P) good performance
prototype
β2 Start of each Linear (K), (M) Average
iteration performance
β3 Continuous Linear then iterative (K), (P) good performance
prototype
This research is essentially an exploratory study, so there are many opportunities
for further research in this area. This study could be expanded to include a wider
spectrum of industry and projects of different customer-developer relationships. Results
could be gathered from other roles within the project team, such as the developers, to
identify whether the process is perceived differently from other perspectives. Participants
could also be involved in the process of comparing the company’s RE process models to
those from literature. Future studies could attempt to correlate the use of different RE
process models with project success. Additionally, the relationships between explicit and
implicit activities and project success could also be studied to identify if there is a link

12


between the nature of activities and the success of the RE process. This research could
also lead into the area of RE process improvement, by identifying areas of strength and
weakness in current RE processes.
6. CONCLUSIONS
The two existing RE process models are compare with our RE process models
and also they compared to the RE process in each project. It was determined that none of
these models were a good representation of every RE process but one of the RE process
model represented some RE processes better than others [15]. While it is has been
established that one model cannot represent all processes, a purely linear model was not
as successful as one that showed iterations of activities. Conversely, a purely iterative
model neglected to represent a progression of RE activities. Therefore, an RE process
model would benefit from a combination of linear and iterative structures which is shown
in our RE model [15]. This outcome is based on the result which is found when we get
the project result. In that result it is clearly seemed that the project α3, β1, β3 is
successful because in that project our RE model is used for requirement engineering.
REFERENCES
1. Berry, D. M. and Lawrence, B. (1998), Requirements Engineering, IEEE
Software, Vol. 15, No. 2, pp.26-29.
2. Leite, J. C. (1987), A Survey on Requirements Analysis, Advanced Software
Engineering Project Technical Report RTP-071, University of California at
Irvine, Department of Information and Computer Science.
3. D. Pandey, U. Suman, A. K. Ramani,(2008), “Impact of Requirement Engineering
Practices in Software Development Processes for Designing Quality Software
Products”, National Conference on NCAFIS, DAVV, Indore.
4. Boehm, B. W and Papaccio, P. N. (1988), Understanding and Controlling
Software Costs, IEEE Transactions on Software Engineering, Vol. 14, No. 10, pp.
1462-1477.
5. Madhavji N. H., Holtje D., Hong W. and Bruckhaus T. (1994), Elicit: A Method
for Eliciting Process Models, Proceedings of the 1994 CAS Conference, Toronto,
Canada, 31 October – 3 November.

13


6. Lubars, M., Potts, C. and Richter, C. (1993), A Review of the State of the Practice
in Requirements Modeling, Proceedings of the IEEE International Symposium on
Requirements Engineering, San Diego, USA, pp. 2-14, IEEE Computer Society.
7. Nguyen, L. and Swatmann, P. A. (2000), Managing the Requirements
Engineering Process, School of Management Information Systems, Deakin
University, Geelong, Australia.
8. Houdek, F. and Pohl, K. (2000), Analyzing requirements engineering processes: a
case study Proceedings of the 11th International Workshop on Database and
Expert Systems Applications, Greenwich, UK, 6-8 September, pp.983-987.
9. Macaulay, L. A. (1996), Requirements Engineering, Springer-Verlag.
10. D. Pandey, U. Suman, A. K. Ramani. (2010) “Social-Organizational Participation
Difficulties in Requirement Engineering Process- A Study”, Software
Engineering Journal, Bioinfo Publication, Navi Mumbai.
11. Kotonya, G. and Sommerville, I. (1998), Requirements Engineering – Processes
and Techniques, John Wiley & Sons, UK.
12. Pohl, K. (1994), The Three Dimensions of Requirements Engineering: A
Framework and its Applications, Information Systems, Vol. 19, No. 3, pp. 243-
258.
13. Martin, S. R. (2002), Requirements Engineering Processes in Australian Practice,
Unpublished Thesis, School of Information Systems, Management and
Technology, University of New South Wales.
14. Loucopoulos, P., and Karakostas, V. (1995), System Requirements Engineering,
McGraw- Hill Book Company Europe.
15. Pandey, D., Suman, U.,Ramani,A. K.(2010), An Effective Requirement
Engineering Process for Software Development, Internation Conference on
ARTCom, ACEEE, Kerla.
16. Hofmann, H. F. and Lehner, F. (2001), Requirements Engineering as a Success
Factor in Software Projects, IEEE Software, Vol. 18, No. 4, pp.58-66.
17. Lowe, D. and Eklund, J. (2001), Development Issues in Specification of Web
Systems, 6th Australian Workshop on Requirements Engineering, 22-23
November, University of New South Wales, Sydney, Australia.

14


18. Dang, T. K. (2000), Understanding the Requirements Engineering Process for
Hypermedia Systems, School of Information Systems, Technology and
Management, University of New South Wales, Australia.
19. Blaikie, N. (2000), Designing Social Research, Polity Press.
20. Galal, G. H. and McDonnell, J. T. (1998), A Qualitative View of Requirements
Engineering, Proceedings of the 3rd Australian Conference on Requirements
Engineering, October, Deakin University, Geelong, Australia.
21. Nuseibeh, B. and Easterbrook, S., (2000), Requirements Engineering: A
Roadmap, The Future of Software Engineering, Anthony Finkelstein (Ed.), ACM
Press.
22. Davis, A. M. (1993), Software Requirements: Objects, Functions, and States,
Prentice Hall. El Emam, K. and Madhavji, N. H. (1995): A Field Study of
Requirements Engineering Practices in Information Systems Development,
Second International Symposium on Requirements Engineering, York, England,
IEEE CS Press, pp.68-80.

15

Performance measurement of different requirements engineering

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (9)

Similar a Performance measurement of different requirements engineering

Similar a Performance measurement of different requirements engineering (20)

Más de iaemedu

Más de iaemedu (20)

Performance measurement of different requirements engineering