Empirical Studies of Requirements Validation

Techniques

Uzair Akbar Raja

Blekinge Tekniska Hgskola, Ronneby, Sweden
uara06@student.bth.se

Abstract Requirements validation ensures that the 1998 which provides guidelines for documenting
software requirements specification contains complete and software requirements specification.
consistent set of requirements which are according to the
customer needs. This paper provides overview of The requirements for the system are subject to change
requirements validation techniques like requirements due to changing stakeholders needs, changes in
inspections, requirements prototyping, requirements testing environment, change in laws and business plan [1].
and viewpoint-oriented requirements validation. This paper Therefore requirements management facilitates to manage
highlights pros and cons of these requirements validation the changes to the system [1].
techniques. In requirements testing special attention is given
to TCD inspections.
The requirement validation process ensures that the
requirements in software requirements specification are
consistent and complete [1]. The requirements validation
1. INTRODUCTION process attempts to identify the errors in software
requirements specification (SRS) before it is used as a
basis for further system development [1].
According to Sommerville and Kotonya requirements
engineering covers all activities involved in discovering, The final phase of requirements engineering is
documenting and maintaining a set of requirements for requirements validation. Requirements validation
computer based systems [1]. Requirements engineering is identifies the ambiguous requirements and resolves
based on requirements engineering process. requirement conflicts.
Requirements engineering process is a structured set According to [3] 56 percent of all the bugs in software
of activities which are carried out to derive, validate and projects are due to the bugs inserted in the requirements
maintain requirements documents [1]. Requirements phase as shown in Figure 1. Half of these bugs are due to
engineering process is divided into five categories or the incomplete and ambiguous requirements and the other
process activities namely requirements elicitation, half are due to the requirements that are omitted. The cost
requirements analysis & negotiation, requirements of fixing a bug is less in requirements engineering phase
specification, requirements management and requirements because few deliverables have been delivered at this
validation. phase.
In the process of requirements elicitation requirements
engineers discover user requirements from domain
knowledge, system documents and market studies [1].
Requirements engineers usually conduct interviews with
stakeholders or customers to articulate their needs.
During this phase requirements are analyzed in detail
and stakeholders negotiate to decide set of agreed
requirements for the proposed system [1]. This process
helps to resolve conflicts among system stakeholders due
to incomplete information or requirements incompatibility
within the available budget [1].
The agreed requirements are documented in
requirements specification document. This document is
also known as software requirements specification (SRS).
IEEE has defined a standard known as IEEE Std 830- FIGURE 1. DISTRIBUTION OF BUGS [3]
 2. RESEARCH QUESTIONS
Following research questions will be answered during
this study on requirements validation.
What are the problems with requirements validation in
general?
What are various requirements validation techniques
proposed in literature?
What are the benefits and problems with requirements
validation techniques?
What is the importance in selection of a particular
requirements validation technique in software
development projects?
3. RESEARCH METHODOLOGY
Most studies in software engineering are exploratory.
Exploratory studies are based on analyzing a particular
problem or situation and these studies are useful for
determining the current research work or new insights in a
specific domain ( like requirements validation in our case)
[16]. Exploratory studies can be performed by literature
reviews, open questionnaires and interviews [16]. In this
research study authors objective is to compare and
analyze requirements validation techniques. Therefore
literature review is suitable methodology to fulfill this
purpose. During the study articles from IEEE, ACM and
Springer will be referenced.
4. PROBLEMS WITH REQUIREMENTS VALIDATION
One of the major problems with requirements
validation phase is the application of a strategy or
framework for requirements validation. Mostly companies
practice requirements validation on ad-hoc basis due to
lack of trained staff or lack of training or exposure to
requirements validation. More attention is given to
software testing phase which is usually carried out in the
end when all modules in software project are integrated.
5. REQUIREMENTS VALIDATION TECHNIQUES
Requirement validation techniques ensure the
completeness of the software requirements specification.
Some of the requirements validation techniques are
requirements reviews, prototyping, use case based
modeling and viewpoint-oriented requirements validation
[1].
The requirements validation techniques covered
during this study will be requirements inspections,
requirements prototyping, requirements testing and
viewpoint-oriented requirements validation.
6. REQUIREMENTS INSPECTIONS
Inspections were introduced by Fagan in 1976 and
they are considered to be the powerful technique to detect
errors [10]. Literature evidence indicates that 50-90 % of
defects can be caught using inspections [9]. CMMI and
ISO / IEC 15504 also recommend inspections as a part of
development process [11], [12].
In requirements inspection process we use inspections
to detect incomplete or ambiguous requirements in
software requirements specification (SRS).
a. Requirements inspection process
The inspection process comprises steps like planning,
overview, defect detection, defect collection, defect
correction and follow-up. These steps are explained in
detail as follow.
1) Planning: The primary objective of the planning phase
is to organize an inspection meeting when materials for
inspections are determined [4]. The materials for
inspections are normally selected when they pass entry
criteria for example when the software requirements
specification (SRS) is complete [4]. The key activities
during the planning phase are the selection of inspection
participants, assigning roles to them, scheduling
inspection meeting and distribution of inspection materials
[4].
2) Overview: In the overview phase the author or authors
of the software requirements specification (SRS) explains
it to the inspection team [4]. The objective behind
overview phase is to make the inspected software
requirements specification (SRS) easier to understand for
the inspection team. There are certain limitations
associated with overview phase [4]. Firstly these meetings
consume effort and time. Secondly this phase does not
ensure the independent assessment of inspected
requirements specification. For example, it may happen
that during the overview phase all inspectors focus their
attentions on a particular aspect of software requirements
specification (SRS) and this conflict may consume more
time before arriving at a conclusion.
Researchers like Fagan, Glib and Graham name this
phase as Kickoff Meeting and categorize this phase as
optional phase [4]. On the other hand there are three
conditions which support this phase [4].
When the artefact to be inspected is complex and
difficult to understand then this phase is justified.
When the artefact to inspected belongs to a large
software system. In this case overview phase
 helps the inspectors to understand the
relationship of that artefact to other components
of the system.
This phase facilitates the training process. For
instance the new team members participate in
these meeting. This way they learn about various
software engineering activities.
3) Defect detection: Defect detection phase is the core
phase of inspection process [4]. In this phase defects are
identified in the software requirements specification
(SRS). This phase can be organized in two ways. First is
the individual defect detection where each inspector
individually inspects the requirements specification or in
group meeting where two or more inspectors inspects the
requirements specification.
Knight and Meyers [4] have proposed the idea of a
Phased Inspection Method. In the Phased Inspection
Method each inspection phase is further divided into mini-
inspections. One or more inspectors are assigned to each
mini-inspection [4].
For example consider a software requirements
specification (SRS) for library information system. We
create four mini-inspections using Phased Index Method
and assign two or more inspectors to each mini-inspection.
Then if any requirement in software requirements
specification (SRS) pertaining to these four activities is
missing, this will be identified.
Porter et.al has proved empirically that mini-
inspections are costly [4]. During mini-inspections when a
defect is dectected it is repaired and then the same process
of inspection starts again. This increases the project cost.
This is the reason that we often find mini inspections [4].
4) Defect collection: There are three major objectives of
defect collection phase [4], the defects detected by the
inspectors during the defect detection phase are collected
and documented, the decision is made that the reported
defect is actually a defect ot not and the decision is made
to reinspect the defected software artefact or not.
In order to fulfill these objectives this phase is
normally carried out in group meeting. Since group
meetings are time consuming so three alternatives namely
managed meetings, depositions and correspondence are
reported in literature [4].
Managed meeting are formal meetings involving
limited number of participants [4]. Deposition is a special
type of meeting involving three persons only [4]. They are
moderator, inspector and author. In correspondence
inspectors and authors use email for communication [4].
They do not need to physically meet at some place.
In order to make decision regarding reinspection of a
software artefact certain statistical models like capture-
recapture models are used [4]. Capture-recapture models
are used in biological studies to estimate the size of
animal population [17]. When an animal gets trapped, it is
captured, marked and then released. When marked animal
is recaptured, it provides estimate of the total population
size based on overlaping samples.
The idea behind capture-recapture models in
requirements inspections is to allow several inspectors
read the same requirements specification [17]. Each
inspector will have a list of requirements with defects.
Then based on the overlap of defected requirements
among the inspectors, one can estimate the number of
defects remaining in the software requirements
specification.
5) Defect correction: In the defect correction phase the
author of the software requirements specification (SRS)
corrects the software requirements specification based on
the feedback obtained from defect collection phase. This
phase ensures that the detected defects are completely
removed form the software requirements specifcation
(SRS).
6) Follow-up: The objective of follow-up phase is to
ensure that the author of software requirements
specification (SRS) has resolved all the reported
incomplete or inconsistent requirements [4].
b. Requirements inspection roles
The people in the inspection team are assigned various
roles to carry out the requirements inspection process
smoothly. Inspection team normally comprises three to six
people with following roles [5].
1) Moderator: Moderator is a key person in the inspection
process. Moderator ensures that inspection team is
selected appropriately, inspection team is trained to carry
out the inspection process and abides by the predefined
rules and regulations for a particular meeting [5].
2) Producer or author: Producer is normally a person
who has developed a software requirements specification
under inspection [5]. During the overview phase of
requirements inspection process the producer explains the
software requirements specification to other inspection
team members. In some literature books producers are
also called as authors [6]. The producer must not serve as
moderator, reader or recorder [6].
3) Reader: The primary responsibility of reader is to
present the inspected requirements specification and lead
the inspection team in a logical fashion [6]. The role of
reader seems to be conflicting with producer or author
role. But reader helps to divert the attention of inspection
team from producer to the product under inspcetion [5].
4) Recorder (Optional): The recorder helps to reduce the
burden from moderator. The recorder keeps note of all
objections and issues raised during the inspection meeting
and helps the moderator to focus on the leading discussion
[5].
5) Inspector: Inspectors responsibilities are to focus on
the software requirements specification under inspection
and identify the confliciting or incomplete requirements
[6]. Similarly when the these requirements are removed
inspectors are responsible for re-examining the software
requirements specification (SRS).
c. Requirements inspection reading techniques
A reading technique provides a series of steps or
guidelines to the inspectors to detect defects in software
requirements specification (SRS). In other words reading
technique is a strategy for inspector [4]. Among reading
techniques ad-hoc reading and checklist-based reading are
most popular because they are practiced by the number of
companies [4].
1) Ad-hoc reading: In ad-hoc reading software
requirements specification is given to inspectors without
any guidelines or directions to look for incomplete
requirements [4]. The word ad-hoc means that no
technical support is given to inspectors to detect defects in
software requirements specification [4]. In ad-hoc reading
defect detection depends on the experience and
knowledge of the inspector.
2) Checklist based readin: In checklist-based reading
inspectors are provided with questions to answer while
inspecting a software requirements specification (SRS).
These questions are related to the quality of the software
requirements specification [4].
Checklists provide a structure to the validation process
and reduce the chances that inspectors will forget some
aspects of the requirements documents [7].
d. Advantages & disadvantages of requirements
inspections
The inspections are useful for large companies as they
require resources in terms of manpower. In large
companies multiple inspection teams can be formed. Each
team may be assigned responsibility to inspect particular
software artifact like software requirements specification
(SRS), design documents or code.
On the other hand inspections cannot be useful for
small companies. Although literature evidences support
inspection team of three people [5]. But in small
companies with comparatively smaller human resource,
inspections may not be as effective.
Inspections require knowledge of reading techniques
and also some pre-requisite knowledge about software
requirements specification (in case of requirements
inspections). Therefore inspections also require training
and external consultants can be involved in training [7].
So this training also adds to the overall project cost.
If a company is planning to use requirements
inspections without any previous experience, they may
introduce it as a pilot project with their normal
requirements validation process [7]. This will help to
judge the suitability of requirements inspections as
effective requirements validation technique.
7. REQUIREMENTS PROTOTYPING
Requirements prototyping helps requirements
engineers to identify and understand the customer
requirements. In addition prototyping also facilitates other
activities like system designing and user interface
development. Requirements prototyping serves as a
communication media between requirements engineers
and requirement issuers. It enables customers to
participate in the requirements validation process. There
are two types of prototyping [8],
a. Throw-away prototyping.
b. Evolutionary prototyping.
According to [8] throw-away prototyping helps in the
identification of poorly understood requirements. It is
used to resolve inconsistencies between requirements
engineers and requirement issuers. Once both agree to a
set of requirements, the prototype is discarded and these
agreed requirements are incorporated in the software
requirements specification (SRS).
Evolutionary prototyping is based on the agreed
requirements and is subject to quality constraints as
imposed in the software development [8]. The theme
behind evolutionary prototyping is to develop a functional
prototype and then constantly refine it based on the
feedback. The Dynamic Systems Development Method
(DSDM) is one of the agile methods and it uses
prototypes in its framework [18]. These prototypes can be
either throw away or evolutionary.
Therefore the companies using agile methods like
DSDM can use requirements prototyping for requirements
validation.
process they may be incorporated into requirements
documents.
Sometimes it is necessary to write prototype manual.
This will require resources like a person responsible for
drafting manual, time to write manual and financial
resources. In such cases this cost should be included in the
requirements validation costs [1].

a. Advantages & disadvantages of requirements 8. REQUIREMENTS TESTING

prototyping
The objective behind requirements testing is to
The advantages and disadvantages of requirements validate the requirements in the software requirements
prototyping are summarized below. specification (SRS) rather than the system [7]. In
Prototyping helps customers to visualize the requirements testing test-case are defined for each
developing software system. Customers may find difficult requirement in the software requirements specification
to visualize the requirements which are written in the (SRS). This helps to identify incomplete or ambiguous
software requirements specification (SRS) [7]. They may requirements because if for a particular requirement it is
find difficult to understand how these written difficult to derive a test-case then it indicates some
requirements will be transformed into a working software problem [7].
system. So they may not be able to identify the problems.
But on the other hand prototyping helps them to
understand the requirements and identify the problems,
issues or need for some additional / changed requirements.
The prototypes developed during the requirements
validation phase may also be used for system testing later
in the system validation process [7]. This way prototyping
ensures the consistency and correctness of final developed
system.
In some companies executable prototypes are used as
stop-gap system. The stop-gap systems are those systems
which can be delivered to the customer in case of delays
in the implementation of the final system [7]. Meanwhile
when the final system is developed and ready for
installation, it replaces the executable prototype. The
prototype developed during the requirements validation
phase can be further transformed into executable
prototype.
Some of the disadvantages of the prototyping
approach are listed below. FIGURE 2 . REQUIREMENTS TESTING [3]

Prototyping is usually costly and time consuming

activity. If a company wants to implement prototyping
then they need to purchase softwares for prototyping and
train people. In addition a requirement engineer will have
to do additional activity of building a prototype along with
gathering customer requirements, prioritizing them and
documenting them in software requirements specification
(SRS).
Paper prototyping is relatively cheap to apply [7]. In
paper prototyping, prototypes are drawn on paper. But it
requires special record logs to be preserved for future
reference. Similarly paper prototypes cannot be
transformed into executables ones, so after validation
The test-case derived for requirements testing can also
be used during the final testing of the system. Figure 2
represents the requirements testing.
In requirements testing the verification and validation
department or testing department is involved early in the
requirements validation phase to derive test-cases. This
normally requires human resource in terms of testers along
with requirements engineers. Similarly the testers should
be experienced professional and in case of new people
proper training is needed. This normally increases the cost
of project.
Test-case driven inspections commonly known as
TCD inspections are well known in requirements testing
and are based on the concept of reuse. Test cases
produced during TCD inspections are also used in other
phases of software development [13].
a. Test case driven inspections (TCD inspections)
Tony Gorschek and Nina Fogelstrm have proposed
the technique of test-case driven inspection of pre-project
requirements. This technique uses test-case as an
inspection tool by involving testers in the early stage of
development process known as pre-project stage [13].
The TCD Inspection process was used in Danaher
Motion Sr AB (DHR) Sweden and it is a three step
process [13] as shown in Figure 3.
FIGURE 3. TCD INSPECTION PROCESS [13]
According to [13] during the step 1 product manager
selects and reviews requirements to be included in the
initial formulation / specification. Some requirements are
also discarded. This is mostly ad-hoc process where
product manager utilizes his personal as well as
colleagues knowledge and experience for initial trial of
requirements. Then the selected requirements known as
formulated or specified requirements are passed on to the
step 2. These requirements are specified according to a
template and contains attribute such as ID, title,
description.
During step 2 TCD inspection itself is performed by
creating test-cases with the requirements [13].
Inappropriate and low priority requirements are removed
during this phase.
In step 3 inspected requirements are prioritized and in
addition project planning is performed [13]. Like step 1
and step 2 some requirements may also be discarded
during this phase. These three steps come under pre-
project phases and after step 3 requirements are selected
for implementation.
TCD Inspections are characterized by involving testers
in the inspection process, reducing the educational and
training cost of inspectors [13]. The most prominent
advantage of TCD inspections is for the product
managers. Product managers can select better
requirements for requirements selection and cost
estimation in the pre-project phase [13].
During the pilot study of TCD inspections at Danaher
Motion Sr AB (DHR) Sweden, the project managers
realized that the refined requirements were of vey high
quality [13]. Similarly completeness and understanding of
requirements improves during TCD inspections which
help in deciding to postpone or discard requirements.
b. Advantages & disadvantages of requirements testing
The main advantage of requirements testing is that it
ensures elimination of unwanted requirements and the
test-cases produced during it can also be used in the final
testing of the system.
The requirement testing is very useful for larger IT
companies having a well established testing department
with experienced testing professionals. Similarly
companies using this approach can also provide training
facilities to other companies planning to use requirements
testing.
The disadvantage of requirements testing is that it
involves costs. For small companies with relatively less
number of people it may not be useful. Similarly
requirements testing require experienced testers and
requirements engineers. Small companies may lack such
requirements in terms of experienced IT force. Moreover
small companies may not provide on job training to new
people for requirements testing.
9. VIEWPOINT-ORIENTED REQUIREMENTS VALIDATION
Some of the terms used to understand the concept of
viewpoint oriented requirements validation are defined
below.
 Universe of discourse: The universe of discourse is
the overall context in which software is developed
including all information and people involved in software
development [15].
Actors: The people involved in the universe of
discourse are known as actors [15]. The actors are of two
types, users on the demand size and software engineers on
the supply side [15].
Users on the demand size represent customers. Users
on supply side include project managers, requirements
engineers, programmers, testers.
Viewpoint: Viewpoint is defined as the standing or
mental position of an individual (actor) when examining
or observing the universe of discourse [15]. It is identified
by individuals name and his role in the universe of
discourse.
Perspective: A perspective is the set of facts which
are observed and modeled according to a particular
modeling aspect and viewpoint [15].
View: View is defined as the integration of
perspectives [15].
FIGURE 4. VIEWPOINT-ORIENTED REQUIREMENTS VALIDATION [1]
Hierarchies: The two types of hierarchies used in the
universe of discourse are is-a hierarchy of concepts and
parts-of hierarchy of concepts [15].
VWPL: The VWPL stands for viewpoint language. It
is used to represents the viewpoints [1].
The method of viewpoint oriented requirements
validation requires two or more analysts (viewpoints)
using VWPL to model the universe of discourse. In order
to understand viewpoint oriented requirements validation
consider two analysts, analysts 1 and analyst 2 as shown in
the Figure 4.
The analyst 1 and analyst 2 model the universe of
discourse using three prospective and two hierarchies. The
three prospective used are data, process and actor [1].
These perspectives and hierarchies are analyzed to
produce list of discrepancies and types of discrepancies
[15]. Then the perspectives are integrated in views shown
as view1 and view2 in figure 4. These two views are
compared for correctness and completeness. In figure 4
circles represents processes and boxes are the inputs and
outputs of processes [1].
The author searched electronic resources like ACM
digital library, IEEE Xplorer, Springer Link and Inspec.
But the author was unable to find much of the research
work done in requirements validation using viewpoints.
a. Advantages & disadvantages of viewpoint-oriented
requirements validation
The viewpoint-oriented requirements validation helps
to identify conflicting requirements based on viewpoints.
This approach recognizes that requirements should not be
considered from a single prospective. The major
advantage of this approach is that it incorporates multiple
views.
As there is no much work available in this area. This
may hinder requirements engineers in industry to use this
approach for requirements validation.
10. DISCUSSION
Requirements validation is one of the most crucial
activities in requirements engineering. There are number
of requirements validation techniques available in
literature each having its pros and cons. The software
development companies should implement a strategy to
develop a framework of requirements validation. This
strategy should clearly specify one or more requirements
validation techniques to be used. This will helps to ensure
that their developed software systems are according to the
stakeholders needs.
The importance of requirements validation techniques
is determined by the fact that they help to identify defects
that can be amplified in later stages of software
development. If these defects are identified in the
requirements validation phase, then overall cost of the
project will also be decreased and project will be
deployed to the customer in time. The cost is decreased in
terms of less effort in software regression testing phase,
test-case reuse (if a company is using requirements
testing) and less development time.
TABLE 1. COMPARISON OF REQUIREMENT VALIDATION TECHNIQUES
specification. These test cases can be reused later in the
integration testing or system testing. On the other hand
requirements prototyping can be reused further to develop
fully functional prototype.
Requirements prototyping involves customers. This
technique helps customers to visualize the system in
software requirements specification. Similarly in
viewpoint-oriented requirements validation customers can
be involved to have their view of the proposed system.
Requirements inspections and requirements testing lack
this feature of customer involvement.

11. FUTURE WORK

In this research study literature review is carried out

regarding requirements validation techniques. This could
be extended to conducting an industrial survey to gather
information about practiced requirements validation
techniques. During surveys people working in the process
area of requirements engineering can be interviewed. The
interview format can be semi-structured as it combines
both structured and unstructured interviews. This way the
interview questionnaire will consist of set of questions
arranged in if-then structure and list of open topics
which will help to carry our comprehensive interview.

Table 1 shows the comparison of requirement

TABLE 2. DATA INPUT FOR INDUSTRIAL SURVEY
validation techniques discussed in this paper.
It is evident form Table 1 that requirements
inspections and requirements testing techniques require
large teams as compared to requirements prototyping and
viewpoint-oriented requirements validation. These large
teams can be of three to six people or multiple teams
working together.
Requirements inspections and requirements testing are
more costly as compared to requirements prototyping and
viewpoint-oriented requirements validation. They require
inspection or testing professionals, physical meeting place
for teams and training session in case of new
professionals.
All the requirements validation techniques can be used
by large companies. But requirements inspection and
requirements testing are more suitable for large companies
as they require resources. Viewpoint-oriented
requirements validation can be used by both small and
large companies as it does not require specialized teams
for requirements validation. Prototyping is mostly used by
small companies but it can also be equally useful for large
companies. Large companies can use requirements The interview data can be collected in a form given in
prototyping for stop-gap systems. Table 2. In Table 2 third row will provide requirement
validation techniques used in industry. These techniques
In requirements testing test cases are written for
could be used in an experiment to identify some of the
verifying requirements in software requirements
effective requirements validation techniques being
practiced in industry. If the experiment is performed in
academic setting then students can be used as subjects.
12. CONCLUSION
The area of requirements validation has opened a new
horizon for researchers to explore. This will enable
companies to adopt techniques and develop systems
according to stakeholders needs in cost effective way. In
order to solve the problems with requirements validation
application of strategy for requirements validation is
required. Requirements prototyping can be easily used by
both small and big companies. While requirements
inspections and requirements testing are suitable for large
companies as they are performed in teams. On the other
hand there is not much research work done in viewpoint-
oriented requirements validation. But viewpoint-oriented
requirements validation provides possibility to identify
conflicting requirements based on viewpoints of various
stakeholders. These requirements validation techniques
will help to detect errors before they move on to the other
phase of software development life cycle and become
amplified.
13. REFERENCES.
[1] Gerald Kotonya, Ian Sommerville, Requirements
Engineering, John Wiley & Sons, New York, 1998.
[2] Thayer, R. & Dorfman, M. Software Requirements
Engineering 2nd Edition, IEEE Computer Society Press,
California, 1997.
[3] Gary E. Mogyorodi, What is Requirements- Based
Testing?, CROSS TALK The Journal of Defence Software
Engineering, March 2003.
[4] Oliver Laitenberger, A Survey of Software Inspection
Technologies, Handbook on Software Engineering and
Knowledge Engineering, Citeseer, 2002.
[5] Steven R. Rakitin. Software Verification and Validation for
Practitioners and Managers, Artech House Publishers, 2nd
edition (August 1, 2001).
[6] Ackerman, A. F., Buchwald, L. S., and Lewsky, F. H.,
Software Inspections: An Effective Verification Process,
IEEE Software, 1989, pp. 31-36.
[7] Ian Sommerville, Pete Sawyer, Requirements Engineering,
John Wiley & Sons, New York, 1997.
[8] J. Siddiqi, I. Morrey, R. Hibberd, G. Buckberry, Towards a
System for the Construction, Clarification, Discovery and
Formalisation of Requirements, proceedings of first
international conference on Requirements Engineering, IEEE,
1994, pp.230-238
[9] O. Laitenberger, T. Beil, T. Schwinn, "An industrial case
study to examine a non-traditional inspection implementation
for requirements specifications," presented at Proceedings of the
Eighth IEEE Symposium on Software Metrics, Los Alamitos
CA, 2002.
[10] M. E. Fagan, "Design and Code Inspection to Reduce
Errors in Program Development," IBM Systems Journal, vol. 15,
1976, pp. 182-211.
[11] CMMI-PDT, "Capability Maturity Model Integration
(CMMI), Version 1.1," in CMMI for Systems Engineering,
Software Engineering, Integrated Product and Process
Development, and Supplier Sourcing Version 1.1 (CMMI-
SE/SW/IPPD/SS, V1.1). Pittsburgh, 2002.
[12] ISO/IEC, "Software Process Assessment TR 15504:1998,"
vol. 2004. http://www.sei.cmu.edu/iso-15504/ : ISO/IEC, 1998.
[13] Tony Gorschek, Nina Dzamashvili Fogelstrm, Test-
case Driven Inspection of Pre-project Requirements-Process
Proposal and Industry Experience Report, in proceedings of the
Requirements Engineering Decision Support Workshop held in
conjunction with the 13th IEEE International Conference on
Requirements Engineering, 2005.
[14] Carolyn B.Seaman, Qualitative Methods in Empirical
Studies of Software Engineering, IEEE transactions on
Software Engineering, Vol 25, No 4, July/August 1999.
[15] J.C.S.P. Leite, P.A. Freeman, Requirements validation
through viewpoint resolution, IEEE Transactions on Software
Engineering, Vol 17, 1991, pp.1253-1269
[16] Christian W.Dawson, Projects in Computing and
Information Systems, Pearson, 2005, ISBN 0321263553.
[17] L.C. Briand, K. El Emam, B.G. Freimut, O. Laitenberger ,
A comprehensive evaluation of capture-recapture models for
estimating software defect content, IEEE Transactions on
Software Engineering, Vol 26, No 6, 2000, pp. 518-54
[18] Dot Tudor, George A. Walter, Using an Agile Approach in
a Large, Traditional Organization proceedings of agile 2006
conference, IEEE, 2006