Requirements engineering literature presents different models of the requirements engineering process. The process models range from linear to iterative in structure. This paper reports on a study of the requirements engineering processes at two Australian 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 three descriptive requirements engineering process models from existing requirements engineering literature.
The RE phase of a software project is vital to its success. This was made evident when
most of the causes of project failure identified by a Standish Group study in 1995 were related
to the RE process (Pfleeger, 1998). Furthermore, the cost of repairing requirements-related
problems dramatically increases as the software development process progresses
Consequently, the ability to identify problems and suggestions for improvements in
the RE process opens up significant potential for increasing the success of software projects.
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
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
This research aims to provide insight into the gap between descriptive RE process
models in literature and practice by constructing high-level models of the RE processes at two
Australian companies and comparing these to the three RE process models selected from
literature for their different structures. The models represent the activities in the RE process
and not additional factors, such as the three dimensions of RE identified by Pohl (1994). This
paper presents the research method and an overview of the results of the research project
Three RE process models were selected for the comparisons made in this research. These three models were selected for their different structures: linear, linear with iterations between activities, and iterative.
The RE process is often depicted with a linear, incremental model. 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.
Requirements elicitation User needs domain information, existing system information, regulations, standards, etc.
Requirements analysis and negotiation
Concept Problem analysis Feasibility and choice of options
Analysis and
modelling
Requirements
documentation
While literature tends to portray the RE process as linear, non-linear models have also
been suggested. The third model selected for use in this research is the
Elicitation
Specification
Validation
User requirements
Knowledge Request more knowledge
Domain Knowledge
User
User Feedback Requirements specification
Models to be validated
by user Requirements
Models Validation
results Problem Domain
Domain Knowledge
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, Nguyen and Swatmann (2000) found that the RE process in their case
study did not occur in a systematic, smooth and incremental way, but was opportunistic, with
sporadic simplification and restructuring of the requirements model when it reached points of
high complexity. Furthermore,
RE field studies have also gathered conflicting results as to the status of RE process
standards in organisations.
The primary aim of this research is to discover and understand RE models in practice
and compare these to models from existing literature. A qualitative research method was
selected as it is concerned with understanding and exploring
A questionnaire instrument was selected in order to collect the large amount of data required to gain a comprehensive understanding of the RE process. Additionally, the questionnaire acted as a timesaving tool, since time restrictions apply to the study. The questionnaire was based on a questionnaire developed by the Requirements Engineering Special Interest Group of the German Association for Computer Science (Gesellschaft für Informatik) and customised for use in the Australian context. The questionnaire consists of three sections covering (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, however participants were offered an “Other-please specify” option to prevent forced answers from occurring. 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. These interview sessions were recorded on tape. 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 seven interviews have been conducted at two companies, operating in the manufacturing and financial industries. Three and four interviews were conducted respectively. The participants were primarily in a project management or business analyst role, with responsibility for RE activities on the relevant project.
The data contained in the questionnaire was entered into a spreadsheet containing the classifications for the data items for each project and company, for example, RE process awareness (Section 4.1). The data gathered on whether the activities were performed explicitly, implicitly or not at all was examined (Section 4.2). This was then mapped to the data on the phases of the RE process and the activities in each phase. This data was constructed into matrices for each project, which were used as the descriptive RE process models (Section 4.3). These models were compared with the three models selected from RE literature (Section 4.3). 3.2
Company A is a large company in the manufacturing industry. Less than 1% of staff
work in the information technology (IT) department. Three projects conducted by the IT
department were examined. The objective of project A1, a large project, was to implement an
enterprise resource planning (ERP) system. Project A2, 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 A3, 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-supplier relationship for these
projects is considered to be similar to the scenario, ‘responding to a business centre within the
same organisation’, suggested by
Company B is a large company in the finance industry. Approximately 20% of staff
work in the IT division. Time was a priority for all three projects. For projects B2 and B3 this
is attributable to the recent move towards iterative, shorter development cycles with fixed
deadlines. Project B1 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 B2 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 B3 implemented a
new equities trading system vendor solution. All three projects produced a customer-specific
business system for an internal customer and had direct contact with the customer throughout
the project, however the end users for project B1 were external to the company. As for
Company A, the customer-supplier relationship for these projects is considered to be alike the
scenario, ‘responding to a business centre within the same organisation’, suggested by
No.
High performance Legal compliance High performance System availability High performance High Performance, System availability Medium Low Low Time / Cost Time / Functionality Easy Easy Functionality Easy Time Easy Medium Time / Functionality Time Medium Low Easy Medium
A1 A2 A3 B1 B2 B3
Large
The following seven common activities tha t occur during the RE process are referred
to in this investigation. These RE activities were used in the questionnaire to allow separate
tasks to be identified, hence preventing the issue of merged activities, identified by
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
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
Verification and Validation: Verification and validation of requirements aims to check that
the requirements accurately represent the needs of the system
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
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
The results from the questionnaire were used to describe the state of the art of RE practices at the companies. A brief discussion of the findings 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, A1 and A2, with many RE activities performed explicitly or implicitly. The RE process awareness in the small project, A3, was low, with only some of the RE activities explicitly or implicitly performed. The processes in the large and medium projects, A1 and A2, were structured, as several RE phases occurred with allocated documentation. It was evident that the RE process in the smallest project, A3, was ad hoc, with a low level of RE process awareness and no dedicated role for RE. The role defined for RE changed on each project between business systems analyst, project manager or no defined role. 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 A1 and A2 both had a medium level of tool support, as no specific requirements management or modelling tools were available at Company A. Project A3 had a low level of tool support, which is consistent with the unstructured, ad hoc nature of the RE process. Projects A1 and A2 had a high level of documentation awareness, as all the suggested RE documentation was produced where relevant. Project A3 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 B1 and B2 was medium, with many RE activities performed explicitly and implicitly. Project B3 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 B2 the business analyst was also performing the project management role. This is similar to project A2, 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 B1 commented that they had used a requirements tracing tool at their former company. The documentation awareness level was generally high, with projects B2 and B3 having a high level and B1 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.
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 (Table 4.1).
A1 A2 A3 B1 B2 B3 - 1 B3 -2
No Explicit Implicit Implicit Explicit Explicit Implicit
Explicit Explicit Explicit Explicit Explicit Explicit Explicit
Explicit Implicit Explicit Explicit Implicit Explicit Explicit
Implicit Implicit Implicit Explicit Explicit Explicit Explicit
Explicit Implicit No No Explicit Explicit Explicit
Explicit Implicit No Implicit Implicit Implicit Implicit 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 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 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.
Implicit Implicit No No Implicit Implicit Explicit 4.3
Participants were asked to list the phases in the RE process and allocate the RE
activities performed each phase. This data was used to construct matrices to represent the RE
process for each project. The RE process models for each project were compared to the three
models selected from literature, summarised in Table 4.2. For more qualitative data and
detailed description of the RE process the reader is referred to
As detailed in section 2, the
A1 A2 A3 B1 B2 B3
Continuous Start Continuous Continuous Continuous Start of each iteration
Linear Iterative - RE activities across multiple phases (K) Linear - RE activities allocated to one phase Iterative – ad hoc process Linear then Iterative prototypes Linear then Iterative prototypes (M) (L) (K), (L) (K), (M) (K), (L) Company A
A lack of company standards resulted in the three projects at Company A following different RE processes according to their different contexts and priorities. In project A1 (Figure 4.1), most of the RE activities were performed in multiple phases. Therefore, it appeared that iterations of activities in the RE process were occurring. However, the RE process also progressed through a series of linear phases. The RE process model of project A1 is similar to the (K) model, as each phase appears to be an iteration of the (K) model. It is therefore similar to the spiral version of the model.
RE occurred at the start of project A2, with later changes handled through the change management process. The RE activities tended to occur in one phase, resulting in a generally linear RE process model (Figure 4.2). The RE process model of project A2 is most similar to the (M) model, as it is linear, however, the (M) model does not represent the continuous change management process.
In project A3, the RE process was ad hoc and iterative (Figure 4.3). After the initial needs analysis was performed, the final solution was identified through iterative prototypes until the users were satisfied. The (L) model is the best representation of project A3, as it indicates the constant interaction with the users and the iterations of elicitation. In this situation, the “specification” that lies at the centre of the (L) model (Figure 2.3) would be substituted with “prototype”, rather than a requirements specification. Company B
The RE processes at Company B also depended upon the different project contexts. The RE process model of project B1 had a generally linear structure but with some iteration of activities (Figure 4.4). It therefore appears to initially to follow the (K) model. The (L) model represents the iterative nature of the prototyping phase of this project. The (M) model is too strictly linear to successfully represent these models.
The linear RE process model of project B2 is most similar to the (K) and (M) models (Figure 4.5). The (L) model does represent the linear progression through the phases of B2.
Project B3 appears to initially follow the (K) model, with a generally linear structure for the first phases of the RE process (Figure 4.6, Figure 4.7). However, with the move to the prototyping stage, where iterations of prototypes were used, the model becomes iterative in nature. The (L) model represents the iterative nature of the prototyping phases of this project. The (M) model is too strictly linear to successfully represent this process. Discussion
Results indicate that projects with RE running as a continuous activity throughout the project (Projects A1, A3, B1 and B3) had RE activities performed multiple phases, resulting in an iterative process model. Furthermore, the projects that used multiple iterations of prototyping in the RE process (Projects A3, B3) resulted in the most iterative process models. The projects with RE performed at the start of the project or each increment (Projects A2 and B2) did not contain the iterations that occurred in the projects with continuous RE, and thus had a more linear process model.
None of the three models from literature suited to every project. On a case-by-case
basis, the different characteristics of the models made one appear the best representation of
the RE process in that particular context. The
The RE processes at two companies were reviewed and compared to existing RE process models in literature. Neither company had a standard RE process, causing the RE process vary between projects. Consequently, the RE processes were examined a project-byproject basis. While RE occurred in all projects, the general feeling from the interviews was that the RE process was seen as one aspect of the entire software process, rather than a process in its own right. The formal term “requirements engineering” was generally not well known, but the importance of gathering requirements was. Furthermore, specific requirements management and modelling tools were not used at either company.
The differences in size and priority appeared to affect the level of structure in the RE process and therefore the level of progression through a set of RE phases. Time was a prioritised factor projects A1, A2, B1, B2 and B3 and a more structured process was required in order to meet deadlines. In contrast, project, A3, had functionality as the priority of the project. This project had an ad hoc RE process consisting of iterative prototypes until the functionality was adequate.
RE activities tended to occur across multiple phases. Of the seven suggested activities, elicitation was the only RE activity performed explicitly in all projects. Interpreting & Structuring, and Negotiation were also performed in all projects, but varied between implicitly and explicitly performed.
When RE was seen as a continual task throughout the project, the RE process model was more iterative. The RE activities tended to occur across multiple phases, making the process models appear iterative. When RE occurred at the start of the project or each project increment the process was more linear. When multiple prototypes were used, the process was highly iterative. Therefore, the point at which the RE process occurs in the project appears to affect the nature of the RE process model. Additionally, the techniques used for RE appear to affect the RE process, such as prototyping.
The
It was determined that even within one company, it was not possible to construct a
single model representing every RE process for every project context. Therefore, the
implication by
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. For example, an RE process model could be generally linear in form until the prototyping phase, which would be depicted as an iterative process. 6
This study should be considered with reference to the contexts of the projects. Definitive generalisations about companies not included in the research cannot be made, due to its small sample size. Additionally, many industries have not been represented in this study. Argument may be raised that the participants of the research may not actually have done what they indicated was done. While honest answers were encouraged, it cannot be known whether this occurred and the answers were taken at face value. The process models were constructed from the data gathered in the questionnaire. The perceptions and interpretations of different people about the RE process may differ between people, as was discovered from the results of the two participants in project A3. It is also possible that the results may not have identified all instances of iterations of activities. Therefore, the process models must be considered as high-level representations of the RE process from one perspective.
As this research is essentially an exploratory study, 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-supplier 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 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. 7