University of Southern California Dissertations and Theses

Formalizing informal stakeholder inputs using gap-bridging methods

(USC Thesis Other)

Formalizing informal stakeholder inputs using gap-bridging methods

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content
FORMALIZING INFORMAL STAKEHOLDER INPUTS
USING GAP-BRIDGING METHODS

by

Hasan Kitapci

A Dissertation Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)

December 2007

Copyright 2007 Hasan Kitapci

ii

Dedication
To my dear wife, daughter, and parents
iii

Acknowledgements
Foremost, I thank to God for His continuous blessings during my doctorate study. The life
would have been much harder for me without praying Him at the tough times of my
research.
I would like to express my deepest gratitude to my advisor Dr. Barry Boehm for his
guidance, supervision and patient encouragement throughout this study. I also would like to
thank him for providing me with the financial support I needed during my doctoral studies. I
would like to thank Dr. Neno Medvidovic for his help and valuable suggestions during the
writing of the papers that improve the results of this dissertation. I am thankful to the other
members of the thesis advisory committee, Dr. Stan Settles, Dr. Cyrus Shahabi, Dr. Craig
Knoblock and Dr. Stephen Lu for the time they spent reading my dissertation and providing
comments on my study. I am most grateful to my colleagues for the encouragement and
support they gave me during this study. Special thanks go to Apurva Jain and Jesal Bhuta.
I particularly acknowledge the Turkish Republic Ministry of National Education for giving
me the opportunity to start studying this degree and the University of Southern California in
admitting me into its graduate school.
Finally, I would like to express my gratitude to my family for the love and support they give
me every day. Without their support and encouragement, this thesis would never been
completed. Especially my dear wife Elif and my daughter Hasna Gul deserve the most since
she experienced almost the same stress I did during dissertation research.
iv

Table of Contents
Dedication ............................................................................................................................... ii
Acknowledgements ............................................................................................................... iii
List of Tables ......................................................................................................................... vi
List of Figures ..................................................................................................................... viii
Abstract .................................................................................................................................. x
Chapter 1: Introduction ........................................................................................................ 1
1.1 Motivation of the Research ...................................................................................... 1
1.2 Significance of the Research .................................................................................... 3
1.3 Contributions of the Research .................................................................................. 7
1.4 Organization of the Dissertation ............................................................................ 10
Chapter 2: Background and Related Work ...................................................................... 11
2.1 Background Information ........................................................................................ 11
2.2 Related Work ......................................................................................................... 23
Chapter 3: Research Methods ............................................................................................ 31
3.1 Level of Formality – Representation Methods ...................................................... 31
3.2 Characteristics and Problems of Requirements Work Products ............................ 35
3.3 Gap-Bridging Methods .......................................................................................... 41
3.4 Evaluation of Gap-Bridging Methods .................................................................... 49
3.5 Hybrid Options Exploration .................................................................................. 52
Chapter 4: Acquiring Informal Stakeholder Requirements Inputs ................................ 54
4.1 The EasyWinWin Negotiation Process .................................................................. 54
4.2 Typical Defects in Requirements Negotiation ....................................................... 62
4.3 Quality Assurance Techniques for EasyWinWin .................................................. 63
Chapter 5: Process Framework: Hybrid Method ............................................................. 70
5.1 Process Framework ................................................................................................ 70
5.2 Our Hybrid Method ............................................................................................... 81
v

Chapter 6: Project Content and Software Process ........................................................... 94
6.1 Project Context ...................................................................................................... 94
6.2 Course Context ...................................................................................................... 94
6.3 Initial Hybrid Method (Fall 2004) ......................................................................... 98
6.4 Intermediate Hybrid Method (Fall 2005) ............................................................. 102
6.5 Our Hybrid Method ............................................................................................. 103
6.6 Lessons Learned Through Hybrid Exploration.................................................... 104
Chapter 7: Hybrid Method Tool Support ....................................................................... 105
7.1 Requirements Negotiation Defect Checker ......................................................... 105
7.2 Requirements Negotiation Transformer .............................................................. 110
7.3 Requirements Negotiation Assistant (RNA) ........................................................ 115
7.4 Lessons Learned During Prototyping .................................................................. 118
Chapter 8: Data Collection and Evaluation Results ....................................................... 119
8.1 Data Collection .................................................................................................... 119
8.2 Evaluation Results ............................................................................................... 121
Chapter 9: Conclusion and Future Work ........................................................................ 149
9.1 Conclusion ........................................................................................................... 149
9.2 Future Work ......................................................................................................... 151
Bibliography ....................................................................................................................... 154
Appendices ......................................................................................................................... 162
Appendix A: System and Software Requirements Definition (SSRD) Outline................... 162
Appendix B: Requirements Types and Attributes List ........................................................ 165
Appendix C: SSRD Requirements Templates ..................................................................... 167
Appendix D: Penn Treebank Tag Set .................................................................................. 169
Appendix E: Typical Problems for EasyWinWin Requirements Negotiation ..................... 171
Appendix F: Software Engineering (SE) Course Projects ................................................... 172
vi

List of Tables
Table 1: Relative Strengths of Requirements Representation Methods ................................ 33
Table 2: Typical Problems for Statement .............................................................................. 35
Table 3: Properties for a Good Requirement ......................................................................... 37
Table 4: Typical Problems for Requirement .......................................................................... 38
Table 5: Characteristics for a Good SRS ............................................................................... 39
Table 6: Typical Problems in an SRS .................................................................................... 40
Table 7: Evaluation of Gap-Bridging Methods ..................................................................... 50
Table 8: Statement-Level Defects (Example) ........................................................................ 62
Table 9: Negotiation-Level Defects (Example) ..................................................................... 63
Table 10: In-Process Checking Activities in EasyWinWin ................................................... 65
Table 11: Input and Output Information Types of the RE Activities .................................... 79
Table 12: Input and Output Information Types of the Requirements Validation .................. 80
Table 13: Requirements Elicitation, Analysis and Negotiation Activities ............................ 82
Table 14: Template Definition and Semi-Automatic Template Filling Activities ................ 84
Table 15: NLP Add-in to the Requirements Engineering Process ........................................ 89
Table 16: Keyword Analysis Add-in to the Requirements Engineering Process .................. 90
Table 17: Standard ARM Indicators ...................................................................................... 90
vii

Table 18: WinWin Tree View ............................................................................................. 112
Table 19: Template Attribute Mapping Processes ............................................................... 113
Table 20: Filled Requirement Template (Example) ............................................................ 114
Table 21: Student Demographics ......................................................................................... 125
Table 22: Number of Defects found by IV&Vers in Negotiation Results ........................... 132
Table 23: Number of Defects found by Defect Checker in Negotiation Results ................. 133
Table 24: Number of True Positives and False Positives .................................................... 133
Table 25: Distribution of False Positives ............................................................................. 134
Table 26: Defect Rates for Syntactic Tools ......................................................................... 140
Table 27: Requirements and Attributes Overview .............................................................. 165
Table 28: Template for a Project Requirement in the SSRD ............................................... 167
Table 29: Template for a Capability Requirement in the SSRD ......................................... 167
Table 30: Template for a System Interface Requirement in the SSRD ............................... 168
Table 31: Template for a Level of Service Requirement in the SSRD ................................ 168
Table 32: Penn Treebank Tag Set ........................................................................................ 169
Table 33: Typical Problems in WinWin Artifacts ............................................................... 171
Table 34: List of Real-Client Projects for SE Course in fall 2005 ...................................... 172
Table 35: List of Real-Client Projects for SE Course in fall 2006 ...................................... 173
viii

List of Figures
Figure 1: Requirements Engineering Process Inputs and Outputs ......................................... 13
Figure 2: Spiral Model of the Requirements Engineering Process ........................................ 15
Figure 3: The WinWin Negotiation Model ............................................................................ 24
Figure 4: Requirements Representation Rapid Modifiability – Precision Tradeoffs ............. 34
Figure 5: EasyWinWin Products with Important Lifecycle Deliverables ............................. 54
Figure 6: EasyWinWin Requirements Negotiation Activities ............................................... 56
Figure 7: Requirements Engineering Activities ..................................................................... 73
Figure 8: Hybrid Method Framework .................................................................................... 83
Figure 9: Independent Verification and Validation in CSCI 577 SE Course ........................ 97
Figure 10: Initial Hybrid Method (Fall 2004) ........................................................................ 98
Figure 11: EasyWinWin Artifacts and MBASE SSRD Requirements Template ................ 100
Figure 12: Intermediate Hybrid Method (Fall 2005) ........................................................... 102
Figure 13: Requirements Negotiation Assistant Block Diagram ......................................... 117
Figure 14: Number of Defects Found in Negotiation Results per Team ............................. 126
Figure 15: Defects Distribution in Requirements Negotiation Results for fall 2005 ........... 127
Figure 16: Defect Numbers vs. WinWin Artifact Numbers per Team ................................ 128
Figure 17: Defects Distribution in Requirements Negotiation Results for fall 2006 ........... 129
ix

Figure 18: Numbers of Concerns – Defects in Requirements Documents in fall 2005 ....... 130
Figure 19: Numbers of Concerns – Defects in Requirements Documents in fall 2006 ....... 131
Figure 20: False Positive Distribution ................................................................................. 134
Figure 21: Defect Rule Pattern Distribution ........................................................................ 135
Figure 22: Comparison of Number of Defects in Negotiation Results ................................ 136
Figure 23: Defect Checker versus IV&Vers Review Analysis Results ............................... 136
Figure 24: Comparison Analysis for Syntactic Tools and Defect Checker ......................... 141
Figure 25: Comparison between Agreements and Requirements based on Topics ............. 143
Figure 26: Cardinality between Agreements and Requirements ......................................... 144
Figure 27: Mean Number of Agreements and Requirements for fall 2005 ......................... 145
Figure 28: Mean Number of Agreements and Requirements for fall 2006 ......................... 145
Figure 29: Comparison of Requirements Related Activities ............................................... 146
Figure 30: Comparison of Cost of Effort for SSRD Documentation ................................... 147
x

Abstract
For many software and systems developers, Requirements Engineering is one of the biggest
problems they face. Without an accurate, consistent, and complete requirements
specification it is very difficult to develop, change, and maintain software. It is now a
generally accepted and frequently stated fact that one of the major causes of software
development failures is poor requirements engineering. The CHAOS Surveys by the
Standish Group report that 15% of the projects fail outright, and 51% are late, run over
budget or provide reduced functionality. On average only 54% of the initial project
requirements are delivered to the client. Inadequate specification of system requirements is
considered to be one of the main causes for project failure.
Good – sufficiently complete, consistent, well-understood, and testable – requirements are a
prerequisite for successful projects. Without understanding what the stakeholders – people
who have some demands on the product, and hence must be consulted in the requirements
gathering activity - really wants and needs, and writing these requirements in a concise,
understandable and testable manner, projects not only won’t lead to what the stakeholders
wanted, but also they probably will fail.
Often, the stakeholders who can contribute the most value and realism to system
requirements are the ones with the least time available to participate in the process.
Negotiations are crucial in the early stages of the lifecycle to develop a set of mutually
satisfactory requirements. We have found the EasyWinWin requirement negotiation method
and tools to be an effective way to involve such busy stakeholders. It avoids time-consuming
xi

group wordsmithing, but results in relatively informal win-win agreements (e.g., “24/7” or
“anytime, anywhere” vs. more precise availability and accessibility requirements). The
transition to semi-formal and formal representations is still a challenging problem. While the
EasyWinWin improves the identification and negotiation of stakeholders’ requirements, the
transition to more formal system requirements and further project artifacts is based on
intuition and experience.
Requirements problems are present to a certain degree in almost all projects despite the fact
that there are available techniques that could address them. The approach of our research is
to integrate gap-bridging methods – template, NLP, keyword analysis, formal experts, and
inspection – with requirements engineering to leverage the benefits of these methods in order
to create a better requirements engineering process. The basic idea is that orchestrating gap-
bridging methods whenever and wherever possible through the requirements engineering
process could eliminate requirements related problems. This framework helps consistently
elicit the customer needs, save time and cost, and trace the requirements through the entire
development life cycle.
We enhance the existing tool EasyWinWin, to improve the results of requirements
negotiation process and further to define the requirements specifications with the
characteristics of good requirements taken into account. Beginning with the identification of
requirements leading to the analysis and negotiation of requirements to the actual generation
of requirements specification, the framework combines all requirements engineering
activities in order to eliminate problems and provide a good foundation for the later artifacts
of software development.
1

Chapter 1:
Introduction
1.1 Motivation of the Research
The challenge of systems development has become “building the right system by defining
the right one” instead of “building the system right”. The complexity of the communication
and decision making processes among stakeholders of the project has been identified as one
of the major factors accounting for misunderstandings in the system development process
[Brooks 1995].
Requirements engineering is a crucial first step in the software development process. It is a
through exploration of the intended product with the intention of discovering - in some cases
inventing - the functionality and behavior of the product. Whether you are building custom
systems or systems by assembling components, using commercial-off-the-shelf software or
making changes to existing software, you still need to explore, capture, and communicate the
requirements.
Requirements engineering related problems have been reported frequently in the literature.
According to "Chaos" [Standish 1999], a software development report by the Standish
Group research firm, the top reasons for project failure are lack of user input and incomplete
or changing requirements. The Standish Group has also found that even though projects are
2

being delivered on time and within budget, the statistics for delivering requirements and
meeting customer expectations are decreasing significantly.
Over the years much work has been done to improve the productivity and quality of the early
stage of the software lifecycle. However, requirements engineering still remains as a hard
problem to automate due to its inherently human-centered nature. There is a gap between
users (who have needs but are unaware of how to specify them as requirements) and
requirements engineering (who know how to specify requirements, but do not know the
needs). From this perspective, most difficult part of the requirements engineering process is
obtaining a complete and consistent set of requirements. Failure to document requirements in
a format that promote clear, complete and comprehensive understanding is a serious risk to
project success. In his article [Wiegers 2000], Wiegers indicates that the most essential and
yet often neglected practice is to write down, or document, the requirements. He goes on to
indicate that requirements should be documented in some acceptable, structured format as
they are gathered and analyzed.
Requirements engineering is getting more attention at present because of the deficiencies
responsible for poor project outcomes. Difficulty of motivating stakeholders to state
precisely what they need since they might not know exactly what they need to they have
incomplete knowledge about the functionality of the intended application [Nuseibeh 2000].
When requirements are discovered, conflicts, overlaps, omissions and inconsistencies should
be analyzed [Kotonya 1998; Sommerville 1997]. In the industry practice, the analysis of
requirements is made by humans with a clerical and tedious process that consists of reading
requirements documents for defects [Firesmith 2003]. Documents containing defects that
used for reference in further processes will cause more defects in the product. Although the
3

impact of a defect in early life cycle documents is rather low, in later phases the impact will
get much higher, since more work is necessary and more people are involved to fix it.
Defects in project requirements cause many projects to fail or overrun their schedule or
budget. Boehm [Boehm 1981] has reported that although only 6 percent of the project cost
and between 9 and 12 percent of project's duration is spent in the requirements phase, it costs
between five to ten times more to repair errors during coding than during the requirements
phase: and it costs between 100 and 200 times more during maintenance.
Almost all research in requirements engineering deals with the introduction of more
formality into the process. More research must be done to provide natural language writers
with insight into how they can improve their documents without formal models. Although
users’ needs truly are difficult to determine, we still need guiding principles to reduce the
ambiguity inherent in natural language document [Hsia 1993].
To correct this situation, it is clearly necessary to address the issue of requirements
elicitation, documentation, validation and management in a relatively more focused manner.
Effective processes and automated tool support need to be developed through which
requirements can be elicited, negotiated, documented, validated and managed through the
software development life cycle. The expectation is that as a result of this, sufficiently
complete, consistent, unambiguous and testable requirements specification will be developed
in the future.
1.2 Significance of the Research
The most important steps in problem solving are defining the problem to be solved and
finding a potential solution. A good, clear, and simple definition can prevent a false start in
4

the search of a solution. As it is mentioned in Techniques of Inventive Problem Solving
(TRIZ) methodology, any application starts with the understanding of the technical system
or technological process and the situation in which the problem appears. Then a set of
problems is recognized, correct statements of the problems are formulated, and at the end the
appropriate heuristics are applied to find the best possible solution of the problems
[Savransky 2000].
It is widely accepted that establishing requirements is considered the most important stage of
systems development. No other stage affords the greatest potential for significant
improvement in time, cost, and the quality of the system [Robinson 1998]. Early detection of
problems in requirements has a very important impact on the overall quality of the software
development process.
Nuseibeh and Easterbrook [Nuseibeh 2000] present major challenges of RE where one way
to solve some of those challenges quoted as “Bridging the gap between requirements
elicitation approaches based on contextual enquiry and more formal specification and
analysis techniques."
A critical success-factor in requirements elicitation and negotiation is the availability and
participation of key stakeholders. However, stakeholders who can contribute most value,
insights, and realism often have the least time to participate in such a process. In such cases,
one would like to use their limited time to participate in defining and negotiating among the
most critical requirements for the system. Therefore an effective and efficient way to elicit,
document, and validate requirements is crucial.
5

An important effort in requirements elicitation has been the adoption of Natural Language
Processing (NLP) to facilitate automation. The nature of the natural language, the input
descriptions often lack preciseness, completeness and consistency where further
communication with stakeholders is essential. There is a demand for mechanisms to enable
stakeholders to participate more in terms of clarifying ambiguity and contribute the missing
domain information that are essential for the success of the project with the aid of NLP-
based systems.
Defining requirements is a complex and difficult process, and defects in the process often
lead to costly project failures [Standish 1995]. There is no complete and well-defined set of
requirements waiting to be discovered in system development. Requirements emerge in a
highly collaborative, interactive, and interdisciplinary negotiation process that involves
heterogeneous stakeholders. During the development of the WinWin negotiation model
[Boehm 1995] and the EasyWinWin requirements negotiation method [Boehm 2001] we
have gained considerable experience in capturing informal requirements in dozens of
projects. EasyWinWin helps a team to jointly brainstorm, organize, and negotiate informal
inputs into a comprehensive set of artifacts about the goals and preferences of stakeholders,
existing conflicts, and achieved agreements. Nevertheless, the result of requirements
negotiation is typically not a complete, consistent, traceable, and testable requirements
specification. For example, stakeholders might become enthusiastic about proposed
capabilities and ratify idealistic agreements such as “anytime, anywhere” service.
Our lessons learned during real-world negotiations show that it is not effective to dampen
the enthusiasm of stakeholders and the creative flow of ideas with techniques emphasizing
detailed wordsmithing, correctness, consistency, etc. [Boehm 2001]. However, post-
6

processing and improving informal inputs into more precise and realistic requirements for
the stakeholders to review and iterate is not well understood. A failure to successfully bridge
the gap from rather informal inputs to more formal representations may have serious
negative impacts on contract negotiation, initial project planning, architectural decisions, or
end-item deliverables [Grünbacher 2001].
Thus, we have been exploring alternative methods for bridging the gap between informal
inputs and a requirements specification: template-based refinement, natural language
processing, keyword analysis, formal methods expertise, and inspections. The goal is to
create a tool-assisted hybrid method framework for development teams and stakeholders in
order to achieve an effective requirements negotiation and transformation. Our main
research question is “How to orchestra gap-bridging techniques to provide a sufficiently
complete, consistent, unambiguous, and testable software requirements.”
Additional research questions are: “What are the benefits and challenges of gap-bridging
techniques?”, “How can gap-bridging approaches be applied in requirements engineering
process?”, “What is the best medium in order to represent the requirements specifications?”,
‘What are the characteristics of work products throughout the requirements engineering
activities?”. In our research, we try to find answers to these questions.
We determined to test the following null hypothesis: “For software development projects,
the mean number of defect for requirements related work products and the cost of producing
those products will not differ using our tool-assisted method (mixed-initiated template,
natural language processing, keyword analysis) and other approach (human-initiated
template and non-assisted inspections) or other requirements syntactic analysis tools”.
7

Further the main null hypothesis is reduced into more simple null hypotheses in order to
prove:
Hypothesis 1 (H1): The number of defects found in requirements negotiation results
will not increase between the tool-assisted method and the non-assisted approach.
Hypothesis 2 (H2): The number of defects found in requirements negotiation results
will not increase between our tool and other requirements syntactic analysis tools.
Hypothesis 3 (H3): The cost of identifying defects in requirements negotiation
results will not decrease between the tool-assisted method and the non-assisted
approach.
Hypothesis 4 (H4): The cost of producing the requirements document will not
decrease between the tool-assisted method and the non-assisted approach.
1.3 Contributions of the Research
There are two principle reasons new inventions: (1) a problem arises outside the technique
(e.g., demand from society or creativity of an inventor); (2) a problem arises inside the
technique (e.g., cost reduction and quality improvement efforts or new materials or
technology available) [Savransky 2000]. My research fits into the second principle where I
am trying to apply the existing approaches in a more efficient way to solve some of the
problems come up during requirements engineering.
The more complete or through the project is in identifying and communicating with all the
stakeholders, the higher the chance of producing a high quality requirements set. Improving
8

the processes of eliciting, documenting, and managing requirements is critical for project
success. Although there are tools that can extract requirements from existing documentation,
few of them provide a facility to elicit and gather the requirements directly from the
stakeholders.
Most of the time, the processes applied for improving the quality of the requirements
specification start with a set of requirements specifications which have already been
gathered and documented by requirements engineer and often where the rationale behind
those requirements are missing. There is a need to develop an integrated environment that
brings together techniques and solutions to the issues of requirements engineering process
where all success-critical stakeholders can contribute the documentation and validation of
software requirements.
The aim of our research is to provide maximum support for gathering and specifying
requirements from success-critical stakeholders. Our framework focuses on involving all
success-critical stakeholders in an iterative specification of requirements where stakeholders
supported by gap-bridging techniques, some used for semi-automation of defect detection, in
order to reduce the defects in the front end of software development process. In addition,
information extracted by those techniques will return to the stakeholders as feedback during
negotiation and documentation activities. Furthermore, semi-automation of requirements
template attributes identification and requirements documentation using template-based
refinement approach will improve the quality of the requirements gathered during
requirements engineering process for the success of the product outcome in the end of the
development life cycle.
9

The goals of the framework are to:
• Document requirements that each stakeholder will interpret the same way
• Support stakeholders in creating and maintaining consistent and traceable template-
based requirements specification
• Capture and cross-reference the rationale information for requirements
• Enable multiple stakeholders to collaborate location dependent into requirements
documentation
• Increase the probability of customers stating real and complete requirements
The main contribution of this research will be as follows:
• Reducing the number of defects that occur during requirements negotiations and
documentation by identifying typical defects with assisting how to remove them
using the gap-bridging techniques
• Providing a method of using document templates in the creation and analysis of
informal software requirements specifications
• Creating descriptions of software requirements which are easier to understand and
contain fewer errors and inconsistencies
• Providing a collaborative environment based on group support system to elicit,
analyze, negotiate, define, and validate the software requirements integrated with the
gap-bridging techniques
10

The novelty of the research is that we will provide an integrated framework to the success-
critical stakeholders the requirements engineering activities by applying the chosen gap-
bridging techniques.
1.4 Organization of the Dissertation
The remainder of this proposal is organized as follows: Chapter 2 addresses the background
information about the research and summarizes existing and current research that has
contributed to the current body of knowledge in requirements engineering. Chapter 3
describes comparison relative strengths of various target requirements representation
methods and the analysis of different approaches for formalizing informal requirements.
Chapter 4 explains the EasyWinWin negotiation approach for acquiring stakeholder inputs
and discusses typical characteristics of negotiation results. Chapter 5 describes our
framework approach for formalizing informal requirements. Chapter 6 presents the project
content and software process with different stages of the hybrid methods. Chapter 7 presents
the tool support for the hybrid method. Chapter 8 summarizes the data collection and
evaluation results from hybrid method applied to e-services projects. Chapter 9 rounds out
the dissertation with conclusions and future work. The appendices of this dissertation contain
additional information regarding to clarify some concepts of the research.
11

Chapter 2:
Background and Related Work
In this section we will provide more extensive definitions of some terms and concepts that
will be used throughout the dissertation.
2.1 Background Information
This section provides some theoretical background information of requirements engineering.
2.1.1 What is a Requirements
Dorfman and Thayer [Dorfman 1997] provide the following definition for a software
requirement:
1. A software capability needed by the user to solve a problem or achieve an objective,
2. A software capability that must be met or possessed by a software or system
component to satisfy a contract, specification, standard, or other formally imposed
documentation.
2.1.2 Types of Requirements
Sommerville and Sawyer [Sommerville 1997] categorize requirements to functional and
non-functional requirements: functional requirements describe what the system should do
and non-functional requirements place constraints on how these functional requirements are
12

implemented. On the other hand, in MBASE software requirements document consists of
project requirements (cost, schedule, development tools, support, etc.), system capability
requirements (features and services), interface requirements (to the user and to other
systems), level of service requirements (‘non-functional’ aspects), and evolution
requirements (most likely directions of system change and growth) [Boehm 1999; Robertson
1999].
2.1.3 Software Requirements Specification
A software requirements specification (SRS) is a document containing a complete
description of what the software will do, independently of implementation details. An SRS is
an important part of the requirements process of the software life cycle and is used in design,
implementation, project monitoring, verification and validation, and in training as described
in IEEE STD 1074-1997 [IEEE 1997].
2.1.4 Requirements Engineering
The first step in any software developmental effort is to determine exactly what the software
system shall do. Software requirements engineering is defined as all the activities devoted to
identification of user requirements, analysis of the requirements to drive additional
requirements, documentation of the requirements as a specification, and validation of the
documented requirements against the actual user needs. As RE is concerned with
interpreting and understanding stakeholders’ goals, needs and beliefs, there are many
problems associated with RE which may lead to inconsistent and incomplete requirements
and cancellation of software projects. Since RE is one of the main contributions to the
13

success of software projects, improving the RE process can significantly increase the
likelihood of software project success.
RE is an engineering activity because it is concerned with identifying appropriate
methodologies to develop software solutions and identifying cost effective ways of doing so.
RE is also a management activity as it is concerned with managing RE activities such as
monitoring product requirements, and managing the project scope, cost and schedule
throughout the software development process.
The following Figure 1 shows the typical inputs and outputs of the requirements engineering
process [Kotonya 1998].

Figure 1: Requirements Engineering Process Inputs and Outputs
The inputs for the requirements engineering process are:
• Existing systems information: Information about the functionality of system to be
replaced, enhanced, extended or other systems which interact with new system.
14

• Stakeholder needs: Description of what system stakeholders need from system to
support work.
• Organizational standards: Standards used an organization regarding system
development practice, quality management, etc.
• Regulations: External regulations such as health and safety regulations which apply
to the system.
• Domain information: General information about the application domain of the
system.
The outputs for the requirements engineering process are:
• Agreed requirements: A descriptions of the system requirements which is
understandable by stakeholders and which has been agreed by them.
• System specification: This is a more detailed specification of the system
functionality which may be produced in some cases.
• System models: A set of models such as a data-flow model, an object model, a
process model, etc. which describes the system from different perspectives.
There are other products that have been produced by using the information gathered during
requirements engineering which shapes the flow of the software development. For example,
a proposal which summarizes the agreed requirements for customer and estimate of
resources, timeline, costs, and a project plan which includes schedule, milestones, phases
for delivery.
15

2.1.5 Requirements Engineering Activities
The requirements development phase includes activities from requirements elicitation,
requirements analysis and negotiation, requirements documentation, requirements validation
and requirements management.
Figure 2 shows these different activities in a spiral model that are repeated until a decision is
made that the requirements specification document should be accepted. If a draft of the
requirements specification document is found to have problems, the elicitation, analysis and
negotiation, documentation, validation spiral is re-entered. This continues until an acceptable
requirements specification document is produced or until external factors such as schedule
pressure or lack of resources mean that the requirements engineering process should end
[Boehm 1998]. A final requirements specification document should then be produced. Any
further changes to the requirements are then part of the requirements management process.

Figure 2: Spiral Model of the Requirements Engineering Process

16

2.1.5.1 Requirements Elicitation
Requirements elicitation is the specific processes of gathering, determining, extracting, or
exposing software requirements. From the user’s perspective, good elicitation results in them
having a better understanding of their needs and constraints. From the developer’s
perspective, it constructs a clear, high-level specification of the problem that is to be solved.
Most importantly, a good elicitation process builds a common vision of the problem and the
conceptualized software solution among stakeholders.
Requirements elicitation is a difficult process in which one has to deal with ambiguity,
informality, incompleteness, and inconsistency, in which the knowledge of the requirements
is anything. The better the requirements are understood, the more likely the resulting system
will be effective for the stakeholders. Thus, the elicitation of requirements relies on
successful involvement and interaction of multiple stakeholders and usually adopts natural
language to represent knowledge.
The result of requirements elicitation is a list of requests or needs that are described textually
with priorities relative to one another.
2.1.5.2 Requirements Analysis and Negotiation
Requirements analysis is a critical task in software development as it involves investigating
and learning about the problem domain in order to develop a better understanding of the
stakeholders’ actual goals, needs, and expectations. Requirements analysis is the activity
during which the requirements gathered during elicitation are analyzed for conflicts,
inconsistencies, ambiguities, missing requirements or extra requirements. During this
activity, negotiation between all stakeholders occurs to arrive at a set of agreed upon
17

requirements. In addition, requirements analysis and elicitation are very closely interleaved.
Information gathered during this activity often has to be interpreted, analyzed, modeled, and
validated before the requirements engineer can feel confident that a complete enough set of
requirements of a system have been collected.
Requirements negotiation can be seen as an iterative process through which stakeholders
make tradeoffs between requested system functions, the capabilities of existing or
envisioned technology, the delivery schedule and the cost [Curtis 1988]. Decisions made by
stakeholders from different divisions and often different organizations need to reach
agreement about the intended system have a profound effect on the technical and economic
feasibility of the project.
2.1.5.3 Requirements Documentation
Requirements documentation is the activity during which requirements are recorded in one
or more forms, usually in a Software Requirements Specification document. This document
is used to communicate the requirements to customers, end-users, managers, designers, and
system developers. It is important to have a standard template for requirements documents
that provides a checklist to ensure that all things are considered.
One of the main problems of requirements documentation is expressing customer
requirements in a form that can be understood not only by requirements engineers, but also
by non-computer professional customers and users. Requirements documentation is an
iterative process that will go into more details during each iterative cycle in development
phases.
18

In writing a requirements document, two aspects have to be carefully balanced: The need to
make the requirements document readable and the need to make the set of requirements
processable. The first of these concerns the structure of the document, how it is organized
and how the flow of it helps the reviewer to place individual requirement statements into
context. The second focuses on the qualities of individual statement of requirements, the
language used to promote clarity and preciseness, and how they are divided into single
traceable items.
2.1.5.4 Requirements Validation
Requirements validation is the activity during which the requirements are checked for
omitted, extra, wrong, ambiguous and inconsistent requirements. This activity also checks to
ensure that all requirements follow stated quality standards.
Validation involves evaluating the correctness and completeness of the requirements, to
ensure that a system built to those requirements will satisfy the users’ needs and
expectations. Inspections and checklists can be very effective in discovering inconsistencies,
omissions, ambiguities, etc.
2.1.5.5 Requirements Management
Requirements management is a systematic approach to eliciting, organizing, and
documenting the requirements of the system, and a process that establishes and maintains
agreement among stakeholders on the changing requirements of the system.
19

A requirements management process includes several key components to function properly.
Projects need adequate feedback methods combined with ongoing documentation,
communication, traceability, and change management.
2.1.5.6 Requirements Traceability
Requirements tracing is needed to compare requirements against other information. Forward
tracing is from stakeholders’ demands to requirements to see that all demands are reflected
in the requirements. This is part of validation, but often neglected with the result that
important business goals may be lost. Backward tracing is from requirements to demands to
see that all requirements have a purpose. This is another part of validation.
2.1.6 Requirements Specification Criteria
Barry Boehm [Boehm 1984] and Alan Davis and his colleagues [Davis 1993] have identified
the criteria that a requirement writing team should look for when they review a natural
language specification. The four basic criteria for requirements specifications are
completeness, consistency, feasibility, and testability [Boehm 1984].
Completeness: A specification is complete to the extent that all of its parts are present and
each part is fully developed. A software specification must exhibit several properties to
assure its completeness.
• No TBDs: TBDs are places in the specification where decisions have postponed by
writing “To be Determined” or “TBD”.
• No nonexistent references: These are references in the specification to functions,
inputs, or outputs (including databases) not defined in the specification.
20

• No missing specification items: These are items that should be present as part of the
standard format of the specification, but are not present.
• No missing functions: These are functions that should be part of the software product
but are not called for in the specification.
• No missing products: These are products that should be part of the delivered
software but are not called for in the specification.
Consistency: A specification is consistent to the extent that its provisions do not conflict
with each other or with governing specifications and objectives. Specifications require
consistency in several ways.
• Internal consistency: Items within the specification do not conflict with each other.
• External consistency: Items in the specification do not conflict with external
specification or entities.
Traceability: A specification is complete to the extent that all of its parts have clear
antecedents in earlier specifications or statements of system objectives.
Testability: A specification is testable to the extent that one can identify an economically
feasible technique for determining whether or not the developed software will satisfy the
specification. To be testable, specifications must be specific, unambiguous, and quantitative
wherever possible.
Thus, it often requires a good deal of added effort to eliminate a specification’s vagueness
and ambiguity and make it testable. But such effort is generally well worthwhile: It would
21

have to be done eventually for the test phase anyway, and doing it early eliminates a great
deal of expense, controversy, and possible bitterness in later phases.
2.1.7 Requirements Engineering Problems
Requirements of bad quality, such as the requirements are ambiguous or incompletely
specified, can have disastrous consequences for the whole project of it is propagated to the
later development steps. Bell and Thayer in their paper “Software Requirements: Are they
really a problem?” [Bell 1976] quoted the following: “It is difficult to get the requirements
right; some common problems are ill-defined terms, inconsistencies, ambiguities, and the
tendency to mix requirements with design decisions.” This was a long time ago; however,
the situation hasn’t changed much in the software development.
Experience has shown that uncontrolled use of natural language can lead to ambiguous,
imprecise and unclear specifications with possibly disastrous consequences for the
subsequent software development process [Meyer 1985].
According to the European Software Improvement Training Initiative survey of 3,800
software projects, fully 50% of all projects reported that requirements specifications were a
“major problem” and an additional 35% reported that requirements specifications were a
“minor problem,” making requirements specification the number one source of the software
problems [Leffingwell 2003]. In addition, Software Engineering Institute (SEI) reported that
requirements problems are the most frequent cause of failure in the following situations:
projects that are significantly over budget, significantly past schedule, significantly reduced
scope, significantly poor quality, not significantly used once delivered, or cancelled
[Firesmith 2003].
22

Problems with the requirements ultimately cause the project to miss the cost-schedule-
performance targets because not capturing all the requirements in a structured manner results
in these specific problems:
• Increase cost and schedule: Effort is spent during design and implementation trying
to figure out what the requirements are.
• Decrease product quality: Poor requirements cause the wrong product to be
developed and delivered or the scope is reduced to meet schedule or cost constraints.
• Increase maintenance effort: Lack of traceability increases the effort to identify
where changes are required.
• Create disputes with the customer: Ambiguity causes differences in expectations
and contractual issues.
The fundamental problem of requirements definition is ambiguity. Sources of ambiguity due
to errors exist in variations in what stakeholders see or hear of a critical event (observational
ambiguity), variations in what stakeholders remember of a critical event (recall ambiguity),
variations in how stakeholders interpret important happenings associated with a critical event
(interpretation ambiguity), and variations in how stakeholders define in their own mind the
problem to be solved (problem understanding ambiguity) [Gause 1989].
Thus, it often requires a good deal of added effort to eliminate a specification’s vagueness
and ambiguity and make it testable. But such effort is generally well worthwhile: It would
have to be done eventually for the test phase anyway, and doing it early eliminates a great
deal of expense, controversy, and possible bitterness in later stages.
23

2.2 Related Work
There are two main questions that are related with requirements: “Am I building the right
requirements?” and “Am I building the requirements right?”. The right requirements rely on
the understandability of desires and expectations of the stakeholders; that is, it is about the
quality of the content of the requirements. In addition, building the requirements right refers
to the way the requirements are written; that is, it is about processes, standards,
methodologies, tools, and techniques that are used to manage the requirements specification
process.
2.2.1 WinWin Methodology
The general win-win approach evolved more or less independently as an interpersonal-
relations [Waitley 1985], success-management [Covey 1990], and project-management
[Boehm 1989] approach. We usually define it as “a set of principles, practices, and tools,
which enable a set of interdependent stakeholders to work out a mutually satisfactory (win-
win) set of shared commitments.”
Interdependent stakeholders can be people or organizations. Their shared commitments can
relate to information system requirements in particular (the WinWin groupware system’s
primary focus) or can cover most continuing relationships in work and life (for example,
international diplomacy). Mutually satisfactory generally means that people do not get
everything they want but can be reasonably assured of getting whatever it was to which they
agreed. Shared commitments are not just good intentions but carefully defined conditions. If
someone has a conditional commitment, he or she must make it explicit to ensure all
stakeholders understand the condition as part of the agreement.
24

The negotiation model guides success-critical stakeholders in elaborating mutually
satisfactory agreements. Stakeholders express their goals as win conditions. If everyone
concurs, the win conditions become agreements. When stakeholders do not concur, they
identify their conflicted win conditions and register their conflicts as issues. In this case,
stakeholders invent options for mutual gain and explore the option trade-offs. Options are
iterated and turned into agreements when all stakeholders concur. Additionally, we use a
domain taxonomy to organize WinWin artifacts (win conditions, issues, options,
agreements), and a glossary captures the domain’s important terms. The stakeholders are in a
WinWin equilibrium condition when the agreements cover all of the win conditions and
there are no outstanding issues (See Figure 3).

Figure 3: The WinWin Negotiation Model
WinWin Negotiation Model integrates requirements analysis with rationale information to
support and capture requirements negotiations consisting of win conditions, issues, options,
and agreements, and their interrelationships among each other.
25

2.2.1.1 Group Support Systems (GSS)
The integration of stakeholders’ views into a coherent set of requirements is particularly
difficult because of the diversity of stakeholders’ background and their usage of different
terminology. Since the requirements negotiation and specification is a joint effort among
stakeholders, the need to support collaborative activities during the requirements engineering
process is evident. The interactions between the stakeholders could be improved by
capitalizing on advances that have been made in the area of computer-supported cooperative
work. Group Support Systems (GSS), technologies designed to facilitate human interactions
can be used to support the collaboration among stakeholders in the requirements engineering
stages of system development process.
Groupware technology is used widely to communicate, cooperate, coordinate, solve
problems, or to negotiate. GSS aids in addressing the complexity inherent in requirements
definition and negotiation. A group support system is a collection of computer-based
collaborative tools (e.g. for idea generation, idea organization, idea evaluation) that a team
may use to focus and structure their mental effort as they work together toward a goal in
repeatable, predictable ways [Nunamaker 1996]. A GSS typically includes software tools for
brainstorming and idea generation, issue structuring and categorization, topic exploration,
issue prioritization and voting, and logging.
Briggs [Briggs 2002] notes that field studies regularly report that teams using GSS can cut
their labor hours for a project by 50% and cut the calendar days for their project by 70%-
90%. Using a GSS can significantly cut the cognitive load of communication and
deliberation by allowing multiple people to work together to structure their information
26

artifacts, and by allowing simultaneous contributions. Teams can read and respond to one
another’s contributions in real time, regardless of how the team is physically distributed.
2.2.1.2 EasyWinWin: Tool Support for WinWin Requirements Negotiation
Collaboration engineering processes address the problem of having an unmanageable
number of stakeholders by identifying and focusing on stakeholders critical to success.
Collaboration engineering aims to simplify the process for practitioners by giving easy-to-
use, repeatable and predictable techniques for efficiently synthesizing a large set of
stakeholder wants and needs into a workable ser of requirements reached by consensus
[Briggs 2003].
In requirements engineering, stakeholders with different backgrounds, assumptions, and
expectations jointly elaborate the needs for a system. EasyWinWin combines the WinWin
Spiral Model of Software Engineering with collaborative knowledge techniques and
automation of a Group Support System. EasyWinWin is based on the WinWin requirements
negotiation model and the GroupSystems, Inc. Group Support System. It helps a team of
stakeholders to gain a better and more thorough understanding of the problem and supports
co-operative learning about other's viewpoints. Moreover, it helps increase stakeholder
involvement and interaction.
EasyWinWin defines a set of activities guiding stakeholders through a process of gathering,
elaborating, prioritizing, and negotiating requirements. The nominal purpose of the
EasyWinWin methodology is to create an acceptable set of system requirements.
Teams can use EasyWinWin throughout the development cycle to create a shared project
vision, to develop high-levels requirements definition, to produce detailed requirements for
27

features, functions, and properties, COTS acquisition and integration, COTS product
enhancement, and to plan requirements for transitioning the system to the customer and user.
2.2.2 Requirements Definition Support
There are three arguments in support of a systematic approach to requirements engineering.
First one is the ability to control the project by producing standardized maintainable outputs.
Second argument is that once a standardized process is in place it should be possible to
measure the effectiveness of that process and hence to seek ways of improving it. Third one
is that it lends itself to the use of automated aids. Automated tools are considered important
because it is assumed that they increase productivity and reduce administrative costs.
Requirements defects are important to remove, but difficult to detect early. Natural language
is not the best medium for unambiguous communication in order to capture requirements.
Natural language is familiar, but inherently ambiguous and difficult to use effectively.
Critical information in requirements that is missing, incomplete, wrong, and unclear can be
difficult to detect. Differences in interpretation and the resulting requirements defects can be
very expensive. They will be detected later at a much higher cost. Analyzing early and often
would enable stakeholders to detect vague terminology and missing information early.
Because of software requirements specification being central importance, many academic
and practical work concentrates on which techniques to use to write good requirements such
that they can be understood the same way by all stakeholders and transformed into a formal
specification.
28

Specriter [Cook 1990] discusses a structured document generation and processing shell. It
elicited user inputs through a series of context-sensitive screens and tailored the list of
questions to suit the problem at hand. Although it provides some limited consistency
checking and specification in MIL-STD-490A format, it lacks ambiguity checking.
The Requirements Apprentice [Reubenstein 1991] assists a requirements engineer to create a
requirements specification from a set of informal requirements supplied by the user.
However, it does not interact directly with the end-users.
The GMARC (A Generic Model Approach to Requirements Capture) [Bolton 1994] system
transforms an informal set of requirements for an application into a requirements
specification document. Although both of these tools generate a requirements specification
document, they also required skilled requirements engineer to enter information.
The following two approaches are general approaches that cover the activities of
requirements engineering. The NATURE prototype [Pohl 1994] is an automated
specification generation system, which addressed requirements domain theory; requirements
process theory, and requirements knowledge representation theory.
On the other hand, CREWS (Cooperative Requirements Engineering with Scenarios)
[Maiden 1998] has two requirements elicitation and two on requirements validation
components. Requirements elicitation supports structured text presentation of the captured
scenarios and analysis of their contents. Requirements validations allow users to discover
errors in their specifications. The elicitation and validation activities provided by these tools
seem similar to our approach, but our approach will have many checking points where
defects will be captured as early as possible both automatically and by stakeholders. The
29

ESPRIT project CREW, style and content guidelines for textual specification of use cases,
implemented in the CREWS-SAVRE and L’Ecritoire tools, combines natural language
processing (NLP) techniques and linguistic patterns, guiding the construction of use cases
and providing an ambiguity detection mechanisms [Rolland 1998].
The Requirements Counsellor [James 2000] is a dual-use tool to analyze an informal
requirements document and act as a mentor in writing requirements. It acts by identifying
issues to be addressed by the writer and is based upon a collection of rules. However, it
works on an initial requirements document instead of gathering stakeholder inputs and fixing
the problems through specification activity.
The RECOCASE approach uses a CASE tool to assist requirements reconciliation. It starts
with group brainstorming the functionality in the form of a use case diagram with
representatives having viewpoints to log and enter descriptions for use cases in a controlled
language [Richards 2003]. Although brainstorming and use case representation approaches
are similar to our approach, the specification process requires users directly interaction with
the system. On the other hand, we provide some automation to requirements template filling.
Kassel and Malloy’s [Kassel 2003] presents an approach to partially automate the
requirements elicitation and specification processes. Their approach allows all stakeholders
interact directly with the system. Although the tool supports requirements engineers
automatically create a draft requirements specification from stakeholders’ inputs, it doesn’t
help analyze the requirements for completeness and consistency.
TIGER (Tool to Ingest and Elucidate Requirements) [Kasser 2003] is a tool for ingesting
and elucidating requirements based on a set of poor words. This tool scan the wording of the
30

requirement and flag any requirements that are poorly written or do not comply with the
requirements for writing requirements.
Although our approach has some similarities with the above approaches, the main
differences are our process starts directly from the beginning where stakeholders participate
in a requirements negotiation meeting. In addition, the process is supported by a group
support system which allows synchronous and asynchronous contribution to the results. By
the way, the validation process also start earlier than the other approach to remove the
defects as early as possible from the data gathered.
Most of the researches done on requirements specification starts their processes with well-
formed natural language requirements statements. On the other hand, there are some
researches done to remove the ambiguity in the requirements statements. However, the
contribution of our research is that we start to use the techniques as early as possible in the
software development process where stakeholders brainstorm, analyze, and negotiate on the
problem to identify the requirements. Moreover, they continue to use these techniques
further to transform their informal requirements into more structured and qualified
requirements specification by using requirements templates.
31

Chapter 3:
Research Methods
In this chapter, we have been exploring relative strengths of requirements representation
methods, characteristics of requirements engineering intermediate products and alternative
methods for formalizing the informal stakeholder requirements inputs, including natural
language processing, keyword analysis, template-based refinement, formal methods
expertise, and inspections. The section summarizes our analysis of these methods.
3.1 Level of Formality – Representation Methods
Developing software is an evolutionary process that adopts informal, semi-formal, and
formal representations of knowledge. Managing the transitions between these
representations is a key to the success of any engineering task. Each of these representations
offers some unique advantages. Informal representations like natural language are user-
oriented. They are well known, since they are being used in everyday life. Informal
representations for capturing system requirements support straightforward involvement and
interaction of even inexperienced stakeholders. On the other hand this approach may result
all kinds of requirements freedom such as inconsistency, incompleteness, ambiguity [Balzer
1978; Feather 1991]. Semi-formal and formal representations overcome these problems but
are less suited for stakeholder interaction.
32

Our analysis of negotiation results concludes that an approach supporting the formalization
of informal EasyWinWin inputs should address both quantity and quality aspects: we need
(1) scalable techniques addressing the size and complexity of negotiation results and
expediting the refinement into a more formal requirements specifications, and (2) techniques
helping to identify and remove defects from the negotiation results early on while product
complexity is still manageable.
Our first challenge was to determine an appropriate degree of formality to serve as the initial
target for methods of strengthening informal requirement inputs. In surveying requirement
practices among University of Southern California’s industry affiliates, we found four
primary categories of formality:
Formal Specifications: Mathematically precise specifications with completely
unambiguous semantics. Examples are Larch [Guttag 1993], Vienna Development Method
(VDM) [Jones 1986] and Z [Spivey 1992].
Formatted Specifications: Specifications whose syntax is often precisely defined, but
which allow the use of imprecise terms and relations within formatted requirements
statements. Examples are the Unified Modeling Language [Rumbaugh 1999], RDD-100’s
Requirements Specification Language [Alford 1985], Volere [Robertson 1999] and the
MBASE SSRD Guidelines [Boehm 2002].
Itemized Statements: Natural language specifications in which each individual requirement
is given a unique identifier. Examples are the requirements Data Item Descriptions in
government and commercial standards such as MIL-STD-498 and IEEE/EIA-J-STD-016.
33

Stories: Colloquial descriptions of desired capabilities used to build up a shared
understanding between clients and developers. The best-known examples are the stories used
in Extreme Programming [Beck 2000].
Each representation method has advantages, disadvantages, and a variety of tools for
working with it. However, the most important to work with this map is the human mind.
That’s why the most important quality of map is that everyone involved should be able to
understand it.
Each of these approaches has been found useful to some constituencies. Table 1 shows the
results of our analysis - an extension of the analysis in [Boehm 1984] - to compare the
relative strengths of these requirements representation methods with respect to five criteria
considered important among these constituencies. The ratings for support were made on a
scale of zero to four stars: 0-weak; 1-modest; 2-intermediate; 3-strong; 4-very strong.
Table 1: Relative Strengths of Requirements Representation Methods
Precision Closure,
Consistency
Checking
Time, Cost
to Develop,
Modify
Non‐
Expert
Usability
Scalability
Formal
Specification
**** ****
Formatted
Specification
** *** ** *** ***
Itemized
Statements
* *** **** ***
Stories
**** **** **

34

As seen in Table 1, no method dominates the others on all the criteria. Formal specifications
are very strong on precision and closure/consistency checking, but weak on the other three
criteria. Stories have almost the opposite profile, except that both formal methods and stories
have difficulties with scalability. The strongest method across all five criteria was formatted
specifications. For this reason, we chose it as the initial target to use in strengthening
informal requirements inputs (see Figure 4).
High
Low
Low High
F o rm al S pecifications
F o rm atte d S p ecificatio n s
Ite m ized S tatem ents
Stories
R a pid M odifia b ility
Precision, Checking

Figure 4: Requirements Representation Rapid Modifiability – Precision Tradeoffs
Using formatted specifications method eliminates many testability and ambiguity problems
because the language forms help prevent ambiguous terms and vague generalities.
Automated systems also have less of a problem in checking for additional clerical errors
introduced in iterating and retyping a specification.
35

3.2 Characteristics and Problems of Requirements
Work Products
This section provides the information about the characteristics and typical problems related
with the work products (stakeholder statements, individual requirements, and a software
requirements specification) generated during the requirements engineering process.
3.2.1 Typical Problems for Statement
Table 2 shows a list of typical problems of stakeholder statements [James 2000]. Some
solutions for these problems provided in order to allow automatic checking during the
activities.
Table 2: Typical Problems for Statement
Typical Problem Definition Solution
Incomplete
statement
The information needed to clearly specify
it may not be available at the time of
writing
Identify them early using a
feedback loop
Parameterized
statement
Contain imprecise design parameters or
posses poorly specified parameters that are
liable to misinterpretation
Provide exact values for the
parameter to measure
Unclear statement
Contain words or phrases that introduce a
degree of ambiguity into the text
Identify ambiguous words
such as adjectives, adverbs for
further analysis
Statement size
Physical size of a statement is an
important factor in understandability
Provide not too short but also
simple sentences
Composite
statements
Contain more than one things Identify the different things in
it and separate them as
individual statements

36

Table 2: Continued
Typical Problem Definition Solution
External reference
Reference to external documents or
standards and the implications of those
references is often omitted or ignored
Add descriptions of external
documents or standards as a
keyword into the glossary of
term
Domain specific
terms
Certain topics and areas that always arise
of concern or are known to be difficult to
analyze
Add domain specific words or
phrases with their definitions
into the glossary of term
Negative statement
Express in the negative terms of what the
system must not do
Eliminate negative statements
or rewrite them as positive
sentences
Unusual
terminology
Contain words or phrases that are not
commonly use in everyday speech
Add these words with
definitions into the glossary of
term
Acronyms &
Abbreviations
Shortcuts often have different meaning
across cultures and domains
Eliminate using them or add
them into the glossary of term

3.2.2 Properties for a Good Requirement
In order to have a successful project, the first step is to write good quality requirements.
Table 3 lists the properties of a good requirement [IEEE 1998]. These properties can be used
during the requirements validation activity to check if requirements satisfied required
properties.

37

Table 3: Properties for a Good Requirement
Property Definition
Unambiguous
Stated in such a way so that it can be interpreted in only one way, specify
only one thing, all parts of the requirements belong together
Complete
All of its parts specified in its template or content or format standard are
present and each part is fully developed.
Correct
Accurately describe the functionality of the system to be built
Consistent
Its details do not conflict with each other
Traceable
Should be oriented around the needs of the customers and users
Feasible
The life‐cycle benefits of the system specified exceed its life‐cycle costs
Testable
Identify an economically feasible technique for determining whether or not
the developed software will satisfy the requirement
Prioritized
Identify the importance of a requirement for the success of the product
Relevant
Within the scope of the business, application being specified

Table 4 shows a list of typical problems of requirements. Some solutions for these problems
can be used to automatically check and highlight the defects in the requirements.

38

Table 4: Typical Problems for Requirement
Property Typical Problem Definition Solution
Unambiguous
Ambiguous terms Has inherently or potentially
ambiguous words
Include term in a glossary where its
meaning is made more specific
Irrelevant information Parts that provide no value to the
meaning of a requirement
Remove irrelevant information not
related with a requirement
Subjective meaning Not all stakeholders' need Eliminate a requirement where
there is no consensus
Composite
requirements
A requirement contain more than one
thing
Split requirement into more than
one simple requirements
Complete
TBDs Places in the requirement where
decisions have been postponed by
writing "To be Determined"
Replace TBDs with more
meaningful comments
Missing information Requirement self contained with
missing information
Use a template structure to check
for missing information
Nonexistent references References in the requirement to
functions, inputs, or outputs not
defined in the requirement
Use appropriate terms in each part
of the requirement details
Correct
Semantically incorrect Do not meet all or part of a need from
stakeholder(s); do not have correct
values

Syntactically incorrect Do not use standard format; do not
properly use words; do not have
correct spelling or grammatically
correct
Highlight potentially ambiguous
words and provide a template
structure for assistance
Consistent
Internal consistency Items within the requirement do not
conflict with each other
Use same terms inside the
definition of requirement
Traceable
Missing reference Do not be traced back to one or more
stakeholders' needs
Add reference to its source
Feasible
Too general
constraints
Do not estimate the feasibility of a
requirements with the given
constraints
Identify the ease of
implementation value of the
requirement
Testable
Not measurable; not
testable
No measurable data or range to test
non‐functional requirements; no
steps of actions to test capabilities
Provide measurable and easy to
follow steps for testing
Prioritized
Missing priority No indication about the return when
this requirements implemented
Identify the importance of
requirement
Relevant
External information Behavior and characteristics of the
associated external systems
Scope the boundary of the project

39

3.2.3 Characteristics for a Good Requirements Specification
Table 5 lists the characteristics of a good software requirements specification
(SRS) document with their definitions [IEEE 1998].
Table 5: Characteristics for a Good SRS
Characteristic Definition
Correct
An SRS is correct if, and only if, every requirement stated therein is one that the
software shall meet.
Unambiguous
An SRS is unambiguous if, and only if, every requirement stated therein has only one
interpretation.
Complete
An SRS is complete if, and only if, it includes the following elements:
• All significant requirements, whether relating to functionality, performance,
design constraints, attributes, or external interfaces
• Definition of the responses of the software to all realizable classes of input
data in all realizable classes of situations
• Full labels and references to all figures, tables, and diagrams in the SRS and
definition of all terms and units of measure
Consistent
An SRS is internally consistent if, and only if, no subset of individual requirements
described in it has of the following conflicts:
• The specified characteristics of real‐world objects may conflict
• There may be logical or temporal conflict between two specified actions
• Two or more requirements may describe the same real‐world object but use
different terms for that object
Ranked for
importance
and/or stability
An SRS is ranked for importance and/or stability if each requirement in it has an
identifier to indicate either the importance or stability of that particular requirement.
Verifiable
An SRS is verifiable if, and only if, there exists some finite cost‐effective process with
which a person or machine can check that the software product meets the
requirement.
Modifiable
An SRS is modifiable if, and only if, its structure and style are such that any changes
to the requirements can be made easily, completely, and consistently while retaining
the structure and style.
Traceable
An SRS is traceable of the origin of each of its requirements is clear and if it facilitates
the referencing of each requirement in future development or enhancement
documentations.

40

Table 6 shows a list of typical problems of a Software Requirements Specification
document. Some solutions for these problems can be used to automatically check and
highlight the defects in the requirements.
Table 6: Typical Problems in an SRS
Characteristic Problem Solution
Correct
No source
reference
Each requirement explicitly referencing its source in earlier
documents
No standards in
writing
requirements
Compare SRS with any applicable specifications, and with other
applicable standards
Unambiguous
Missing glossary of
term
Include term in a glossary where its meaning is made more
specific
Natural language
pitfalls
An independent party review to identify ambiguous use of
language
Use requirements specification languages
Use representation tools to state the requirements with their
natural language descriptions
Complete
Missing
requirement
Any external requirements imposed by a system specification
should be acknowledge and treated
Missing data Specify the responses to both valid and invalid input values
Missing label,
reference or
definition
Specify labels, references to figures, tables, and diagrams and
definition of all terms
Use of TBDs Describe the conditions causing the TBD, what must be done to
eliminate it, who is responsible for its elimination, and by when
it must be eliminate
Consistent
Use different
formats
Describe all requirements in same output format (i.e., tabular)
Conflicted
information
SRS should be reviewed by an independent party to identify
conflicted actions so that it can be corrected
Use different terms
for an object
Eliminate multiple terms having the same meaning and use
standard terminology and definitions
Ranked for
importance
and/or stability
Missing priority Prioritize each requirement to make the differences clear and
explicit
41

Table 6: Continued
Characteristic Problem Solution
Verifiable
Ambiguous
requirements
Use concrete terms and measurable quantities
Modifiable
Missing table of
content
Have a coherent and easy‐to‐use organization with a table of
contents, and index, and explicit cross‐referencing
Redundant
requirement
Eliminate redundancy
Compound
requirement
Express each requirement separately
Missing reference When redundancy is necessary, the SRS should include explicit
cross‐references to make it modifiable
Traceable
Missing backward
traceability
Each requirement explicitly referencing its source in earlier
documents
Missing forward
traceability

Each requirement in the SRS have a unique name and reference
number
When code and design documents modified, it is essential to be
able to ascertain the complete set of requirements that may be
affected by those modifications

3.3 Gap-Bridging Methods
We have been using EasyWinWin to capture informal requirements from stakeholders in an
annual series of 15-20 University of Southern California (USC) electronic services projects.
In the context of these projects, we have been exploring alternative methods for formalizing
these informal requirements inputs, including natural language processing, keyword
analysis, template-based refinement, formal methods expertise, and inspections. The section
summarizes our analysis of the relative strengths and difficulties of using these methods.
Our search for ways to improve this situation has involved a comparative analysis of
alternative approaches:
42

3.3.1 Template-Based Refinement
The idea of using templates for expressing requirements is based on the use case templates
by Rumbaugh [Rumbaugh 1999] and Cockburn [Cockburn 1997]. Other similar works are
the Volere Requirements Specification template [Robertson 1999] and the User
Requirements Document Template developed at CERN [CERN 1998].
The most essential, yet often neglected, requirements engineering key practice is to write
down the requirements in some accepted, structured format as stakeholders gather and
analyze them. To minimize the effort and enhance readability, it is advisable to use a
standard document format or requirements specification template, to capture textual
information about each requirement.
Requirements templates help to express requirements. Requirements information is
structured in a fixed form, so requirements engineers know what missing information must
be searched and reuse is promoted. In addition, filling blanks in pre-written sentences is
easier and faster than writing a whole paragraph saving what the system is expected to do.
Moreover, requirements templates can be reused with some adoption to specific
development.
Organizations that use requirements templates help in the validation of the requirements by
inducing the analyst to provide more complete information.
3.3.1.1 Human-Initiated Template
The requirements engineers detail the textual properties of each requirement. There are many
usage of this type of template such as use case template, Volere software requirements
43

template, and MBASE SSRD templates. Most of them are documented using either word
processing or requirements management tools. On the other hand, human-initiated templates
can be used in any domain [Robertson 1999].
3.3.1.2 Computer-Initiated Template
Computer-initiated template approach seems a futuristic expectation as the requirements
engineering activities heavily depends on stakeholders’ interaction and communication.
However, requirements specification can be analyzed and similar patterns for requirements
related in a domain can be extracted and used in later projects. Although, fully automatic
computer-initiated template is not applicable, partially filled templates will provide real help
to the requirements engineers in producing requirements for a project.
A way in our approach that we are trying to achieve is having a computer program operates
on the EasyWinWin data to produce draft templates. Moreover, Duran et. al [Duran 1999]
uses an approach based in templates and patterns where requirements elicited and expressed
with a CASE tool.
3.3.2 Natural Language Processing (NLP)
In the process of software development, requirements engineering is important as well as the
users' participation in the specification of problems, solutions and requirements. Detailed
software requirements need to be written in a form that is understood by both the customer
and the development team. Using the customer's language to describe these software
requirements is most effective in gaining their understanding and agreement. That’s why the
language that has to be considered is a natural language. Natural language is widely used in
industry to state requirements for all types of systems, because it is flexible and universal. A
44

recent study shows that several software development companies use common natural
language for specifying requirements in the early phases [Mich 2004].
Natural language is important because RE is largely about communication. Natural language
processing have changed the way in which the English language is used in specifications, for
instance to avoid ambiguity and to improve understandability. NLP is concerned with the
development of computer-based applications whose utility derives from their use of
knowledge about language [Burg 1997].
Although documents written in natural language are often hard to process automatically and
inconsistency is difficult to detect, NLP techniques and tools can be used to extract template-
relevant meaning from the stakeholder expectations to achieve a higher level of
understanding. Moreover, to reduce ambiguity and vagueness in use cases written in plain
natural language the use of a controlled natural language is proposed.
Several specific natural language processing (NLP) techniques have been tailored to the
purpose of analyzing and controlling software requirements. Some of these approaches and
tools are as follows:
• Saeki et al. [Saeki 1989] proposes restricted natural language processing
requirements ideas to get specifications.
• Macias and Pulman [Macias 1993] propose the application of NLP techniques to
requirements documents in order to control the vocabulary used, which must be
fixed and agreed upon, and the style of writing.
45

• Newspeak tool [Osborne 1996] uses natural language processing (NLP) techniques
to aid the development of formal descriptions from requirements expressed in
controlled natural language.
• CIRCE tool [Ambriola 1997] is used to build (semi-) formal models in an almost
automatic fashion by extracting information from the NL requirements.
• Abstfinder [Goldin 1997] is a prototype natural language text abstraction finder for
use in requirements elicitation. The technique proposed is restricted to a strict lexical
analysis of the text.
• Mich and Garigliano [Mich 2000] propose a set of metrics for syntactic and
semantic ambiguity in requirements based on the use of information on the
meanings and roles of the words within a sentence.
• Scott and Cook [Scott 2004] describes a context-free grammar that defines
requirements language and its associated data model to support automatic reasoning
to create, compare, and assess requirements.
In the automation of requirements verification process, there are some proposals based on
NLP like Fabbrini et al. [Fabbrini 1998]. The usual goals of NLP when applied to RE are to
know the used vocabulary, the writing style, detecting ambiguity (degree of syntactic and
semantic uncertainty of the sentence), the information conveyed by requirements,
discovering under-specifications, missing information and unconnected statements.
NLP is also adaptable to use case description verification. For example, Fantechi et al.
[Fantechi 2002] present a set of metrics to quality evaluation of use cases. A use case is seen
46

as a set of sentences with an underlying template for which metrics such as the average
number of words per sentences or the average of sentences containing acronyms not
explicitly and completely explained can be controlled in order to perform a quantitative
evaluation of a requirements document.
3.3.3 Keyword Analysis
A keyword analyzer can be used to produce summary information to facilitate specification
development. Specific words and phrases can be identified and searched in the requirements
document for different purposes (e.g., checking the quality of document, defect detection,
idea grouping, etc.). It is also easy to expand the keyword lists and the classification of the
words and phrases into the different categories for analysis.
Several researches have been done by using this method as the following examples show:
• Automated Requirements Measurement (ARM) [Wilson 1997] is a tool to discuss
overall quality aspects of requirements specifications and requirements in general. It
supports of management, assessing the structure of the requirements document, the
structure of individual statements and the vocabulary used to state the requirements.
It analyzes the requirements by browsing through the document and sums those
words and phrases indicate that statements are weak or strong.
• Percept - Requirements Counsellor [James 2000] describes the concept that provides
early feedback on the perceived goodness of a set of requirements during
requirements elicitation process using pattern-matching techniques for identifying
poorly phrased or inadequate requirements.
47

• Quality Analyzer for requirements specification (QuARS) tool [Fabbrini 2001] is
based on the quality model composed of high-level quality properties to evaluate
natural language requirements by means of syntactic and structural indicators. The
indicators are collected into specific dictionaries that contain terms and linguistic
constructions characterizing a particular defect, which are detectable by analyzing
the requirements.
• First Requirements Elucidator Demonstration (FRED) [Kasser 2004] acts as an
extension to a spelling and grammar checker. Particular “poor words” have been
identified that are indicative of potential errors in the requirements and these are
reported for further examination.
3.3.4 Formal Methods Expert
A formal method in software development is a method that provides a formal language for
describing a software artifact such that formal proofs are possible, in principle, properties of
the artifact so expressed. Formal methods support precise and rigorous specification of those
aspects of a computer system capable of being expressed in the language. Using
specification written in a formal language to complement natural language descriptions can
make the specification more precise. Developers, who use formal methods, have developed
tools to interactively capture a user’s informal understanding and thereby develop a formal
specification [Zeroual 1991].
Formal methods can be particularly useful during the early stages of software engineering,
and enable the software developer to discover and correct errors that otherwise might go
undetected, increasing the quality of the software, while decreasing its failure rate. Formal
48

methods have been applied to many industrial software domains and their use and adoption
in industry is getting momentum [Bjorner 2000].
Requirements engineers can write formal specification by using unambiguous and provable
mathematical notations to describe the requirements. In addition, formal specifications are
extremely useful in identifying inconsistencies in requirements specifications. However, it
requires experts to refine the appropriate template elements into formal specifications before
tools can be used to analyze them.
Direct use of formal methods in eliciting requirements and in discussing them with
stakeholders poses serious usability problems [Le Charlier 1998].
3.3.5 Inspections
Inspection is an important aspect of software quality assurance. The goal of inspection is to
detect ad correct software defects earlier in the development cycle. Software inspection is an
industry-proven process for improving software product quality and reducing development
time and cost. In system development, the exact cost of error removal is impossible to
assess. It is generally expected that for every hour spent in walkthroughs, three hours are
saved in testing; for every hour in inspection, five hours are saved in testing [Ackerman
1989].
Formal technical reviews (inspections, walkthroughs, and technical reviews) are a method of
removing defects at the requirements phase where they are introduced. The objective being,
for the stakeholders, to detect errors or potential problems as early as possible in the system's
49

description to ensure development proceeds in the right direction and meets the needs of the
business.
Checklists for work products (e.g. requirements, and design specifications) are typically lists
of issues that should be analyzed to ensure consistency, correctness, and completeness. The
primary purpose of the checklists is to provide the reviewer with hints and recommendation
for finding defects.
The Perspective-Based Reading technique supports the identification of defects from the
viewpoint of those stakeholders who will use the artifacts being inspected. It does this by
providing scenarios that help explain what to look for in order to find potential defects from
that particular perspective. The scenario helps the reviewer verify completeness, correctness,
and understandability of the artifacts under review.
3.4 Evaluation of Gap-Bridging Methods
We have analyzed each of these alternative approaches with respect to five criteria that we
consider highly important: Required human resources, Available technology, Generality,
Scalability, and Precision. As with the ratings of requirements representation methods, the
bridging approaches are rated on the same scale of zero to four stars in terms of their support
in achieving the criteria. The results of the analysis are summarized in Table 7.

50
Table 7: Evaluation of Gap-Bridging Methods
Required Human
Resources
Available Technology Generality Scalability Precision
Human‐
Initiated
Template
**
Template‐building and refining
process is slow, labor‐intensive
****
Can be used with formatted
specifications. Strong tool support
[Robertson 1999, Nikula 2000]
****
Can be used for any domain
[Robertson 1999]
**
Feasible for any size, but with
diseconomies of scale
[Robertson 1999, Nikula 2000]
**
Builds a good basis, but
introduces some
misinterpretations and
defects
Computer‐
Initiated
Template
**‐***
Some effort required for post‐
processing entries
*‐**
Currently infeasible to fully inter
meaning from text. Some domain‐
model checking feasible for narrow
domains
*‐**
Some entries feasible (e.g.,
priorities) others only
feasible for narrow domains
*‐**
Weak for large complete
solution, partial solution
scalable
*‐**
End results depend on
human expertise in post‐
processing entries
Natural
Language
Processing
**‐***
Depends on pre‐ and post‐
processing human resources.
Best in narrow, mature
domains
*‐**
Currently infeasible to fully inter
meaning from text. Some domain‐
model checking feasible for narrow
domains [Rolland 1992, Nanduri 1996]
*
Only feasible for mature,
narrow domains with
restricted vocabularies
[Macias 1993]
*
Weak for large specs, broad
domains, large vocabularies
*‐**
End results depend on
human expertise in post‐
processing entries
Keyword
Analysis
**
Preprocessor could help focus
on common terms, synonyms
[Wilson 1997]
****
Numerous keyword analysis packages
available [Wilson 1997]
***
Less valuable in domains
with rapidly changing
vocabularies
*_***
Processing scalability is
strong. Output value
decreases with size, breadth of
domain
*
End results limited,
depend on human
expertise in post‐
processing entries
Formal
Method
Experts
*
Formal method experts scarce.
Would also have to consult
domain experts [Hall 1990]
**
Formal spec languages available with
moderate tool support [Guttag 1993,
Spivey 1992]
***
Available to most domains.
Harder to formalize levels of
service
**
Formal method experts
scarce. Larger specs harder to
formalize [Hall 1996]
****
Experts produce most
precision in specs [Hall
1990]
Inspections
**
More people involved early, but
with effort savings later. Some
effort to post‐process into
template [Basili 1996]
****
Mature practices. Special techniques
such as perspective‐based reviewing
effective [Fagan 1976, Basili 1996]
****
Can be used for any domain
**
Feasible for any size, but with
some diseconomies of scale
***
Produces strong‐shared
vision, earlier defect
elimination, reduced
reword [Halling 2003]
51

As in the analysis of requirements representation methods, no approach dominates all of the
other approaches with respect to all of the criteria. This suggests that hybrid combinations of
the approaches will be attractive. For example, inspections could be combined with
computer-initiated templates and NLP.
Both the inspections and human-initiated template approaches are fairly strong across all the
criteria. Inspections provide some comparative advantages in early defect reduction, reduced
rework, use in avoiding misinterpretations, and use in early elaboration of the stakeholders’
shared vision of the proposed system.
Some shortfalls of inspections (e.g., extra post-processing effort to convert the inspection
results into formatted specs) could be reduced via hybrid approaches. For example,
computer-initiated template could be generated and used as the artifacts to be inspected,
ensuring that the inspection fixes would yield formatted specs directly. Keyword analysis
could be applied as a generator of useful subsidiary artifacts such as lists of elements
including common terms and word-association diagrams. Formal methods could compatibly
be applied for specs needing high precision. Natural language processing has limited
applicability in its current state, but can be valuable for domain - specific model checking in
such mature and focused domains as telecommunications or aircraft control.
Overall, the analysis indicates that hybrid methods have promise as a basis of improving
over current human-initiated template approaches to bridging the pre-requirements to
requirements gap. We are now experimenting with some initial hybrid approaches.
52

3.5 Hybrid Options Exploration
Inspecting requirements is the most effective way to identify ambiguities, unstated
assumptions, conflicting requirements, and other defects at the earliest point in the software
development life cycle. Although inspections is one of gap-bridging approaches, inspection
alone doesn’t remove the gap; instead it improves the quality of the results for better
requirements specification by removing the defects in the statements and helping in
formalizing these statements to some extent. Therefore, inspections can be used with the
other approaches as part of a hybrid method.
Human-initiated template with inspections approach is another hybrid method used in
software development. Yet it is time-consuming to create the template and perform the
inspection process manually, it is better to have small software projects instead of large
software projects.
Another hybrid method is using formal method experts together with human-initiated
template where experts can formalize the statements during requirements specification. This
is also time-consuming regarding to experts formalizing requirements manually. In addition,
formal methods are not widely used for all kinds of project except safety-critical and highly
complex systems because of their required human resources and cost.
An alternative hybrid method may use computer-initiated template to store the requirements
that are extracted from the EasyWinWin results using NLP. NLP techniques provide
requirements elicitation, conflict identification, control and analysis of requirements and
translation of natural language requirements into formal or semi-formal specification
language statements to some extent during the requirements specification. The way that we
53

propose to use these techniques is: NLP can be used to analyze the valuable data gathered
from USC projects and use it in categorizing the results for producing requirements template
manually. This hybrid method can reduce the size of human resources required to input the
information directly from the negotiation results into the requirements template.
Another alternative hybrid method is the combination of computer-initiated template
produced from the negotiation results, and formal methods for some type of the requirements
(e.g., system capability requirements). In addition NLP can be also used as part of this
hybrid method for improving the quality of requirements specification.
54

Chapter 4:
Acquiring Informal Stakeholder
Requirements Inputs
4.1 The EasyWinWin Negotiation Process
The input to an EasyWinWin workshop is typically a mission statement outlining the high-
level objectives of a project and another statement specifying the negotiation purpose. In
each activity in this process the team adds details and increases precision. The EasyWinWin
process inputs and outputs are shown in Figure 5.

Figure 5: EasyWinWin Products with Important Lifecycle Deliverables

55

The outcome is a set of well-defined deliverables, more specifically (1) the topics of a
negotiation organized in a domain taxonomy, (2) a glossary with definitions of key project
terms, (3) a set of agreements providing the foundation for further refinements and plans, (4)
open issues addressing constraints, conflicts, and known problems, as well as (5) decision
rationale showing the negotiation history (comments, win conditions, issues, options, etc.).
EasyWinWin helps identifying risks by having stakeholders assess the relative value and
difficulty of achieving a given win condition. High-risk win conditions have either uniformly
high difficulty ratings or a lack of consensus on their ratings. EasyWinWin is also used to
prioritize features for defining the core capability in the risk-driven SAIV (Schedule as an
Independent Variable) process model. Prototypes are developed concurrently with
EasyWinWin negotiations to reduce the risk of misunderstanding system requirements.
Major results of the negotiation process are a list of agreements and a list of unresolved
issues (e.g., caused by stakeholder dissent) that have to be managed as potential project
risks. Agreements of success-critical stakeholders are input to the project contract and to
refinement during requirements engineering activities. The WinWin tree shows how
agreements and open issues can be traced back to stakeholder win conditions.
The EasyWinWin process is comprised of the following activities (see Figure 6):
56

Figure 6: EasyWinWin Requirements Negotiation Activities
4.1.1 Review and Expand Negotiation Topics
Stakeholders often enter a requirements negotiation with fuzzy and limited expectations and
understandings of what can and should be done. This team activity tries to broaden their
individual perspectives by asking them to elaborate, refine, and customize an outline of
negotiation topics. Stakeholders suggest modifications to the taxonomy of negotiation topics
to reflect their own interests and culture.
This taxonomy of topics serves as both an organizing framework and a stakeholder checklist
for WinWin negotiations (see Appendix A). It becomes a useful way to organize the
hundreds of artifacts that emerge later in the process. This taxonomy consists of project
requirements (cost, schedule, development tools, support, etc.), system capability
57

requirements (features and services), interface requirements (to the user and to other
systems), level of service requirements (‘non-functional’ aspects), and evolution
requirements (most likely directions of system change and growth) [Boehm 1999; Robertson
1999].
4.1.2 Brainstorm Stakeholder Interests
Stakeholders exhaustively explore their interests in the project using an electronic
brainstorming technique. They make contributions to a series of electronic pages that swap
randomly among their screens. This rapid and simultaneous interaction allows sharing
different opinions and perspectives. Stakeholders make use of the taxonomy developed in
the preceding step and try to identify goals for all identified negotiation topics to explore
also less understood areas. Sessions typically last between 30 and 60 minutes and between
100 and 300+ statements are collected. As contributions are anonymous at this point, people
reveal interests that they might be reluctant to discuss in an identified brainstorming session.
The resulting collection of stakeholder statements and ideas provides a starting point for
elaborating win conditions and defining important terms of the domain.
4.1.3 Converge on Win Conditions
Brainstorming comments from stakeholders are usually unstructured, redundant, ambiguous,
and often vague. The goal of this activity is to jointly develop a list of clearly stated,
unambiguous win conditions by considering all ideas contributed in the brainstorming
session. Win conditions are elaborated jointly to make sure they are understood by all
participating stakeholders and easily communicable to others. The challenge is not to miss
any important ideas and at the same time to weed out pointless brainstorming contributions.
58

Typically, several brainstorming statements are merged into one win condition. However, if
a statement covers several aspects (e.g., it describes a system service and a system property),
it may be split into several win conditions. The group is explicitly prohibited from arguing
with or endorsing win conditions at this time. Stakeholders also organize these win
conditions into categories representing the major negotiation topics. Win conditions shall fit
the associated topics in the taxonomy and their level of detail should match the overall
negotiation purpose.
4.1.4 Capture a Glossary of Terms
Defining a glossary of project terms is a key prerequisite for all subsequent process steps. As
participants brainstorm, they use words that have special meanings within the context of a
project. The facilitator adds important terms to a shared list if requested by a stakeholder.
The groupware tool then automatically organizes brainstorming comments containing these
keywords (or synonyms thereof) on sheets showing how exactly a certain term is used in
different statements or contexts. Stakeholders use this information to create and jointly
review definitions for these terms. Typically there are several rounds of reading and refining
the definitions, but we found the time spent is worthwhile to reduce risks stemming from
miscommunication.
4.1.5 Prioritize Win Conditions
Polling in EasyWinWin is used to determine priorities of win conditions and to reveal
conflicts and mismatching perceptions among stakeholders. Stakeholders rate each win
condition for each of two criteria: Business importance shows the relevance of a win
condition to project success; feasibility indicates perceived technical or economic constraints
59

of implementing a win condition. Developers typically focus on technical issues, while
clients and users concentrate on the business relevance. Win conditions are automatically
grouped in one of four categories: low hanging fruits (high importance, low expected
difficulties), important with hurdles (high priority, difficult to realize), maybe later (low-
priority, easy to realize), and forget them (unimportant, difficult to achieve).
4.1.6 Reveal Issues and Constraints
Stakeholders also examine the results of the prioritization poll and analyze patterns of
agreement and disagreement. The groupware system displays items with high consensus in
green, and items with low consensus in red. The facilitator shows a graph of voting patterns
for any red item, and asks the group to speculate why the disagreement exists. As
stakeholders explain why opinions may have differed, they discover and correct ambiguity in
their win conditions. They surface unspoken constraints, unrealized assumptions, and
unshared information. These items are recorded as comments, candidate issues (and
sometimes options) for the win condition under discussion.
4.1.7 Identify Issues and Options
Conflict can be characterized as disagreement among the stakeholders of the requirements
and this disagreement may lead to inconsistencies in the specifications. Conflict
identification and resolution in the WinWin negotiation model is based on capturing Issues,
Options, and Agreements. Stakeholders identify these artifacts in several iterations and
organize them in a group-outlining tool.
60

The facilitator first encourages the team members to read each win condition. If it raises any
issue the stakeholders capture a candidate issue for the win condition. The team converges
on the issues for each win condition by analyzing the collected candidate issues. The
facilitator then encourages the stakeholders to read each issue. If the stakeholders can think
of any options for addressing an issue, they may enter a candidate option for the issue. The
team again converges on the options for each issue by analyzing the collected candidate
options. Participants are discouraged from arguing about issues or options in this phase. The
resulting deliverable is called the WinWin Tree. It contains all win conditions, some of which
will have issues as subheadings, some of which will have options as subheadings.
4.1.8 Negotiate Agreements
Win conditions for which no issues have been raised are automatically declared agreements.
The group must negotiate a resolution to every issue in the WinWin Tree. Often someone in
the team has already proposed an option that can be used to resolve the issue. These options
typically become agreements.
Other issues must be negotiated by the old-fashioned way - horse-trading, persuasion,
lobbying, inventing new options for mutual gain, or give-and-take. However, because the
lead-in process tends to be exhaustive, the discussion can be focused, and the available
trade-offs are often explicit. Because stakeholders are likely to have several automatic wins
early in the process, they tend to be willing to make trade-offs with one another. The group
continues to work with the goal to achieve WinWin equilibrium (i.e., all win conditions and
options are covered by agreements and there are no outstanding issues). The resulting
61

WinWin tree shows how agreements emerge in a negotiation process and captures the
decision rationale.
4.1.9 Check Completeness
In this step we tag all the WinWin artifacts with one or more negotiation topics. The goal of
this step is to determine if all identified negotiation topics have been sufficiently addressed.
After this step, the team reflects on each negotiation topic to decide whether any win
conditions, issues, or options are out of place, and whether any artifact needs to appear in
more than one category. An empty category indicates that a negotiation topic has not been
explored thoroughly during the negotiation and may need to be further explored. This
reviewed and expanded negotiation topics where each stakeholder win-win artifacts are
categorized then used as the outline for requirements specification document.
The result of a WinWin negotiation is typically not a complete, consistent, traceable, and
testable requirements specification. For example, stakeholders might become enthusiastic
about proposed capabilities and ratify idealistic agreements such as “anytime, anywhere”
service. Rather than dampen their enthusiasm with a precise wordsmithing exercise, it is
better to have a facilitator post-process such agreements into more precise and realistic
requirements for the stakeholders to review and iterate. Another approach to improve the
quality of the negotiation results is to review them based on defect types and eliminating
those defects.
62

4.2 Typical Defects in Requirements Negotiation
Defects in a requirements negotiation can appear on the statement level or on the negotiation
level. Typical faults we experienced are vague or ambiguous statements, missing
information, wrong level of detail, or inconsistencies. All defects have to be interpreted with
respect to the defined negotiation purpose, which states the context and the desired level of
detail.
4.2.1 Statement-Level Defects
Negotiation artifacts are statements written in natural language and therefore error-prone.
Table 8 shows some examples of defects that can we identified in individual statements:
Table 8: Statement-Level Defects (Example)
Statement Defect Type Defect Description
Win condition: List search results in
alphabetical order
Unclear terms /
statement or missing
information
Unclear by which fields search
results should be sorted
Glossary definition: ISBN is the
abbreviation of International Standard
Book Number. Every journal has a
unique ISBN
Incorrect statement Journals have an ISSN (unlike
books)
Win condition: User interface should be
simple and straightforward
Unverifiable
statement
This statement is not measurable
and testable
Win Condition: The administrator is
responsible for changing data formats
Ambiguous term The term administrator is
ambiguous, as different types of
administrators exist in this context
(e.g., sys admin, db admin)

63

4.2.2 Negotiation-Level Defects
A challenge of the EasyWinWin process lies in understanding a large number of interrelated
artifacts and their relation to the overall negotiation purpose. The quality criteria
completeness and consistency relate the negotiation results to a set of expectations (what
should be in the negotiation results) and span multiple statements. A typical severe defect is
the incomplete coverage of the negotiation purpose statement or the agreed negotiation
topics (see Table 9).
Table 9: Negotiation-Level Defects (Example)
Statement Defect Type Defect Description
Win condition: Non‐fulltext journals'
information will not be in the journal
title searchable database (categorized as
a system capability).
Incorrect relationship
of statement to topic
This is not a system capability but
a goal describing the intended use
of the system.
Win condition: Use tool X to build the
[…] database.
Inconsistency Conflict with overall project
constraint that tool Y should be
used.

4.3 Quality Assurance Techniques for EasyWinWin
An EasyWinWin negotiation results in a significantly higher number of artifacts compared
to traditional paper- or blackboard-based approaches. Due to this size and complexity
systematic quality assurance techniques become even more important because defects might
ultimately cause even more defects in the final product. Although the impact of a defect in
the pre-requirements is typically rather minor and local initially, it can become more serious
in later phases, since more rework is necessary and more people are involved to fix the
64

defects. For example, an ill-defined capability defect that can be easily fixed during
requirements negotiation could become a major problem if it cannot be realized with the
chosen system architecture. Consequently, before refining the negotiation results to other
life-cycle artifacts like contracts, specification, project plans, or architectural models defects
should be eliminated to reduce both the effort and probability of rework stemming from
undetected defects.
We have developed QA techniques for EasyWinWin that can be applied during negotiations
and after negotiations [Grünbacher 2004].
4.3.1 In-Process Quality Assurance
EasyWinWin describes two types of collaborative activities: In some activities stakeholders
focus on generating ideas and statements (“diverge”), in other activities stakeholders
consolidate the created results (“converge”). During “diverging” activities the primary goal
of the process is to produce new content. During “converging” activities the results are
consolidated and also checked for defects [Briggs 2001]. This separation avoids confusion
from switching the context between production and consolidation/analysis processes.
For local defects on the statement level (see Section 4.2) a simple form of alleviating the
effects of imperfect products is to check each individual statement. Beyond such simple
checks we have developed joint rapid checking activities to be performed by a team to spot
and resolve defects during a negotiation. At certain points in the process all participants step
back from the negotiation and check the quality of the products developed so far to eliminate
local defects that have been identified. Fixing defects in the process is typically
straightforward as it is possible to clarify issues with the author. The process is not an
65

inspection as the participants (and authors) review the products themselves. The list of
checking activities is in Table 10 and explained in detail below.
Table 10: In-Process Checking Activities in EasyWinWin
Activity Checking Focus
Review negotiation topics Context and negotiation topics
Converge on win conditions Initial set of win conditions
Capture a glossary of terms A glossary of terms
Identify issues and options WinWin Tree
Negotiate Agreements Completeness of negotiation results
Check Completeness Completeness of documentation

4.3.1.1 Check the Context and Negotiation Topics
The moderator and the stakeholders check the list of negotiation topics with respect to the
mission statement and statement of negotiation purpose. The negotiation topics shall be
consistent with the scope and boundaries of the system as defined in the mission statement.
In addition, they shall sufficiently address the system environment, interfaces; functions,
nominal and off-nominal cases; risks, technical and organizational constraints and
conditions; system quality issues, level of service, performance; as well as project issues
such as budget, time, resources, economic constraints, and conditions.
4.3.1.2 Check the Initial Set of Win Conditions and Glossary Terms
The next check in the process is after converging on win conditions and defining glossary
terms. Important conditions to be checked are:
66

• All win conditions express a stakeholder goal and are related to a specific
negotiation topic. Further they must be within the scope of the mission statement. If
a win condition covers more than one topic, it should be split up.
• All important and possibly unclear terms in the win conditions are defined in the
glossary.
4.3.1.3 Check the WinWin Tree
After the identification of issues, options, and agreements the checks from the preceding
stages can be repeated. Rules for describing agreements, risks, and glossary terms include:
• All win conditions and options are defined as complete, active, and positive
sentences.
• An issue states a risk, constraint or uncertainty on a win condition, and not a solution
or alternative.
• An option states a solution or an alternative to overcome an issue.
• An agreement is either derived from a win condition not raising any issues or from
an option.
• Important and possibly unclear terms in the issues, options or agreements are
defined in the glossary.
• Agreements and potential risks can be traced back to the initial win conditions in the
WinWin Tree.
67

4.3.1.4 Check the Completeness of Negotiation Results
At the end of the negotiation agreements and potential risks are organized by negotiation
topics. Sorted and reduced results are checked for completeness and comprehensibility:
• Agreements express goals that can be more general than requirements.
• Potential risks are open issues that could not be resolved during the negotiation.
• The glossary defines all potentially unclear terms in an unambiguous way (e.g., does
not contain undefined terms).
4.3.1.5 Check the Completeness of Documentation
The completeness of the documentation can be checked for project management and
requirements engineering purposes at the end of a negotiation:
• For each negotiation topic there is at least one win condition. Otherwise the list of
negotiation topics should be revised or missing win conditions should be identified.
• The set of agreements should provide a useful basis for developing plan, contract,
requirements document, etc.
4.3.2 Post-Process Quality Assurance
In addition to the joint and rapid checks performed by the stakeholders described in the
preceding section, we will use an inspection technique following the standard inspection
process [Gilb 1993].
68

Here are the actions taken by the inspectors that are related with the output of the
EasyWinWin Requirements Negotiation:
• Inspectors check the list of negotiation topics for clarity and completeness by
comparing it to a standard requirements engineering reference.
• Inspectors check each statement and mark potentially unclear/ambiguous terms and
statements. They look up unclear terms in the glossary, and report missing
definitions.
• Inspectors report unclear statements and mark win conditions, belonging to several
negotiation topics or listed under the wrong negotiation topic.
• Inspectors check each statement relevant for their perspective and mark incorrect
statements.
• Inspectors check whether each win condition really presents a goal, each issue really
is a constraint or objection, and each option really suggests a solution. Furthermore
they mark statements, which do not describe a goal (e.g., a design solution) and list
missing information by comparing the actual negotiation to the things they expected
to find.
• Inspectors mark statements that contradict each other and any other forms of
inconsistency (e.g., win condition vs. glossary definition; defects in the structure of a
WinWin Tree).
69

• Each entry in the glossary is checked for clarity and correctness of the definition,
especially whether unclear terms in the definition are explained appropriately.
70

Chapter 5:
Process Framework: Hybrid Method
This thesis integrates ideas drawn from template-based specification, Natural Language
Processing techniques, keyword analysis and inspections into a hybrid model of the
requirements engineering which allows the capture of stakeholders’ requirements, and
documenting them in a structured format as detailed requirements specifications.
5.1 Process Framework
A common finding in many of the Independent Expert Program Reviews conducted by the
Software Technology Support Center is that requirements elicitation, analysis, and
management is being conducted in an inefficient manner [Leishman 2002]. An important
step to mitigating requirements risks is to develop and strictly follow sound processes and
procedures relative to requirements engineering.
The importance of processes and their roles in a software development has been increasingly
widely recognized. In many cases, analyzes of processes showed that they included
redundant activities, unnecessary duplication of information and inefficient flow of work
from one process participant to another. There may be scope for process improvement where
the process is modified to meet some improvement objectives. Kotonya and Sommerville
[Kotonya 1998] provided the following objectives for process improvement:
71

1. Quality improvement: The outputs produced by the process are of higher quality.
In the case of requirements this means that they may contain fewer errors, may be
more complete or may better reflect the real needs of success-critical stakeholders.
2. Schedule reduction: The outputs from the process are produced more quickly. In
the case of requirements, this means that less time is needed to produce the final
version of the requirements document.
3. Resource reduction: Fewer resources such as staff time are needed to enact the
process. Therefore, a smaller team of requirements engineers can produce the final
document.
Thus the RE process, in general terms, consists of a series of activities. Each activity may
result in a work product. The work product should be capable of being maintained and be
subject to quality control. The effectiveness of the RE process should be capable of
measurement and improvements in the process should be quantifiable. There are four
questions which should be answered when planning process improvement:
1. What are the problems with current processes?
2. What are the improvement goals?
3. How can we introduce process improvement to achieve these goals?
4. How should improvements be controlled and managed?
It is a well-documented belief that the failure to develop and document good requirements
specifications is the major cause of software development failures [Davis 1990; Faulk 1997;
72

Standish 1995]. The problems with writing good, correct, complete, and testable software
requirements specifications are a major issue in software development. Some of the major
issues of concern in the requirements engineering area are:
1. The inability of engineers to write a correct software requirements specification
2. The lack of cooperation by stakeholders when it comes to verifying that the software
requirements are correct
3. The lack of understanding of the structure and purpose of the software requirements
specifications
4. The problems associated with identifying which tool and methodology to use in
developing and representing a software requirements specification
According to Sommerville & Sawyer [Sommerville 1997], selection of RE process depends
on many things: organizations, system engineering and software development process, type
of the software development, etc. All processes do not fit to all organizations. Usually good
requirements engineering process involves the following activities [Sommerville 1997]:
1. Requirements elicitation, where the system requirements are discovered through
consulting the stakeholders, from system documentation, domain knowledge and
market studies.
2. Requirements analysis and negotiation, where the requirements are analyzed in
detail, and they are accepted by the stakeholders.
73

3. Requirements validation, where the consistency and completeness of the
requirements are checked.
These activities also need support to accommodate changes in the requirements.
In our framework the requirements engineering activities are integrated around requirements
validation because in each activity there are some processes for validation (see Figure
7Error! Reference source not found.).

Figure 7: Requirements Engineering Activities
Our framework for developing software requirements is aiming to combine these following
processes and procedures that direct stakeholders in the following areas:
• Requirements elicitation
o Brainstorming: Brainstorming is a group creativity technique designed to
generate a large number of ideas for the solution to a problem.
74

Brainstorming helps in exploring alternatives and making right choices.
Each stakeholder throws out his views until finally a solution is agreed
upon. The solution derived from the brainstorming session will be checked
with other stakeholders. This increases the chances of building a right
product.
o Categorization: Categorizing requirements will aid in the discovery and
review of requirements during the requirements negotiation.
o Capturing glossary of terms: Identification of the key terms that have
specific meaning for the project is important to share the understanding of
the problem among the stakeholders. Definitions will be provided together
by the stakeholders decrease the ambiguity in the requirements
specification.
• Requirements analysis and negotiation
o Prioritization: Any project, especially with resource limitations, must
establish the relative priorities of the requested features, or functional
requirements. Prioritization helps the project manager plan for staged
releases, make trade-off decisions, and respond to requests for adding more
functionality.
o Prototyping: One effective mechanism for reconciliation stakeholders’
expectations and system capabilities involves prototyping concurrently with
negotiation. A prototype is a quick and dirty version of a potential product,
75

probably only part of the product. The intention of the prototype is to
present the stakeholders with a simulation of the requirements. There are
two approaches to build requirements prototypes: high-fidelity (uses some
kind of automated technology) and low-fidelity (mainly uses pencil and
paper or some other familiar means.) A low-fidelity prototype is built to
provide a quick visual explanation of some of the requirements and to elicit
some misunderstood or missing requirements [Robertson 1999].
o Conflict Identification and Resolution: Conflict identification seeks to
determine which requirements reduce the satisfaction of the other
requirements. Conflict resolution seeks to restructure requirements so that
the undesired requirements interactions will be reduced or removed.
• Requirements documentation
o Template specification: The attributes of the requirements template can be
tailored based on the type of the project and requirement type using the list
of all requirements template attributes (see Appendix B).
o Template filling: The requirements template attributes can be filled either
automatically by using the extracted information from the requirements
negotiation process and others can be filled manually by the system
analysts.
• Requirements validation
76

o Informal reviews: Informal reviews are unscheduled, unplanned, walk
through inspections of the product artifacts.
o Formal inspections: Formal inspections are type of scheduled,
comprehensive inspections of the product artifacts, usually performed by
properly trained operating personnel.
o Ambiguity analysis: The process of identifying the ambiguity that is part of
the requirements specification which will result in very costly changes aids
in resolving differences in meaning among the stakeholders.
o Completeness analysis: The requirements document should include all
requirements that define all functions, and constraints intended by the
system user.
o Consistency analysis: Requirements in the document should not conflict.
That is, there should be no contradictory constraints or descriptions of the
same system function.
• Requirements management
o Change management: Impact analysis is used to determine what other
artifacts in the development might be affected if a selected artifact changes.
o Requirements traceability: Traceability is the property of a requirements
specification that reflects the ease of finding related requirements. The
orphan requirements that have no source to be traced most of the time cause
either extra effort to be implemented for less return on investment.
77

5.1.1 Characteristics of Framework
Our view of the requirements engineering process can be characterized as follows:
• Iterative and Evolutionary: Requirements engineering process that will go into
more details during each iterative cycle during development phases. It is not enough
to obtain the stakeholders requirements once and assume that they are correct. Work
products evolve through reconsideration of previous results and elaboration of new
requirements. Approaches like the WinWin Spiral model support evolutionary
development [Boehm 1998]. The spiral model of RE process shows the iterative
nature of RE and involves repeated elicitation, analysis and validation activities.
• Bridging Activities: Feedback is one of the most powerful principles for software
engineering. Feedback helps stakeholders get better control of project by providing
facts about how things are working in practice. The earlier the feedback comes, the
better the requirements specifications be. The process fosters feedback between
requirements engineering activities to achieve a complete, consistent, and testable
set of requirements.
• Usability: The process is stepwise activities, which can be followed by even
inexperienced stakeholders with the help of some automatic checking, feedback
mechanism, and guideline explaining what is required for each step.
The framework provides stakeholders a clear structured way to formalize informal
stakeholders’ inputs to requirements specification and to maintain consistency and
traceability between negotiation artifacts (rationale for requirements) and requirements
78

specifications. Our goal in requirements documentation is “all requirements must be
specified with enough details to be testable and implementable.”
The initial requirements from the stakeholders are not clear and the developers also need
time to learn the domain. Due to the vague initial requirements, the process must involve the
stakeholders, especially the users, in making all the requirements decisions along with the
prototyping. Since the requirements are not well defined, the stakeholders must see the
prototyped behaviors and then be able to adjust the existing requirements. Thus, the process
must be iterative enough to allow continuous changes to the requirements, user interface and
system behaviors.
A utility capable of providing rapid and early feedback on the individual and overall
goodness of the requirements being created could improve the requirements elicitation and
documentation processes through highlighting at a very early stage in the relationship where
the potential contentious issues - inconsistencies, ambiguities, vague requirements, errors,
etc. - appeared. It offers guidance and explanations to users as to why their requirements are
considered problematic.
The framework provides a complete process of deriving a rigorous requirements
specification from informal and unstructured statements. The process starts with the capture
of stakeholders’ needs and expectations. Information gathered during requirements
elicitation often has to be interpreted, analyzed, modeled and validated before the
requirements engineer can feel confident that a complete enough set of requirements of a
system have been collected. During the requirements negotiation, and requirements
79

documentation, stakeholders formalize the requirements based on the template attributes in
order to produce an SRS.
The requirements validation activities check the intermediate results to produce correct,
complete, consistent, and unambiguous requirements specifications. Incomplete
requirements, compound requirements, negative requirements and dozens of other common
errors are found and flagged for fixing. Finally, the completed specification can be printed
out or passed on to another tool for further development. Table 11 and Table 12 show the
inputs and outputs for the requirements activities in our framework.
Table 11: Input and Output Information Types of the RE Activities
Requirements Engineering
Activity
Input Output
Requirements Elicitation Problem statement
Negotiation topics
Elicited and categorized win
conditions
Requirements Analysis and
Negotiation
Elicited and categorized
stakeholders’ win conditions
Prioritized win conditions
WinWin Tree
Issues related with win
conditions
Options addressed issues
Negotiated agreements
Negotiation topics tagged
with WinWin artifacts
Requirements
Documentation
WinWin Tree Software requirements

80

Table 12: Input and Output Information Types of the Requirements Validation
Requirements Engineering
Activity
Input Output
Requirements Validation
(during converge on win
conditions)
Win conditions
NLP criteria
Keyword Analysis Criteria
Corrected win conditions
Requirements Validation
(during negotiate
agreements)
Agreements
NLP criteria
Keyword Analysis Criteria
Corrected agreements
Requirements Validation
(after EasyWinWin
negotiation)
WinWin Tree
Checklist criteria
Validated WinWin Tree
Requirements Validations
(during requirements
documentation)
Requirements
NLP criteria
Keyword Analysis criteria
Corrected requirements
Requirements Validation
(after requirements
documentation)
Corrected requirements
Checklist criteria
Validated requirements

We have not attempted to adopt a full natural language understanding approach but only
using some of the natural language processing techniques to improve the quality of the data
gathered during the requirements engineering process.
Essential requirements engineering activities are:
• Identify all success-critical stakeholders
• Identify negotiation topics
• Elicit stakeholders' needs in important areas
• Agree on a common vocabulary for the project
81

• Prioritize requirements
• Find contradictions and dependencies between requirements
• Determine what requirement types to use
• Select attributes and values for each requirement type
• Establish a procedure to propose, review, and resolve changes to requirements
• Develop a mechanism to track requirements history
Our process is about using templates for the requirements, defining quality criteria of the
statements and emphasizes the importance of the participation of the success-critical
stakeholders on the activities of the requirements engineering to assure and warranty the
quality of them.
5.2 Our Hybrid Method
The Requirements Engineering is a group problem solving process where many stakeholders
make a variety of contributions that ultimately affect the effectiveness and efficiency of the
software product. A major challenge is thus to understand this group process, and based on
this understanding, find efficient ways of supporting groups of stakeholders in solving the
problem of deciding what techniques to use. Requirements must be analyzed to determine
completeness, consistency, and testability. In the process of formalizing informal
requirements, ambiguities, omissions, and contradictions will often be discovered. Table 13
shows the input and output of the steps during EasyWinWin requirements negotiation.
82

Table 13: Requirements Elicitation, Analysis and Negotiation Activities
Activity Input Output
Review and Expand
Negotiation Topics
Problem statement
Initial negotiation topics
Expanded negotiation topics
Brainstorm Stakeholder
Interests
Problem statement
Expanded negotiation topics
Stakeholders’ expectations
and needs
Converge on Win Conditions Stakeholders’ expectations
and needs
Main categories
Categorized stakeholders’
win conditions
Capture Glossary of Terms Stakeholders’ win conditions Glossary of Terms
Definition for terms
Prioritize Win Conditions Stakeholders’ win conditions
Prioritization Criteria
Prioritized win conditions
Reveal Issues and Constraints Prioritized win conditions Unstated assumptions,
constraints
Identify Issues and
Conflicting Win Conditions
Prioritized win conditions
Unstated assumptions,
constraints
Issues for win conditions
Conflicting win conditions
Identify Options and
Addressed Issues
Prioritized win conditions
Issues for win conditions
Options for each issue
Addressed issues
Negotiate Agreements and
Identify Related Win
Conditions and Options
Prioritized win conditions
Issues for win conditions
Options for each issue
Tagged win condition
without issue as agreed
Tagged some options as
agreed
Check Completeness WinWin artifacts
Negotiation topics
Tags between WinWin
artifacts and negotiation
topics

Our hybrid approach for formalizing informal stakeholder inputs is automatically putting the
categorized and prioritized EasyWinWin artifacts into a draft requirements template with
previously defined criteria for template properties and using NLP, keyword analysis and
inspections to analyze, control and improve the quality of requirements specifications. By
83

establishing a feedback mechanism using the data gathered from NLP, keyword analysis and
inspections, the process can be improved incrementally by taking advantage of the defect
information. Strong support for comments on the intermediate results allows stakeholders to
continuously remove defects and improve the quality of the requirements - refine the
intermediate results that will be inputs for further processes. In more detailed manner, the
following paragraphs will explain the processes done in our hybrid approach. Figure 8 shows
the context diagram of our hybrid method with the gap-bridging techniques.

Figure 8: Hybrid Method Framework

5.2.1 Mixed-Initiated Template
Mixed-initiated template is the combination of human-initiated template and computer-
initiated template. Requirements templates can be partially filled by computer processes and
84

rest of the work left to the stakeholders to fill and correct. The activities that are used to
define our template with their inputs and outputs are shown in Table 14.
Different type of requirements templates can be generated for use. For example, in MBASE
SSRD document, we have five different types of requirements: project requirements,
capability requirements, system interface requirements, level of service requirements, and
evolution requirements. For capability requirements we use a use case like template (see
Appendix C).
Table 14: Template Definition and Semi-Automatic Template Filling Activities
Activity Input Output
Review Requirements Type
and Define Requirements
Attributes
Requirement types as main
negotiation topics
Requirement types with
attributes
Map Agreements to
Requirement Types
WinWin artifacts with
negotiation topics tagged
Initial list of requirement
Fill Requirement Attributes Pre‐defined filling criteria
WinWin artifacts with
negotiation topics tagged
Requirements Specification

5.2.2 Natural Language Processing
A requirement is simply a statement in the chosen language that clearly tells an expectation
placed on the design process prior to implementing the creative design process.
Requirements are formed from the words and symbols of the chosen language. In the
English-speaking world, requirements are phrased in English sentences that cannot be
distinguished structurally from English constructed for any other purpose.
85

Plain natural language is a great tool for gathering stakeholders’ interests that are only
vaguely perceived, but in many cases these interests need to be reworked sooner or later into
precise system requirements. Failure to produce a correct requirements document will result
in the production of the wrong system.
Textual material from the early phases of a project, when suitably tagged and indexed, can
provide the background information and contextual clues that a human developer or
maintainer requires so as to understand the design goals and decisions implicit in the
finished system [Wile 1983].
Natural language is important because RE is largely about communication. NLP have
changed the way in which the language is used in specifications, for instance to avoid
ambiguity and to improve understandability. However, documents written in natural
language are often hard to process automatically and inconsistency is difficult to detect.
NLP is usually divided into two main areas: understanding, i.e., the problem of extracting
the meaning of sentences, and generation, i.e., the problem of generating sentences
conveying a given meaning. As an introduction to NLP techniques [Allen 1995], the main
components of NL analysis are:
• Morphology; the study of rules of word formation,
• Syntax; the study of rules of sentence formation,
• Semantic; the study of the interpretation of a sentence,
• Pragmatic; the study of the usage of language in a certain context.
86

The approach we take to automating the analysis process is as follows. We collect a list of
natural language checking criteria in terms of the parsing rules for a natural language parser.
We then apply these rules to the parser output and feed the results back to the stakeholders
for further correction. Some of the natural language checking criteria for writing good
requirements are:
• It is a good practice to write each requirement as a single sentence. If you find
yourself taking more than one to describe it, then you may in fact be describing
several requirements. If the word "and" appears, or you use two verbs in the
sentence, then it might be that you are describing two requirements.
• Form a complete sentence (not a bullet list of buzz words or list of acronyms).
• State a subject and predicate where the subject is a user.
• Use the active voice
• Syntactic analysis or parsing is the process of assigning a syntactic structure to a
sentence. Syntactic structure provides a foothold on the problem of semantics:
determining who did what to whom.
o POS tagging - disambiguation of words
o Syntactic chunking - identification of simple noun and verb groups
• Long sentences are not suitable for requirements specifications, especially when the
sentence contains two or more different requirements - split long sentences
87

• Look for unknown words, personal and possessive pronouns and replace them or ask
the user to provide an alternative
• Tag unknown words and proper nouns as keywords
• Separate the sentence into noun and verb phrase to transpose composed sentences
into simple sentences.
o Sentence with two noun phrases and one verb phrase could be split into two
sentences
o Sentence with two verb phrases could be split into two sentences
o Sentence composed of simple sentences could be split into sentences
• Spelling and grammar checks for stakeholder inputs
• Adjectives, adverbs, statements starting with verbs are sources for unverifiable
statements
• If statement starts with verb, and not a passive sentence then subject is missing in
the statement
• The use of conjunctions within a requirement in another example that requires user
interpretation because conjunction use often signifies multiple requirements within
the statement but valid exceptions exist that prevents the prohibition of their use.
o When “or” conjunction is used, most of the time the statement is vague, or
easy to be misunderstood.
88

o When “and” conjunction is used, the statement has the following problems
If it combines modifiers of noun, then statement is ambiguous
If it combines adjectives and there is no measure, then statement is
ambiguous
If it combines verbs, then there is a compound statement
• Find special characters (e.g. /, &) and replace them with their word meanings
• The avoidance of the use of pronouns and adverbs when writing requirements
• The verb indicating the action can be examined to classify requirements as
functional (transitive verb use) or non-functional (intransitive verb use)
• The auxiliary verb that identifies the imperative mood can be extracted (usually
"shall" but "must", "will", or "should" could be permitted) to identify the statement
as a requirement as opposed to an indicative mood statement that simply states a fact
• Find nouns and noun phrases, which are generally glossary of terms and eliminate
the synonyms of these terms. Then replace the eliminated terms with the most
general synonym left in the glossary of the term list.
We can rephrase sentences so that they are meaningful on multiple levels and to multiple
audiences, including the various kinds of stakeholders and software developers. Simplify the
structure of sentences makes them less prone to ambiguity. A useful mental model is that
89

functional requirements are characterized by verbs, and non-functional requirements are
characterized by adjectives.
The criteria for checking the understandability of the statements can be applied by using
natural language processing techniques. The NLP activity for defining checking criteria is
shown in Table 15. Moreover, the tagging process will provide us a list of proper nouns, and
noun phrases that can be used as initial glossary of terms for the stakeholders to choose their
real terms instead reviewing and adding them manually which results most of the time with
lack of finding important terms for the project.
Table 15: NLP Add-in to the Requirements Engineering Process
Activity Input Output
Define NL Checking Pre‐defined category,
checking criteria, and
feedback
Modified category, checking
criteria and description
Initial list of terms

5.2.3 Keyword Analysis
A simple yet powerful heuristic for detecting ambiguity is looking for weak phrases
indicators in requirements specifications, i.e., “clauses that are apt to cause uncertainty and
leave room for multiple interpretations”, as described in [Rosenberg 1998].
The words and phrases used as pattern indicators for respective categories were constructed.
If a certain term or keyword occurred in the text of a requirement statement, then as far as
possible that requirement belonged unambiguously to only one category. The activity to
define indicators in our framework is shown in Table 16.
90

Table 16: Keyword Analysis Add-in to the Requirements Engineering Process
Activity Input Output
Define Keyword Analysis
Checking
Pre‐defined category,
indicators, and feedback
Modified category, indicators,
and feedback

List of typical error types with indicators of words will be identified to check the statements
and requirements during requirements engineering activities. An example of tool that uses
this technique to measure the goodness is Automated Requirements Measurement Tool
(ARM) [Wilson 1997].
Table 17: Standard ARM Indicators

Categories
Imperatives Continuance Directive Option Weak
Phrases
Incomplete
Indicators
Shall
Must
Must not
Is required to
Are
applicable
Are to
Responsible
for
Will
Should
Below:
As follows:
Following:
Listed:
In particular:
Support:
And
:
E.g.
I.e.
For
example
Figure
Table
Note:
Can
May
Optionally
Adequate
As
appropriate
Be able to
Be capable
of
Capability
of
Capability
to
Easy to
Effective
As required
Normal
Provide for
Timely
TBD
TBS
TBE
TBC
TBR
Not defined
Not
determined
But not
limited to
As a
minimum

91

Table 17 shows the categories related to individual specification statement and the set of
related indicators. The categories and indicators can be modified according to the domain-
dependent quality purposes.
5.2.4 Inspections – Quality Assurance
Although some of the defects can be captured automatically, requirements inspections still
remain the principal arena for assuring the adequacy of requirements specification. Because
it costs so much more to fix defects later in the development process, formal inspection of
requirements is perhaps the highest leverage software quality practice available. Disciplined
verification processes by trained personnel prove their value by high software requirements
specification defect removal efficiency. To achieve a higher defect removal precede formal
inspections with informal reviews that take a broader look at the requirements specification
for completeness, consistency, and other quality factors that may be missed in a detailed
inspection. Combining formal inspection with incremental informal requirements reviews
provides a powerful approach to building quality into the product.
Checklists can be used to help reviewers focus on what to look for in a requirements
negotiation results and requirements specification and provide categories for classifying
defects. There are three levels of checking during the process of requirements negotiation
and specification. These are:
• Statement-level checking: This checking is performed during converge on win
conditions activity when a win condition identified. It is checked according to the
problems we gather for a statement (see Table 2 in Chapter 3). In addition, the
92

agreements are checked according to the same criteria during negotiate agreements
step.
• Requirement-level checking: This checking is performed while new requirements are
transformed from agreements and new information added as details to the
requirements template. The qualities we try to achieve are provided in Table 3 in
Chapter 3. Typical problems and solutions how to eliminate them are also provided
in Table 4 in Chapter 3.
• Document-level checking: This checking is performed both at the end of the
negotiation process and documentation process to improve the quality of the results
and remove the defects still exist in the product. Typical problems and solutions are
provided in Table 6 in Chapter 3.
A groupware system for requirements inspection should thus seamlessly support the many
ways that people work together; as individuals or in groups, co-located or geographically
dispersed, synchronously or asynchronously.
The major benefits of using a GSS for inspections are as follows:
• Its flexibility allows customizing it to different inspection process designs (e.g.,
different reading techniques, perspectives).
• It supports both individual defect detection tasks as well as inspection meetings.
• It can be nicely integrated with the negotiation and documentation process.
93

• It supports different inspector roles, i.e. inspectors performing different defect
detection tasks.
As described in Section 4.3 during negotiation and after negotiation quality assurance
techniques can be used integrated with the requirements negotiation and documentation
steps. To improve requirements, we need feedback. Faster and early feedback about the
negotiations results removes ambiguity more quickly, making requirements get done faster.
The information extracted and returned as comment to the stakeholders will remove the
defects in the WinWin results and requirements. Since some of the checking will be done
automatically, only correcting those defects left to the stakeholders. However, there are also
some defects that cannot be captured automatically. That’s why, we also need reviewers
participate the negotiation and documentation process in order to find more defects in the
WinWin artifacts and requirements.
94

Chapter 6:
Project Content and Software Process
6.1 Project Context
We have a strong motivation to find ways to bridge the gap between informal inputs and
more formal specification: At USC for example, we develop the requirements for 15 to 20
electronic services applications for the USC community as part of our software engineering
team project course each year. During the course we conduct requirements negotiations
involving real clients and 5-6 person teams of computer science graduate students as
developers. In average, one-third of the graduate students taking this class are experienced
software developers from industry, who often take this course remotely while they are
continuing to work at their respective companies. The projects are a key part of University of
Southern California’s core course in Software Engineering, which is designed to meet the
increased needs for people capable of integrating systems and software engineering in an
applications context [Boehm 1994]. The goal of these projects is to negotiate functionality,
budget, schedule, architecture, and transition for proposed e-services applications to be used
at USC.
6.2 Course Context
The CSCI 577A course is the first half of the USC Software Engineering project course,
which focuses on software plans, processes, requirements and architectures. This course
95

covers the application of software engineering process models and management approaches
for developing plans, requirements and architecture of large software systems. Students work
in teams and apply the Win-Win spiral model [Boehm 1998] and Model Based System
Architecting and Software Engineering (MBASE) guidelines for software engineering of
real-client projects [Boehm 1999].
We have been experimenting with EasyWinWin negotiation and the MBASE SSRD
requirements template, a formatted specification template, as a way of addressing the
problem of formalizing our project requirements.
6.2.1 Software Development Process
Over the years of developing electronic services applications for the USC Libraries, we have
been evolving MBASE [Boehm 2002] and its light-weight version LeanMBASE [Boehm
2005]. MBASE and LeanMBASE involves early reconciliation of a project’s success models
(correctness, stakeholder win-win, etc.); product models (domain requirements, architecture,
etc.); process models (waterfall, spiral, etc.); and property models (performance, reliability,
etc.). It extends the spiral model in two ways:
• Initiating each spiral cycle with a stakeholder win-win stage to determine a mutually
satisfactory set of objectives, constraints, and alternatives for the system’s next
elaboration during the cycle.
• Orienting the spiral cycles to synchronize with a set of cycle anchor points: Life
Cycle Objective (LCO), Life Cycle Architecture (LCA), and Initial Operational
Capability (IOC) [Boehm 1999].
96

During each of the anchor points, one of the key artifacts is a Requirements Definition,
which includes project and process, capability, interface, level of service, and evolution
requirements. In MBASE and LeanMBASE approaches, the Requirements Definition is
developed concurrently with the other five system definition artifacts (Operational Concept
Description, Prototype, Architecture Definition, Life Cycle Plan, and Feasibility Rationale)
[Boehm 2002]. So consistency between these project artifacts has a very high importance in
order to succeed developing the application. These approaches mix of flexibility and
discipline let project teams maintain consistency across multiple product views including
requirements template, use case scenarios, product architecture diagrams, requirements
traceability relations, etc.
For e-services application projects, project teams have roughly 11 weeks in the fall semester
to go from a short problem statement used in EasyWinWin negotiation to an LCO package
and then LCA package [Boehm 2002]. Project teams use a domain model [Boehm 1999]
included the system boundary, its major interfaces, and the key stakeholders with their roles
and responsibilities. This domain model also establishes a domain taxonomy, which is used
as a checklist and organizing structure for EasyWinWin requirements negotiation process.
Moreover, this taxonomy is used as the table of contents for the Requirements Definition,
ensuring consistency and rapid transition from EasyWinWin negotiation and requirements
specification.
6.2.2 Independent Verification and Validation (IV&V)
The basic objectives in verification and validation of software requirements specifications
are to identify and resolve software problems and high-risks issues early in the software life
97

cycle. Verification and Validation activities produce their best results when performed by a
V&V agent who operates independently of the developer or the analyst [IEEE 1998].
The remote graduate students (off-campus graduate students) in the course are responsible
for "Independent Verification and Validation" (IV&V). V&V is a collection of analysis and
testing activities across the full life cycle and complements the efforts of other quality-
engineering functions. It determines that the software performs its intended functions
correctly, performs no unintended functions and measures the quality and reliability of the
software. Figure 9 shows overall steps of developing and reviewing the artifacts.

Figure 9: Independent Verification and Validation in CSCI 577 SE Course

Developers produce the artifacts. The artifacts are sent to reviewers (IV&Vers) and they
review the artifacts. If the IV&Vers find any issue, they register potential Problems as
Concerns on the Concern logs. The Concern logs made by IV&Vers are sent back to the
developers. The author determines which Concerns need fixing and registers them as
Problems.
Developers
IV&Vers
Artifacts
Review
Identify
Provide Filter for
Fix
Concerns
Problems
Develop
98

6.2.3 EasyWinWin Output as Software Requirements Definition
EasyWinWin helps: (1) to achieve a reconciliation of customer expectations with developer
capabilities before firmly committing to a set of prioritized requirements, (2) to smooth the
transition from Stakeholders WinWin Agreements into requirements specification. The
agreements are used to identify the system requirements by mapping each agreement with
one or more of the titles to the outline in the Requirements Definition.
6.3 Initial Hybrid Method (Fall 2004)

Figure 10: Initial Hybrid Method (Fall 2004)

99

Our previous method for bridging the EasyWinWin-specification gap is what we’ll call the
“Human-Initiated Template” approach with applying “Inspections” to the Requirements
document (see Figure 10):
1. The project team member responsible for Requirements fills out the MBASE
requirements template for agreed-upon Win Conditions as shown in Figure 11.
2. Some other members of the development team and/or an outside member,
Independent Validation and Verification (IV&V) person, inspect the set of
specifications. They frequently find misinterpretations and other defects, causing
considerable rework.
3. Architecture Review Boards at the anchor points, described in software
development process subsection, consisting of client representatives and outside
experts review the reworked specifications. They find fewer misinterpretations
and other defects, but still cause further rework.
The teams have about three weeks to go from the EasyWinWin statements to a formatted
specification defined by MBASE process guidelines [Boehm 2002]. The MBASE
template format for capability requirements, for example, is [ID number; Title;
Description; Priority; Proposed Activity; Pre-condition; Post-condition; Reference; Risk
Level]. An example of EasyWinWin outputs mapped into MBASE SSRD requirements
template is shown in Figure 11.
100

Figure 11: EasyWinWin Artifacts and MBASE SSRD Requirements Template
Besides the rework effort, the main problems are that the steps have to be sequential with in
a very short time window, and that convergence is slow toward a fully elaborated shared
vision among the project stakeholders. A main reason for this is that the first step is done
from a single developer’s viewpoint.
Initial results indicate that using human-initiated template with formatted specifications
helps stakeholders understand the project’s requirements. Project negotiation makes all
stakeholders comfortable to share their interests and reduces the requirements mismatch and
changes, which are two of the top 10 risks that affect software projects [Boehm 1991] and
main reasons for the failure of projects [Standish 1995].
101

The hybrid method of human-initiated template and inspections provides pretty good results
according to requirements definition with complete, consistent, traceable and testable results
[Boehm 1984]. Concerning the issue of requirements completeness, there is no complete
requirements but sufficient requirements specification [Carson 2001] for the current project
and for the current level of development. During the negotiation process, teams used
negotiation topics to gather as many system requirements as possible. The negotiation also
provides consistency among the requirements because all stakeholders reach to an
agreement. References between the EasyWinWin agreements and system requirements
provide traceability through the development life cycle. When a change occurs, it can be
traced upward or downward in order to check the effected items. In addition, the negotiation
results used to create the formatted specifications such as pre- and post-conditions with
input(s) and output(s) are inputs for testability of the requirements. Inspections done on the
EasyWinWin output and requirements document improve the results of system requirements
by removing defects and ensure consistency of them [Halling 2003].
However this approach is a bit time-consuming because of doing things manually with
human-initiated template and inspections. In addition, there were no participation of
IV&Vers in the requirements negotiation and no inspections done on the negotiations results.
Although it is very efficient for small size project, it is difficult to use in large projects
because of the large size of the documentation. More effective methods for this situation are
other combinations of methods as hybrid method because of their abilities to get better
results from the negotiation.
102

6.4 Intermediate Hybrid Method (Fall 2005)
Requirements
Negotiation
Requirements
Documentation
output
Stakeholders
SSRD
do
output
WinWin
Report
Reviewer
(IV&V)
Requirements Engineer
use
Requirements
Template
use
Evaluation
Report
do
review
participate
submit
review
use
Evaluation
Report
submit
use

Figure 12: Intermediate Hybrid Method (Fall 2005)
In this intermediate hybrid method we still use “Human-Initiated Template” approach with
applying “Inspections” not only to the Requirements document but also to the EasyWinWin
report (see Figure 12). The teams started using the light-weight version of MBASE
(LeanMBASE) to guide them through out the development life cycle. The rest of the
activities were the same except the IV&Vs taking additional tasks.
IV&Vs are not required to participate to the Requirements negotiation sessions, but allowed
to contribute if they want. We would like to see how the participation of IV&Vs to the
103

requirements negotiations will improve the inspection of the work products generated by the
team. In addition, the IV&Vs had a new inspection document which is the first work product
produced by the team. The lessons learned by involving the IV&Vs into the requirements
negotiation proved that the effectiveness of the IV&Vs inspections improved due to their
understanding about the problem and negotiation done on the problem. They submitted more
quality concerns included evaluation reports that helped the team fix their problem or
mitigated the risks before they became unmanageable during the development process.
Moreover, with the EasyWinWin report evaluation we would like to check the type of
defects the negotiation results had in order to investigate an automation of defect
identification using Natural Language Processing and Keyword Analysis. More details about
the results of the EasyWinWin Evaluation results can be found in the chapter 8.
6.5 Our Hybrid Method
In our Hybrid Method described in detail in Section 5.2, IV&Vers are also success-critical
stakeholders. They will participate and contribute to the requirements negotiation of the
project. In addition to their participation to the software development process, the
development team will also use the guiding rules and natural language processing based
defect checker throughout the negotiation process to identify potential defects. It can be used
immediately during the process, or can be left until the negotiation session is over. Then the
requirements analyst or IV&Ver can use the tool to check the defect. The defects can be sent
to the stakeholders for more information and feedback in order to eliminate the problems the
negotiation results have and carried away to the requirements.
104

Since the requirements gathering process is iterative, during renegotiations the tool will
assist the development team to clarify the meaning of the statements.
After the negotiation done and agreements gathered, requirements analyst can use the
transformation process and prototype tool to transform the negotiation results into
requirements templates. The tool will provide the functionality to tailor the attributes of the
requirements template by adding or removing attributes from already pre-defined attribute
list. Currently the tool uses the LeanMBASE requirements templates as attributes.
6.6 Lessons Learned Through Hybrid Exploration
• Frequent prototype demonstrations affect the change of the project capabilities. It is
better to modify rankings of previously stated capabilities and develop new
capabilities.
• Use of prototype extensively during requirement negotiation found to be extremely
helpful in communicating with the client.
• Clients learning objectives would be enhanced and requirements would stabilize if
the client were involved in a document review after the LCO package.
• Involve IV&Vers into the negotiation process could put forth their views and the
issues with the various requirements and thereby ensure the feasibility of the
requirements.
105

Chapter 7:
Hybrid Method Tool Support
This chapter describes the main parts of the tool support for the framework in the elicitation,
analysis and negotiation, documentation, and validation of requirements gathered from all
success-critical stakeholders.
This is an iterative and incremental approach that is built in an iterative environment where
stakeholders participate in the requirements negotiation and definition process to respond to
the incomplete and ambiguous data.
7.1 Requirements Negotiation Defect Checker
The Requirements Engineering process is communication intensive. Requirements result
from stakeholders’ negotiation on functionality and quality of the software product to be
constructed. The requirements are interpreted and decisions are made during requirements
negotiation. Many stakeholders who are involved in the process make a variety of decisions
that ultimately affect the effectiveness and efficiency of the software product. The quality of
the requirements negotiation process is crucial as good-enough requirements is the
foundation for a successful focusing of the available development resources. Since,
processes and tool supports for Requirements Engineering as a decision-making process with
focus on describing and understanding stakeholders’ needs are essential.
106

Attacking ambiguity as early as possible in order to get rid of it since the cost of correction
in early stages of product development is much, much less than later. To improve
requirements, you need feedback from the stakeholders. Faster feedback removes ambiguity
more quickly, making requirements get captured faster.
The success of the projects depends critically on the stakeholders’ understanding of the
requirements specifications, which requires defined qualities and is tied to the quality of
these specifications.
As requirements are discovered during requirements negotiation, some analysis is carried
out, and if problems are recognized, they need to be discussed with the source of the
requirements and resolved.
Directly translation of informal specifications to formal specifications doesn’t eliminate the
problems informal specifications have. Only they are carried to the formal specification, may
be, with different meanings. So it is worthwhile to capture and fix the problems that informal
specifications have with the assist of the automated tools and stakeholders who are the
domain experts.
The literature review and analysis done on the requirements negotiation results reviews of
IV&Vers enable us to identify some guidelines that can be used by the stakeholders and
patterns for capturing ambiguities or other requirements statement related problems
explained in Chapter 3. The literature review has been done on the techniques of natural
language processing, mainly on natural language understanding techniques.
107

The approach we take to automate the defect identification process is as follows. We use a
part-speech-tagger to tag the negotiation results to get the part of speech tags of the words.
Part-of-speech tagging is the task of assigning each word it POS tag (see Appendix D). It is
not strictly what POS tags exist, but the most common ones are noun, verb, determiner,
adjective and adverb. Only 11.5% of all words are ambiguous with regard to their POS tags,
but since these are the more often occurring words, 40% of the words in a text are usually
ambiguous [Jurafsky 2000]. This makes the process of writing rules since the ambiguously
tagged words will make the tool vulnerable to identify defects where there is no defect (false
positive).
Based on the IV&Vers reviews we try to identify a list of natural language checking criteria
in terms of the parsing rules for a natural language parser. We then apply these rules to the
parser output and feed the results back to the stakeholders for further correction.
At the beginning of the development it is necessary to evaluate the requirements in order to
identify and solve ambiguities and inconsistencies in the requirements for starting the project
well. Due to the volatility of stakeholder requirements where they change during the project
life cycle, it is important to continue their analysis.
Some examples of defect types found in agreements, indicators, and way it is found are
provided below:
• Agreement: “Searchable archive based on predefined criteria”
o Defect type: Unverifiable statement
o Indicator: predefined
108

o Found by speech tag: adjective
• Agreement: “User authentication”
o Defect type: Incomplete statement
o Indicator: not a sentence
o Found by speech tag: no verb phrases
• Agreement: “Search by specific fields e.g. title, author”
o Defect type: Missing information
o Indicator: no subject
o Found by speech tag: start with verb
• Agreement: “More time is required to integrate with Z-bit or keep it as low priority”
o Defect type: Unclear term
o Indicator: “Z-bit”
o Found by speech tag: proper noun
• Agreement: “The database is easy to maintain and modify for the maintainer”
o Defect types: Unverifiable statement, Composite statement
o Indicator: weak phrase, multiple verbs
109

o Found by keyword “easy”, speech tag: conjunction
A set of rules for writing and checking of requirements helps in removing or minimizing the
deficiencies and ambiguities of the natural language requirements. Replace subjective
formulations with clear and objective formulations. Implicit assumptions must be made
explicit in requirements in order to be meaningfully complete. Incomplete comparatives and
superlatives require a reference point to be completely defined with the unit of measure and
the tolerance. Ambiguous requirements defined as requirements that have more than one
interpretation where source of ambiguity can be terms, pronoun references or certain
sentence structures.
Here are some of the rules that we built in order to catch the defects:
Passive Verbs: Passive verbs consist of the verb to be combining with the past participle of
another verb.
How to find: Each passive verb starts with one form of the verb to be, i.e., “is, are, was,
were, be, been, being” and followed by the past participle of another verb, either as a regular
verb ending in “ed” or an irregular verb.
How to fix: First method; place the agent before the verb. Second method; cut out as much of
the passive verb as possible.
Overwriting: Do not overuse qualifying words. Overusing qualifying words weakens the
understandability of the text and increase the ambiguity, in requirements point of view,
increase the vagueness and unverifiability.
110

How to find: Check adverbs, and adjectives such as adverbs for adjectives or adverbs for
adverbs.
How to fix: You can often delete them without loss of meaning or emphasis.
Foreign Words: Avoid foreign words or use the English alternative. This lets you omit the
foreign words, use the English equivalent, or recast your sentence.
How to find: Check foreign words using part of speech tag.
How to fix: Highlight common foreign phrases and usually give the English equivalent.
We use the LanguageTool [Naber 2003], an open source language checker for English, and
other languages, to apply our defect rule patterns that we identified. LanguageTool is a rule-
based language checker that will find errors for which a rule is defined in its XML
configuration files. It also allows writing Java codes for more complicated errors which
makes it a good candidate to use as a rule checker.
7.2 Requirements Negotiation Transformer
Writing good requirements is the key to a successful project. Without good user
requirements there is no clear direction for building a product. Development team members
can head in different directions.
Writing requirements is essentially a cooperative work; only the customers and users really
know the problem at hand, but only the requirements engineer can help them in fully and
correctly expressing them.
111

The analysis of requirements negotiation statements in the context of information systems
development is of growing importance in the field of computational linguistics, such as
using the part-of-speech of the words for identifying objects and methods, associating
classes with nouns, relationships with verbs, and attributes with adjectives and prepositional
phrases.
The taxonomy and the requirements templates make it possible to measure the degree of
completion, and more importantly the areas in need of completion. The requirement template
can be used to test whether a requirement is complete or not. The first test for completeness
is to compare the requirement with the attributes of the requirement template. While it is not
necessary to have every component for every requirement, if contents of some attributes are
missing then the requirement is incomplete.
Requirements template that can improve requirements elicitation and documentation can use
two kinds of patterns. Linguistic patterns are sentences in natural language descriptions that
can be parameterized and integrated into templates. Requirements patterns are generic
requirements templates found very often during elicitation process and can be reused with
some adaptation. Requirements templates help to express requirements. Requirements
information is structured in a fixed form, so requirements engineers know what missing
information must be searched and reuse is promoted. In addition, filing blanks in pre-written
sentences is easier and faster than writing a whole paragraph saving what the system is
expected to do. Moreover, requirements templates can be reused with some adaptation to
specific developments.
112

The Requirements negotiation results provide use rich information to start writing the
requirements. We first try to understand what kind of information they are in the negotiation
results and mappings between the attributes of the negotiation results and requirements
template. Here is a view from a WinWin Tree (see Table 18).
Table 18: WinWin Tree View
Capabilities
Business
Importance
Ease of
Implementation
Priority
Tag
[W55] The system shall be able to
add/edit/delete rules [Core
Capabilities]
10.000000 6.666667
LHF
[W59] The system shall be able to
add/edit/delete functions. [Core
Capabilities]
9.666667 6.333333
LHF
[W75] The system shall be capable of
creating a rule tree for the knowledge
base. [Secondary Capabilities]
5.833333 4.166667
IWH
[W76] The system shall be able to
perform simple rule optimizations
[Secondary Capabilities]
4.333333 3.000000
FGT

From the WinWin Tree we can get the information about what type of an winwin agreement
it is, what is the id of the winwin agreement, the agreement statement, the priority of the
winwin agreement, what taxonomy item it belongs to.
Using those information we are able to identity some of the attributes of requirements
template. Table 19 shows the way a capability requirement template generated for
LeanMBASE SSRD.

113

Table 19: Template Attribute Mapping Processes
Capability
Requirement:
Automatically generated by the tool
Title:
For the capabilities the “verb+object” is a good candidate for the
title
Priority:
Priority comes from the priority tag agreement has in the
winwintree.
Description:
The wiwin agreement can be placed here
Input(s):
The object(s) of the statement
Source(s):
The subject/actor of the statement
Output(s):
The object(s) of the statement
Destination(s):
The prepositional phrase of the object
Precondition(s):

Post Condition(s):

Win‐Win
Agreement(s):
The winwin agreement id

Based on the above mappings that we can use a tool which uses the mappings can be an aid
for a requirements engineer to generate a draft document of requirements. The iterative and
incremental nature of the process will allow the requirements expressed in desired level later
when the information about the missing attributes has been identified. Here is a requirements
template written by a requirements engineer by using the information they gathered during
the requirements negotiation (see Table 20).
114

Table 20: Filled Requirement Template (Example)

For the requirement to be complete the specification must contain a definition of the terms
used in the requirements. Attributes allow the information associated with a single
requirement to be structured for ease of processing, filtering, sorting, etc. The particular
attributes used will depend on the exact processes that need to be supported. Some attributes
are exactly automatic - e.g., dates, numbers; some come from users - e.g., priority; other
attributes are flags, which are set after analysis work - e.g., checkability.
The experience and knowledge of the practitioners is very important in the definition and in
the choice of the mappings between informal and formal notations. Complete automation of
the informal to formal specification transformation is unlikely, given that informal
Capability
Requirement:
CR‐ 1: Rule Optimizations
Priority:
W (Want to have)
Description:
The system shall be able to perform optimizations within the
Knowledge Base.
Input(s):
Set of knowledge Base rule objects.
Source(s):
User input, Imported XML file.
Output(s):
A list of new optimized Knowledge Base rule objects.
Destination(s):
The current Knowledge Base.
Precondition(s):
A Knowledge Base must have been loaded (possibly an empty one).
Post Condition(s):
The Knowledge Base is updated.
Win‐Win
Agreement(s):
W‐76
115

specifications are inherently incomplete. Human interaction is needed during generative
transformations to at least simplify generated formal specifications. Most generative
informal to formal specification transformations generate a formal specification skeleton
using information available from the informal specifications. This then requires the specifier
provide additional details to complete the formal model.
7.3 Requirements Negotiation Assistant (RNA)
In a software development process, informal requirements and/or specifications are often
written in a natural language since they become readable and the intuitive meanings
understandable. Such an informal specification is manually or semi-automatically translated
into a formal specification so that ambiguity, incompleteness and inconsistency of the
informal specifications are reduced.
At the beginning of the development it is necessary to evaluate the requirements in order to
identify and solve ambiguities and inconsistencies in the requirements for starting the project
well. Due to the volatility of stakeholder requirements where they change during the project
life cycle, it is important to continue their analysis. Our approach is thus to assist the
requirements engineer during the entire life cycle of the requirements, proposing some
methodology independent techniques to simplify his task.
An utility capable of providing rapid and early feedback on the overall goodness of the
requirements being delivered (or even created) could improve the elicitation process through
highlighting at a very early stage in the relationship where the potential contentious issues
(inconsistencies, ambiguities, vague requirements, etc.) were. Then help the stakeholder to
116

identify and improve badly phrased or contentious requirements as soon as possible in the
system development life cycle.
The words, phrases, and words linguistic information used as pattern indicators for
respective categories were constructed. If a certain indicator occurred in the text of a
requirements statement, then as far as possible that statement belonged unambiguously to the
defect category.
The defect checker is not another grammar checker. Although it is based on the
LanguageTool [Naber 2003] rule engine, it specifically checks the type of defects that can
occur in the requirements negotiation statement. On the other hand, the rules for defect
checker is based on the part-of-speech tags, instead of specific keywords such as easy, only,
and.
Figure 13 shows the block diagram of the Requirements Negotiation Assistant tool. The tool
uses the EasyWinWin Requirements negotiation tool results provided in html format as input
and formats it according to the WinWin Tree structure for both managing the winwin
artifacts and attributes. The NLP Interface is used to review the part of speech tags of the
winwin artifacts for additional review processes in case some defects can be missed during
the automated process. In addition, the NLP tool which is an open source used to extract the
template related meaning so it makes the process of template filling easier by using the
mapping between the extracted information provided by the NLP tool and the requirements
template attributes. The RNA tool uses the Defect Rule Engine to apply the rule it has to the
given winwin artifacts and highlight the potential defects it captures. This component also
enables to choose what type of defects to apply for the given input. Another component,
117

which allows to modify the requirements template attributes by displaying the initial
attributes for the given requirement type and allowing to add or remove additional attributes
for the general attributes list that can be used in the requirements template. Additional
information about the attributes can be found in Appendix B Table 27.

Figure 13: Requirements Negotiation Assistant Block Diagram
The Requirements Transformer uses the attributes list for the requirements types with the
extracted information stored in the database to fill the requirements attributes. The tool only
handles the attributes filling with the existing mapping it has. The user has to review the
transformation of the winwin artifacts into requirements and further enter the rest of the
information for the unfilled attributes.
118

7.4 Lessons Learned During Prototyping
While it is true that ungrammatical forms almost always lead to trouble, the converse cannot
be asserted with assurance. A statement may be perfectly clear and unambiguous according
to the rules of grammar, yet still be read in several ways by different readers.
Do not rely completely on the error messages generated by defect checker. Judgment is
needed to interpret error messages correctly and to make amendments to the text.
The defect checker tool can be used immediately to check if there is a defect or can be left
later to review the content all together. Studies have shown that near-immediate feedback to
the author facilitates more effective correction by signaling errors while the current content
is fresh in mind. In addition, the reinforcement of coupling successful correction with the
original thought process generates a reduction in first-time errors as writing continues.
119

Chapter 8:
Data Collection and Evaluation Results
The data collection and evaluations were done by using used by the teams projects during
CS577 Software Engineering courses in fall 2005 and fall 2006. During the requirements
negotiation and documentation, process effectiveness will be evaluated. Feedbacks from the
users will provide improvements to the framework and insight about what kind of tool
support will be beneficial to the stakeholders.
Example analyzes of case studies drawn from the software engineering course projects are
used to validate the hybrid method and prototype of the support tool for defect identification
and requirements transformation in order to improving the quality of requirements
specifications.
8.1 Data Collection
At the beginning of the semester, the students are required to fill out a background survey to
measure their experiences. The average of level of experience is measured by the number of
years the students have been working in industry.
The lists of real-client project during the Software Engineering courses in fall 2005 (see
Table 34 and fall 2006 (see Table 35 in Appendix F) can be found in Appendix F. The type
of the project and the clients’ community are also provided. Each year we are having some
project from industry, neighborhood, and university community.
120

8.1.1 Effort Data
In the Requirements Engineering process, productivity is about gathering enough agreed
requirements in order to proceed to the design stage with the minimum cost, time and effort.
Productivity in the RE process can be measured in terms of the number of people involved,
the time taken in the RE process (elapsed time), the cost of the RE process, the effort in
man-months and the amount of the requirements gathered.
The effort spent by the project teams are gathered from their weekly submission of effort
reports using an online effort system.
8.1.2 Word Product Data
The effort spent by the project teams are gathered from their weekly submission of effort
reports using an online effort system.
8.1.3 Review Data
There are two data types to be collected. The first is concern data from the IV&Vers. After
reviewing the artifacts Requirements Negotiation Results (EasyWinWin Reports) based on
defect types (see Appendix E) and Requirements Documents (SSRD), the IV&Vers made
Concern Logs, in which the concerns of the IV&Vers are written. All of the necessary
information is included in the logs. Another data type is a Problem List, which is produced
by the development team. The development teams recorded which concerns are problems
that need to be fixed and if the concerns are not problems, they provide the reason why.
Based on the collected data, data analysis was performed and statistical significant was
tested.
121

8.1.4 Feedback Data
At the end of the semester, student required to submit individual critique based on the
experiences they got throughout the course and answered some questions mainly related
with the processes they have used during the development lifecycle. They provide their
comments regarding the requirements related activities such as requirements negotiation
process, individual verification and validation process and transformation of requirements
negotiation results into requirements specification which are analyzed in order to eliminate
the weaknesses of the processes and improve the effectiveness of the processes.
8.2 Evaluation Results
8.2.1 Framework Validation
The framework was evaluated specifically with respect to the following qualities:
Effectiveness: The outputs produced by the framework are of higher quality. In our case this
means that the requirements may contain fewer defects, may be more complete or may better
reflect the real needs of success-critical stakeholders. The framework will demonstrate
effectiveness if there are no false positives in the defect identification process. A false
positive occurs when the defect identification process identifies a defect which is not exactly
a defect.
Efficiency: The outputs from the framework are produced more quickly with fewer human
resources. In our case this means that less time is needed to identify defects and produce the
final version of the requirements document.
122

Lets recollect the primary hypothesis: “For software development projects, the mean number
of defect for requirements related work products and the cost of producing those products
will not differ using our tool-assisted method (mixed-initiated template, natural language
processing, keyword analysis) and other approach (human-initiated template and non-
assisted inspections) or other requirements syntactic analysis tools”.
The corresponding individual hypotheses are:
Hypothesis 1 (H1): The number of defects found in requirements negotiation results will not
increase between the tool-assisted method and the non-assisted approach.
Hypothesis 2 (H2): The number of defects found in requirements negotiation results will not
increase between our tool and other requirements syntactic analysis tools.
Hypothesis 3 (H3): The cost of identifying defects in requirements negotiation results will
not decrease between the tool-assisted method and the non-assisted approach.
Hypothesis 4 (H4): The cost of producing the requirements document will not decrease
between the tool-assisted method and the non-assisted approach.
The individual hypotheses H1, H3, and H4 support the framework evaluation with respect to
the efficiency and effectiveness qualities. Evaluation of framework’s effectiveness is
supported by hypotheses H1. Evaluation of framework’s efficiency is supported by
hypotheses H3 and H4. Evaluation of effectiveness of defect identification approach is
supported by hypotheses H2.
A specific set of metrics is required to evaluate these hypotheses. H1 and H2 are concerned
with the number of defects found in the requirements negotiation results. H3 is related with
123

the cost of the defect identification in requirements negotiation results. H4 is involved with
the cost of producing requirements document using the mixed-initiated template approach.
To disapprove each of these null hypotheses we need to demonstrate that the hybrid method
framework is significantly better than the others.
Student’s t-test [Student 1908] was used to analyze the metrics for statistical significance.
Based on the hypotheses there are five metrics of direct interest to our validation:
1. Number of defects found by the defect checker based on defect types
2. Number of defects found by IV&Vers in the requirements negotiation results based
on defect types
3. The amount of effort utilized to identify defects in requirements negotiation results
by the defect checker
4. The amount of effort utilized to identify defects in requirements negotiation results
by the IV&Vers
5. The amount of effort utilized to produce an initial version of requirements document
from negotiation results
Some of these metrics were collected through assignments (reviews, inspections, etc.)
conducted in graduate software engineering during fall 2005 and fall 2006. Others are
gathered through analyzing the results of applying the defect checker and requirements
transformation processes.

124

The metrics collected during software engineering courses are:
• the number of defects identified by IV&Vers in requirements negotiation results
• the number of defects identified by IV&Vers in requirements document
• the effort report that the IV&Vers submitted for their inspections
• the weekly effort submission of the development teams
Other metrics that we collected are:
• the number of defects found by the other syntactic tools
• the amount of time spent to apply syntactic tools
The assignments given to the IV&Vers and development teams during software engineering
course are used so that metrics for the hypotheses H1, H3, and H4 were gathered.
During fall 2005, one evaluation assignment given to the IV&Vers to identify defects in the
requirements negotiation results produced by their stakeholders of their project. They have
identified the defects that occur in the requirements statements and the amount of time they
spent doing this assignment. During fall 2006, the assignments of this kind were given to the
IV&Vers and their review results are collected.
During fall 2005, four evaluation assignments given to the IV&Vers to identify concerns in
the requirements document produced by the development team, mainly by the requirements
analyst member. They submitted concern logs with the detailed descriptions of the concerns
and the amount of time they spent doing these assignments. It was the same way that the
125

IV&Vers did them during fall 2006. In addition, development teams reviewed the concern
logs to identify existing problems and descriptions of further rework in the problem logs.
They also provided rationale for the concerns that are not problems.
Distribution of students and their average work experiences are shown in Table 21. The p-
values of differences in average all student experiences and average DEN student
experiences for 2005 and 2006 group are greater than 0.1 indicating that these means are not
significantly different. On the other hand, the average on campus student experiences for
2005 and 2006 are significantly different based on the p-value. The fall 2005 students were
more experienced than the fall 2006 students.
Table 21: Student Demographics

2005 2006
P‐Value
Number of Students 157 156
On campus Students 120 125
Remote Students
37 31
Average Experience 2 years 1.48 years
0.16
( t =1.42)
Average On Campus Experience 1.3 years 0.6 years
0.0061
(t = 2.76)
Average DEN Experience 4.3 years 5.1 years
0.51
(t = ‐0.663)

126

8.2.2 Analysis of Defects in EasyWinWin Negotiation Results
Based on the IV&V evaluation done on the EasyWinWin report, number of defects and
comparison about the defect types found during IV&Vers review for fall 2005 projects are
shown in Figure 14. Some of the defects related with WinWin artifacts are listed in
Appendix F Table 33. We have found that more than one defect type can occur in the
WinWin artifact.
0
10
20
30
40
50
60
70
Number of defects
Team Number
Negative statement 01 0 3 0 0210 111 20 0 0 0 1 1 0
Composite statements 19 3 1 2 2630 52 11 30 0 4 0 1 1 1
Unverifiable statement / Vague terms 27 1 12 9 5 17 9 4 117 63 2 16 1 72 0
Incorrect statement 34 4 4 1 1120 310 01 3 2 0 0 2 0
Unclear statement / Ambiguous terms 7 3 18 8 8 5 23 18 4 10 6 16 17 9 13 16 0 5 7 3
Incomplete statement / Missing information 11 12 5 8 7 2 17 37 3 1 1 5 3 5 0 5 2 2 2 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23

Figure 14: Number of Defects Found in Negotiation Results per Team

We have found that unclear statements or ambiguous terms, incomplete statement or missing
information, and unverifiable statement or vague terms defect types are the main defect
127

types that occur in requirements negotiation results. Percentage of the defects types found
during IV&Vers reviews are shown in Figure 15.
Incorrect statement
6%
Unclear statement /
Ambiguous terms
36%
Incom plete
statement / Missing
information
24%
Composite
statements
10%
Negative statement
3%
Unverifiable
statement / Vague
terms
21%

Figure 15: Defects Distribution in Requirements Negotiation Results for fall 2005

Figure 16 shows the comparison of the number of winwin artifacts reviewed and number of
defects caught by the IV&Vers. Although the projects are different, the percentage of the
defected WinWin artifacts provide use the conclusion that approximately half of the artifacts
have some type of defects which will carry on to the requirements specification if not fixed
by the stakeholders. The defect numbers given in the figure are the total unique defect
numbers calculated from the IV&Vers’ reviews.
128

Defect Numbers vs WinWin Artifact Numbers per Team
76
87
63
31
45
39
140
38
54
53
49
47
48
34
26
17
28
43
19
22
26
35
25
36
25
14
56
61
11
22
12
35
30
20
18
39
3
16
15
4
0
20
40
60
80
100
120
140
160
34.2 40.2 39.7 116.1 55.6 35.9 40.0 160.5 20.4 41.5 24.5 74.5 62.5 58.8 69.2 229.4 10.7 37.2 78.9 18.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23
Percentage of Defects in WinWin A rtifacts
Team Number
Number of WinWin Artifacts
Number of Defects

Figure 16: Defect Numbers vs. WinWin Artifact Numbers per Team
Based on the effort submission of the IV&Vers for reviewing the EasyWinWin report, the
mean value of defects they identified in one hour was 4. However, the effort they submitted
includes the time they spent on familiarizing themselves with the artifact and preparing the
evaluation forms.
During fall 2006, the requirements negotiation review assignment has been updated based on
some feedbacks. The list of defect types was updated. The main defect types are the same
only additional types for typo errors, redundant statement, wrong categorization, etc. were
added. Check the Appendix for the updated list. During this semester, we had three
Requirements Negotiation results reviews. The first one was during the requirements
129

negotiation weeks, where the stakeholders had their first negotiation sessions and gathered
some of their win conditions. IV&Vers did a review on these win conditions and submitted
back their review forms to the teams for correction. Some of the teams fix the problems that
they have agreed on submitted as a defect by their IV&Vers.
The second review was after the teams finished with their requirements negotiations sessions
and prepared the EasyWinWin report. The third one was at the end of the semester where
teams updated their EasyWinWin negotiation results based on the meeting they had with
their clients and the feedback they got during the LCO Architecture Review Board. The
percentage of the defect types hasn’t changed between the two fall semesters projects (see
Figure 15 and Figure 17)
Incom plete
statement/Missing
information
22%
Unclear statement
/ Ambiguous
terms
33%
Incorrect
statement
9%
Unverifiable
statement/Vague
terms
25%
Com posite
statement
9%
Negative
statement
2%

Figure 17: Defects Distribution in Requirements Negotiation Results for fall 2006

Another finding that we have seen was the number of defect caught has been increased in
fall 2006 reviews as 6.5 defects per hour. Still these numbers include the familiarization and
documentation of the defects, not only reviewing and finding the defect.
130

8.2.3 Inspection Results of Requirements Specifications
The classifications of defect are missing, wrong, extra and open issue. Missing applies to
things that should be in the requirement, but are not. Wrong is for things in the requirement
which are present but have mistakes. Extra is for things that are not called for, i.e. there is no
requirement that implies they should be present in the requirements. Open issue are
problems that the author cannot fix solely in the requirement or at that time.
Figure 18 shows the comparison of number of concerns identified by the IV&Vers and final
defects registered by the author of the requirements documents in fall 2005. The number
review results collected was 28, 28, 26, and 29 respectively for four versions of the
requirements documents LCO Core, LCO Draft, LCO Package and LCA Draft.
26
138
148
77
182
10
129
18
68
53
21
216
29
74
93
31
00 0
16
39
6
18
8
13
2
7
138
3
34
00 0
50
100
150
200
250
1 2 3 4 5 6 7 8 9 101112 13 1415 1619 21 2223
Team Number
Number of Concens/Defects
Concerns Defects

Figure 18: Numbers of Concerns – Defects in Requirements Documents in fall 2005

131

The total number of concerns found is 1313. The total number of defects found is 284. The
average number of concerns and defects are 43, 9 respectively. However, there is no
uniformity across all the review results.
Figure 19 shows the comparison of number of concerns identified by the IV&Vers and final
defects registered by the author of the requirements documents in fall 2006. The number
review results collected was 29, 28, 28, and 25 respectively for four versions of the
requirements documents LCO Core, LCO Draft, LCO Package and LCA Draft.
42
36
25
110
48
155
16
84
12
39
22
56
47
124
43
15
122
14
9
24
9
84
25 26
4 5 6
15
7
12
25 26
15
12
76
7
0
20
40
60
80
100
120
140
160
180
12 345 6789 10111213141516 1718192021
Team Number
Number of Concens/Defects
Concerns Defects

Figure 19: Numbers of Concerns – Defects in Requirements Documents in fall 2006

The total number of concerns found is 1026. The total number of defects found is 399. The
average number of concerns and defects are 35, 14 respectively. However, there is no
uniformity across all the review results. On the other hand, we are proposing that our
132

framework will eliminate some of the defects earlier than the reviews and also find more
defects in a short time than the current review process.
8.2.4 Comparison of IV&V Evaluations and Defect Checker Tool
Results
Table 22 and Table 23 respectively show the total number of defect caught by IV&Vers and
Defect Checker tool.
Table 22: Number of Defects found by IV&Vers in Negotiation Results
Team
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23
Incomplete
statement /
Missing
information
11 12 5 8 7 2 17 37 3 1 1 5 3 5 0 5 2 2 2 1
Unclear
statement /
Ambiguous
terms
7 3 18 8 8 5 23 18 4 10 6 16 17 9 13 16 0 5 7 3
Incorrect
statement
3 4 4 4 1 1 1 2 0 3 1 0 0 1 3 2 0 0 2 0
Unverifiable
statement /
Vague terms
2 7 1 12 9 5 17 9 4 1 1 7 6 3 2 16 1 7 2 0
Composite
statements
1 9 3 1 2 2 6 3 0 5 2 11 3 0 0 4 0 1 1 1
Negative
statement
0 1 0 3 0 0 2 1 0 1 1 1 2 0 0 0 0 1 1 0
TOTAL
24 36 31 36 27 15 6
6
70 11 21 12 4
0
31 18 18 43 3 16 15 5

This only shows the quantitative analysis of the defects. It is clearly shown that Defect
Checker tool can find more defects than IV&Vers. On the other hand, Defect Checker
cannot find defects in categories incorrect statement and negative statement. It is due to the
133

fact that the incorrectness requires human judgment. However, the negative statement defect
type is due to the incapability of the part-of-speech tagging tool used.
Table 23: Number of Defects found by Defect Checker in Negotiation Results
Team
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23
Incomplete
statement /
Missing
information 35 52 25 11 31 16
12
4 26 20 30 32 35 36 19 12 7 16 21 10 9
Unclear
statement /
Ambiguous
terms 36 15 28 17 10 1 16 0 8 19 11 22 0 16 1 4 13 9 4 2
Incorrect
statement
Unverifiable
statement /
Vague terms 25 35 57 24 23 27 51 11 16 26 22 31 15 28 7 9 22 22 10 12
Composite
statements 8 13 6 5 14 5 17 1 3 5 5 8 5 3 3 6 1 7 1 3
Negative
statement 11 0 3 0 2 0 18 0 0 4 0 0 0 0 0 0 0 0 0 0
TOTAL
115 115 119 57 80 49
22
6 38 47 84 70 96 56 66 23 26 52 59 25 26

This doesn’t prove that all the defects caught by the Defect Checker are true positives. The
qualitative analysis done on the defects found by the tool finds some false positives due to
the wrong part-of-speech tagging (see Table 24).
Table 24: Number of True Positives and False Positives
Team
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23
True
Positives
10
1
10
6
10
8 52 55 45
19
4 28 40 79 67 88 53 58 22 23 44 48 23 26
False
Positives
14 9 11 5 25 4 32 10 7 5 3 7 3 8 1 2 7 11 1 0
134

The analysis of patterns indicates that the distribution of the false positives fall into the
following defect categories; incomplete, unverifiable, composite, unclear. Table 25 lists the
number of false positives captured by the Defect Checker tool.
Table 25: Distribution of False Positives
Team
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 19 21 22 23
Incomplete 14 5 9 4 6 3 31 8 7 5 3 7 3 2 0 1 2 7 1 0
Unclear 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0
Unverifiable 1 2 1 1 11 1 0 1 0 0 0 0 0 5 1 0 2 3 0 0
Composite 0 0 0 0 7 0 1 1 0 0 0 0 0 0 0 0 1 1 0 0

Many false positives indicated by the Defect Checker for the incomplete defect type (see
Figure 20). Main reason is the ambiguity of the part-of-speech tagger, where more than one
tag provided for a word, assigns wrong pos tag to the words. The Defect Checker requires
more complex rules to eliminate false positives.

Figure 20: False Positive Distribution

135

Further analysis of the false negatives show that due to the not including any patterns for the
negative statements, they remained as false negatives for the defect analyzer.
Figure 21 lists the number of defects found by the pattern for all the teams. The numbers in
front of the rules are given for the defect categories. The

Figure 21: Defect Rule Pattern Distribution

Figure 22 lists the number of true positives defects found by the pattern for all the teams
compared to the all defects found by the IV&Vers defect analysis on the requirements
negotiation results. The number of defects found by the Defect Checker is due to some
statements had more than one defect. Except in 2 projects, Defect Checker found an average
of 3 times more defects. The reason for those projects is that they have two IV&Vers whom
assigned multiple defect types to the same negotiation statements.
136

Figure 22: Comparison of Number of Defects in Negotiation Results

The analysis shows that in overall Defect Checker did a better job than the reviewers based
on the number of true positives defects found (see Figure 23). The mean values of the defect
types shows that the Defect Checker has very high ratio defect rate than the IV&Vers review
results. Only in unclear statements/ambiguous terms the ratio is a little close to each other.

Figure 23: Defect Checker versus IV&Vers Review Analysis Results

137

Only in incorrect statement category the Defect Checker cannot processed any value due to
the analyst/reviewers judgment needed. Hypothesis H1 is rejected because the p-values for
using un-paired t-test are less than the alpha value of 0.05.
Defect Checker spent a few seconds to generate a defect report. However, the cost of the tool
finding the defects depends on the analyst/reviewers checking the defects for false positive
and validating the defects. In additions, the cost of finalizing the defects depend on the
number of requirements negotiation artifacts. If the number of artifacts is bigger than the
time required validating will increase.
Based on the calculated results during the analysis of the defect identification by the Defect
Checker and further validation of defects identification of false positives, it is estimated that
3 to 5 minutes required spending per defect. On the other hand, the average cost for the
IV&Vers are 0.68 hours per defect base on the review data collected which include the
following cost; familiarizing themselves with the review process and project, reviewing and
identifying the defect, and documenting the defects. Hypothesis H3 is rejected due to the
cost analysis that spent for identification of the defects when the costs compared between the
Defect Checker and IV&Vers Defect Review.
8.2.5 Comparison of Syntactic Tools and Defect Checker Tool
There are syntactic tools, where some of them are free to use, to measure the quality of the
natural language requirements specification. I have done a comparative analysis of these
syntactic tools and the prototype of defect identification tool Defect Checker which is part of
the Requirements Negotiation Assistant tool. The following syntactic analysis tools are used
for the comparison of the defects identification:
138

• Syntactic Tools (based on indicator keywords):
o Automated Requirements Analysis Tool (NASA ARM): The Automated
Requirement Measurement (ARM) Tool was developed by the Software
Assurance Technology Center (SATC) at the NASA Goddard Space Flight
Center as an early life cycle tool for assessing requirements that are specified in
natural language. The objective of the ARM tool is to provide measures that can
be used by project managers to assess the quality of a requirements specification
document. The tool is not intended to evaluate the correctness of the specified
requirements. It is an aid to “writing the requirements right”, not “writing the
right requirements”.
The ARM tool searches each line of the requirements document for specific
words and phrases the SATC has identified as quality indicators. Using these
indicators, the ARM tool creates a file that includes three reports. This file
contains a Summary Report, a detailed Imperative Report and a detailed Weak
Phrase Report. The ARM Summary Report includes the total number of times
each quality indicator occurs in the requirements document. The location within
the source file of each specification statement identified by the tool and a copy
of the specification statement are listed by the Imperative Report. The Weak
Phrases Report lists the location and specifications that contain indicators that
are considered to be phrases that weaken the specification.
o TIGER Pro: TIGER Pro is a front end tool for assisting the user to write good
requirements. It elucidates requirements based on a set of "poor words" and
139

pointing out up to seven types of (potential) defects in each of the requirements
(multiple requirement in a paragraph, possible multiple requirement,
unverifiable requirement, use of "will" or "must" instead of "shall", the existence
of a user defined "poor word", design constraints in the requirement and
incomplete sentences).
o CassBeth SAT: The Specification Analysis Tool (SAT) is an automation aid to
help organizations develop clean useful specifications that contain clear,
complete, consistent, and testable requirements. SAT performs automated
specification analysis very fast but allows Humans to make final decisions at
each level. It is service based and allows you to determine which level of
services are needed for any given specification analysis task. While performing
these services it gathers metrics and makes them available for easy review
allowing you to optimize your rules across projects.
o CassBeth SAT based on QuARS indicators: The tool, called the Quality
Analyzer for Requirements Specifications (QuARS), makes it easier to extract
structured information and metrics for detecting linguistic inaccuracies and
defects. QuARS allows requirements engineers to perform an initial parsing of
requirements by automatically detecting potential linguistic defects that can
cause ambiguity problems at later stages of software product development.
• Requirements Negotiation Assistant – included Defect Checker based on LanguageTool
rule-based engine for grammar checker which uses part-of-speech rule patterns with
combination of limited keyword indicators such as verb “BE”.
140

Based on the analysis, Table 26 shows the results of which tool did get the highest problem
among them based on the defect rate which is calculated as follows:
Defect rate = Number of defects/Number of WinWin Artifacts
Table 26: Defect Rates for Syntactic Tools
NASA ARM
TIGER Pro without
incomplete sentence
CassBeth SAT
SAT‐QuARS
RNA (Defect Checker)
Tool Outperformed
0.45 0.70 0.96 1.08 1.51 RNA (Defect Checker)
0.92 1.14 0.92 0.95 1.32 RNA (Defect Checker)
1.05 1.29 1.19 1.50 1.92 RNA (Defect Checker)
0.58 0.74 1.06 1.29 1.84 RNA (Defect Checker)
0.96 1.02 1.07 1.09 1.78 RNA (Defect Checker)
1.51 1.74 1.67 1.54 1.26 TIGER Pro
0.29 0.69 0.74 0.71 1.61 RNA (Defect Checker)
0.00 0.08 0.28 0.40 0.95 RNA (Defect Checker)
1.13 0.61 0.98 0.78 0.87 NASA ARM
1.00 1.11 1.19 1.13 1.58 RNA (Defect Checker)
0.89 1.43 1.04 0.94 1.32 TIGER Pro
1.66 1.36 1.32 1.47 2.04 RNA (Defect Checker)
0.25 0.48 0.50 0.44 1.17 RNA (Defect Checker)
0.21 0.56 0.62 0.88 1.94 RNA (Defect Checker)
0.81 1.12 1.00 0.69 0.88 TIGER Pro
1.00 1.35 0.82 1.00 1.53 RNA (Defect Checker)
0.71 0.79 1.07 1.18 1.86 RNA (Defect Checker)
1.25 1.32 1.32 1.32 1.34 RNA (Defect Checker)
0.27 0.67 0.60 0.40 1.67 RNA (Defect Checker)
1.32 1.36 1.55 1.23 1.18 CassBeth SAT
141

Due to the QuARS tool not available to the public at the time of the analysis, I have
collected the indicators that have been published for the QuARS. These indicators are used
with the CassBeth SAT rule analysis tool for syntactic analysis to identify defects in
negotiation results. I have excluded the TIGER Pro with the rule that it will check if the
statements don’t have modal verb “shall” and if not then adds it as a problem into the total
number of problems this is not the case with the other tools in order to have a better
comparison done on the syntactic tools.
All of the tools, except Requirements Negotiation Assistant use keywords as a list of
defective words to be captured by their tool to find out the number of defects. My tool uses
pos-tag based regular expression rules to check the problems. The t-test results of the
comparison analysis of the syntactic tools are shown in Figure 24.

Figure 24: Comparison Analysis for Syntactic Tools and Defect Checker

142

It is clearly seen that Requirements Negotiation Assistant tool outperforms in most of the
projects. It found the highest number of defects in the projects EasyWinWin reports based on
the defect rates. Hypothesis H2 is rejected because of the p-values for using un-paired t-test
are less the alpha value of 0.05.
8.2.6 Evaluation of Requirements Transformation
In order to do a better evaluation of Requirements Negotiation results into Requirements
Specification, first we need to understand the relationship between those two products
artifacts.
The number of win conditions and agreements gathered during the EasyWinWin negotiation
process are generally close to each other. When there are more agreements that means there
are more than one option for a win condition and more than one option has been agreed.
Some projects made better analysis on the issues related with win conditions which decrease
the risk for their project.
The comparison of the agreement and requirement numbers show close ranges between them
except for project category. When the traceability analysis is done between agreements and
requirements, we will see that there are some agreements left without defining any
requirement. On the other hand, there are some requirements without any trace to
agreements, which means new requirements added to the list from customer meetings.
However, this has a bad effect on the requirements dependability. Since, the consistencies
between requirements are very important in order to satisfy the stakeholders.
143

Our framework will provide capabilities to capture the dependency and contradictions
between the requirements, in addition to managing the requirements list by using the tool.
Therefore, the addition or change in the requirements will be managed to eliminate more
defects in the requirements specification.
The following figure (see Figure 25) shows the total number of requirements generated from
the total number of agreements. The “Tag with Negotiation Topic” provides us the linking
categories the agreements are belong to. However, the agreements are not tagged only with
one negotiation topics, but more than one.
Comparison between agreements and requirements
according to Tagged Negotiation Topics
18 5
14 9
83
10 3
50
265
15 9
49
77
44
263
16 9
15 2
21 6
94
15 9
0
50
100
150
200
250
300
Project
Capability
Interface
Level of Service
Evolution
NO TAXONOMY
Agreements Requirements Tag with Negotiation Topic

Figure 25: Comparison between Agreements and Requirements based on Topics

The results show the dependency between the agreements and negotiation topics, where a
computer software requirement tagged agreement is also related with user interface
requirement and more. On the other hand, these dependencies provide us a valuable detail
during the requirements documentation. Hence, while generating requirements from
144

agreements the related WinWin artifacts can improve the process of extracting information
that is required for that requirement. In addition, changes done on some of the artifacts’
impact on other artifacts will be managed easily.
The analysis of cardinality between the WinWin Agreements and requirements shows that
most of the time there is a one-to-one relationship (see Figure 26). Moreover, there are
situations where one than one agreement traced to a requirement.
EWW to SSRD
83%
12%
1% 2%2%
1%
1 to 1
1 to 2
1 to 3
1 to 4
1 to 5
more than 5

Figure 26: Cardinality between Agreements and Requirements

The following Figure 27 and Figure 28 show the relationship between the mean number of
agreements gathered during the requirements negotiation and the mean number of
requirements documented based on those agreements for fall 2005 and fall 2006
respectively. Although there are little differences between the agreements and requirements,
in general observation the average number of agreements and requirements are close to each
other with respect to the agreements gathered during the requirements negotiation.
145

Figure 27: Mean Number of Agreements and Requirements for fall 2005

Figure 28: Mean Number of Agreements and Requirements for fall 2006

146

The analysis of effort cost spent for documenting the requirements specification will provide
the differences between the techniques used between fall 2005 and fall 2006. During fall
2006, the process allowed the teams spent less time documenting and managing
requirements documents. The cost of producing a requirements document from the
negotiation results shows that the amount of time spent to produce and maintain the
requirements documents was better when the tool-assisted hybrid methods techniques was
used (see Figure 29).
0
10
20
30
40
50
60
70
80
WinWin Negotiation
Prototyping for Requirements
Modeling and Documenting OCD
Modeling for SSRD
Documeting for SSRD
Documenting the COTS
Assessment CAB
Fall 2005
Fall 2006

Figure 29: Comparison of Requirements Related Activities

The analysis of cost of effort in transitioning agreements into requirements specification
based on the t-test is given in Figure 30. In order to show there are no statistically significant
differences between the number of agreements and number of requirements we have
provided the t-test values for them either. The p-values indicate that there are no statistically
significant differences between the two groups of data. On the other hand, the p-value for the
147

documenting for SSRD shows that the differences between the values are very statistically
significant (see Figure 30). With respect to these results, Hypothesis H4 is rejected because
the p-value for using un-paired t-test is less than the alpha value of 0.05.

Figure 30: Comparison of Cost of Effort for SSRD Documentation

8.2.7 Summary of Evaluations
Analyses and results of this research described in this dissertation illustrate the following
results:
• Hypothesis H1 is disproved by t-test analysis done on the number of defect found by
both approaches.
• Hypothesis H2 is disproved by the t-test analysis done on the mean number of
defects found by each syntactic analysis tools.
148

• Hypothesis H3 is disproved by the analysis of cost estimation using the tool assisted
techniques and the effort submission of the IV&Vers on the same requirements
negotiation results.
• Hypothesis H4 is disproved by t-test analysis done on the mean number of effort
cost spent transitioning the requirements negotiation agreements into structured
requirements specification.
The Hybrid Method demonstrates that it will improve the efficiency and effectiveness of the
requirements negotiation process whereas easy the defect identification and transformation
of the requirements negotiation agreements into structured requirements specification with
the assistance of the Requirements Negotiation Assistant tool.

149

Chapter 9:
Conclusion and Future Work
9.1 Conclusion
Errors in requirements specifications can have a major impact on software costs. It is evident
that early detection and correction of potential problems during requirements analysis may
alleviate many much larger problems later on during testing and maintenance. Despite this,
in comparison with the rest of software development activities, relatively little time and
effort is expended during requirements phase. By investing more up-front in verifying and
validating the software requirements specifications, projects may harvest the benefits of
reducing integration and test costs, higher software reliability and maintainability, and more
user-responsive software.
In order to improve the software engineering design, testing and quality control, first we
have to improve the ability to articulate quality requirements and requirements in
unambiguously clear testable format. Thus, writing good requirements specification is
important. A well-written requirements specification pays for itself many times over -- the
construction is more precise, the maintenance costs less, and the product reflects what the
stakeholder needs and wants.
You cannot build the right product unless you know precisely what the product is intended to
do, and how the product’s success is to be measured. This research considers how the
150

requirements problems can be addressed by selecting appropriate methods to support the
process of requirements generation and validation. It describes each method briefly and
shows how it contributes to the requirements engineering process. We have presented a
model relating WinWin and Requirements artifacts to bridge the gap between requirements
negotiation process and system requirements specification. We try to combine existing
approaches with group support system instead of inventing a new approach.
We believe that bridges between different ways of representing knowledge in the software
process are useful to: Overcome the lack of communication and interaction between the
users and the development team, and support iterative and evolutionary software
development processes. Involving customers and users throughout the development effort
can result in a better understanding of the real needs.
Activities supported by gap-bridging techniques, some techniques used for semi-automation
of defects identification in order to reduce defects in the front end of the software
development process. In additions, information extracted by those techniques will return to
the stakeholders as feedback during negotiation and documentation activities. Furthermore,
semi-automation of requirements identification and documentation using template-based
refinement approach will improve the quality of the requirements gathered during the
requirements engineering process.
The work shows that requirements captured in natural language can be evolved to a more
formal representation by means of an intermediate activity in which the requirements are
structured. The success-critical stakeholders should conduct this activity. Although it
requires some additional effort, it is a useful step to improve the quality of WinWin results,
151

to discover open issues and problems in the requirements specification, and to establish
useful links supporting traceability. Identified problems and links can be used in further
refinements of the specification or in case of changes to the specifications. By providing
templates and guidance for requirements writing, we address common issues granularity and
facilitate the communication between stakeholders.
9.2 Future Work
9.2.1 GSS based Hybrid Method Support
While current generation tools provide good support to requirements capture and
requirements analysis, they offer only modest assistance for linguistic tasks such as
requirements writing and documentation. Using a part-of-speech tagging tool to tag and
extract the noun phrases and verb phrases through its API.
This dissertation presented our research of RE tools automating and supporting the activities
of requirements engineering where stakeholders participate. The first steps to realize our
process have been the analysis and selection of proven gap-bridging techniques and tools,
and the development of hybrid method based on them.
While initial results are encouraging, more studies are necessary to provide a tool support for
our hybrid approach and evaluate its usefulness. In further research activities we will
empirically evaluate the tool with respect to their benefits and usability and then we will
demonstrate how RE tool can support stakeholders in real-world settings.
152

The Group Support System platform can provide an extremely cooperative environment for
requirements engineering activities:
• Writing and managing requirements specifications
• Validating the requirements for consistency and completeness
A process guideline will explain the use of group techniques and collaborative tools in our
framework. A detailed process guide will reduce variance in the quality of deliverables and
help lower-skilled or less experienced practitioners accomplish more than would be possible
with straight stand-up facilitation.
9.2.2 Boilerplates
Those who have difficulty writing requirements experience one of three problems:
1. fundamental problems expressing themselves in the language of choice,
2. technical knowledge deficiency that makes it difficult to understand the technical
aspects of the subject about which the requirements are phrased,
3. difficulty in deciding what to write requirements about.
One solution to these problems is using boilerplates [Hull 2005]. This results in a more
complete requirement statement that becomes the text for the requirements. Providing
requirements statement with blank parts that can be replaced with the requirements attributes
make the process of requirements gathering easier especially for the stakeholders who have
less experience on software development and requirements specifications.
153

9.2.3 Conceptual Models
Conceptual modeling is based on a linguistic approach that tries to formalize the linguistic
mechanisms through which analysts are able to abstract observed phenomena onto concepts.
Some people think more precisely with words, whereas others are better able to grasp
concepts quickly by studying diagrams. Using both types of representation leverages
different thinking modes and permits project stakeholders to understand requirements from
more than one angle.
Requirements elicitation and analysis is a process of learning and discovery. The goal is to
sufficiently understand the requirements so that the stakeholders can prioritize and allocate
them to software. Models can supplement requirements specified as textual statements.
Because each representation relates to another, using multiple models tends to accelerate
understanding and reveal errors in requirements. Analysis modeling promotes overall
software quality, helping the stakeholders define the right requirements so that the right
solution can be delivered.
154

Bibliography
[Ackerman 1989] Ackerman, A. F., Buchwald, L. S., and Lewski, F. H., “Software
Inspection: An Effective Verification Process,” IEEE Software, Vol. 6, No. 3, May 1989, pp.
31-36.
[Alford 1985] Alford, M., “SREM at the Age of Eight: The Distributed Computing Design
System,” IEEE Computer, 4/1985, pp.36-46.
[Allen 1995] Allen, J. F., Natural Language Understanding, Benjamin Cummings, 1995.
[Ambriola 1997] Ambriola, V., Gervani, V., “Processing natural language requirements,”
Proceedings of ASE 1997, IEEE Press, 1997, pp.36-45
[Balzer 1978] Balzer, R., Goldman, N., and Wile, D., “Informality in program
specifications,“ IEEE Transactions on Software Engineering, 4(2):94-103, March 1978.
[Basili 1996] Basili, V., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Soerumgaard, S.,
and Zelkowitz, M. “The Empirical Investigation of Perspective-Based Reading,” Empirical
Software Engineering: An International J., vol. 1, no. 2, 1996, pp. 133-164.
[Beck 2000] Beck, K., Extreme Programming Explained. Addison-Wesley, 2000.
[Bell 1976] Bell, T.E., Thayer, T.A., “Software Requirements: Are They Really a
Problem?”, Proceedings of the Second International Conference on Software Engineering,
San Francisco, October 1976, pp. 61-68.
[Beum-Seuk 2002] Beum-Seuk Lee and Barrett R. Bryant., “Automation of Software
System Development Using Natural Language Processing and Two-Level Grammar,”
Proceedings of Monterey Workshop, Venice, Italy, 2002.
[Bjorner 2000] Bjorner, D., “Pinnacle of Software Engineering: 25 years of Formal
Methods,” Annals of Software Engineering, 10, 2000, pp. 11-66.
[Boehm 1981] Boehm, B., Software Engineering Economics. Prentice-Hall, 1981.
[Boehm 1984] Boehm, B., “Verifying and Validating Software Requirements and Design
Specifications,” IEEE Software, January 1984, pp. 75-88.
155

[Boehm 1989] Boehm B., Ross R., “Theory W Software Project Management: Principles
and Examples,” IEEE Transactions of Software Engineering, vol. 15 ed. 7, pp 902-916,
1989.
[Boehm 1991] Boehm, B., “Software Risk Management: Principles and Practices,” IEEE
Software, vol.8, no.1, January 1991, pp. 32-41.
[Boehm 1994] Boehm, B., “Integrated Software Engineering and System Engineering,” The
Journal of NCOSE, vol. 1, no. 1, July/September 1994, pp.61-67.
[Boehm 1995] Boehm, B., Bose, P., Horowitz, E., Lee, M.J., “Software Requirements
Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach,” Proc. ICSE,
1995.
[Boehm 1998] Boehm B., Egyed A., Kwan J., Port D., Shah A., Madachy, R., “Using the
WinWin Spiral Model: A Case Study,” IEEE Computer, p. 33-44, July 1998.
[Boehm 1999] Boehm, B., Port, D., Egyed, A., Abi-Antoun, M., “The MBASE Life Cycle
Architecture Milestone Package: No Architecture Is An Island,” 1st Working Int. Conf. on
Software Architecture, 1999.
[Boehm 2001] Boehm, B., Grünbacher, P., Briggs, B., “Developing Groupware for
Requirements Negotiation: Lessons Learned,” IEEE Software, pp. 46-55, May/June 2001.
[Boehm 2002] Boehm, B., Port, D., Brown, A. W., Colbert, E., “Guidelines for Model-
Based (System) Architecting and Software Engineering.” USC-CSE, 2002.
[Boehm 2005] Boehm, B., “Guidelines for Lean Model-Based (System) Architecting and
Software Engineering – Version 1.5”, CSSE-USC, 2005.
[Bolton 1994] D. Bolton, S. Jones, D. Till, D. Furber, and S. Green., “Using domain
knowledge in requirements capture and formal specification construction,’ In M. Jirotka and
J. Goguen, editors, Requirements Engineering: Social and Technical Issues, pages 141–162.
Academic Press, 1994.
[Briggs 2001] Briggs, R.O.; de Vreede, G.-J.; Nunamaker, J.F.; and Tobey, D.H.
“ThinkLets: Achieving Predictable, Repeatable Patterns of Group Interaction with Group
Support Systems (GSS),” In, Proc. 34th Hawaii International Conference on System
Sciences. 2001: IEEE CS.
[Briggs 2002] Briggs, B., Grünbacher, P., “EasyWinWin: Managing Complexity in
Requirements Negotiation with GSS,” Proc. Hawaii Int. Conf. on System Sciences, IEEE
Comp. Soc. Press, 2002.
[Briggs 2003] Briggs, R.O., de Vreede, G.J., Nunamaker Jr., J.F., “Collaboration
Engineering with ThinkLet to Pursue Sustained Success with Group Support Systems,”
Journal of Management Information Systems, 19(4), 2003. pp. 31-63.
156

[Brooks 1995] Brooks, F.P., The Mythical Man-Month: Essays on Software Engineering.
20
th
Anniversary edition, Addition Wesley, 1995.
[Burg 1997] Burg, J. F. M. Linguistic Instruments in Requirements Engineering.
Amsterdam: IOS Press, 1997.
[Carson 2001] Carson, R. S., Shell T., “Requirement completeness: Absolute or relative?”
Systems Engineering, vol.4, no.3, 2001, pp. 230-231.
[CERN 1998] CERN, PSS–05 User Requirements Document Template, Technical report,
CERN, 1998.
[Cook 1990] Cook, S.C., “Knowledge Based Generation of Measuring Instrument
Specification,” IMEKO International Symposium on Knowledge Based Measurement, 1st,
Karlsruhe, FDR, 1990.
[Covey 1990] Covey S., The Seven Habits of Highly Effective People. Fireside Books, New
York, 1990.
[Curtis 1988] Curtis B., Krasner, H. and Iscoe, N., "A Field Study of the Software Design
Process for Large Systems," Communications of the ACM, Vol. 31, No. 11, 1988, pp. 1268-
1287.
[Davis 1990] Davis, A.M., Software Requirements: Analysis and Specification, Prentice-
Hall, Englewood Cliffs, NJ, 1990.
[Davis 1993] Davis A., et al., “Identifying and Measuring Quality in Software Requirements
Specification,” Proceedings of Software Metrics Symposium, IEEE CS Press, Los Alamitos,
California, 1993, pp. 141-152.
[Dorfman 1997] Dorfman, M. and R. Thayer, Software Engineering. IEEE Computer
Society Press, Los Alamitos, CA, pp.79, 1997.
[Duran 1999] Durán, A., Bernárdez, B., Ruiz, A., and Toro. M., "A Requirements Elicitation
Approach Based in Templates and Patterns," In WER’99 Proceedings, Buenos Aires, 1999.
[Fabbrini 1998] Fabbrini, F., Fusani, M., Gervasi, V., Gnesi, S. And Ruggieri, S.,
“Achieving Quality in Natural Language Requirements,” Proceedings of the 11th
International Software Quality Week, San Francisco, May 1998.
[Fabbrini 2001] Fabbrini F, Fusani M, Gnesi S and Lami G., “An automatic quality
evaluation for natural language requirements,” In: Proceedings of the 7th International
Workshop on Requirements Engineering: Foundation for Software Quality, Interlaken,
Switzerland, 4-5 June, 2001.
[Fagan 1976] Fagan, M., “Design and Code Inspections To Reduce Errors In Program
Development,” IBM Systems J., vol. 15, no. 3, 1976, pp. 182-211.
157

[Fantechi 2002] Fantechi, A., Gnesi, S., Lami, G., Maccari, A., “Application of Linguistic
Techniques for Use Case Analysis”, Proceedings of the IEEE Joint International
Requirements Engineering Conference, Essen, Germany, September 9-13, 2002.
[Faulk 1997] Faulk, S.R., “Software Requirements,” in Software Engineering, M. Dorfman
and R.H. Thayer, eds., IEEE Computer Society Press, Los Alamitos, CA., 1997.
[Feather 1991] Feather, M.S., and Fickas, S., “Coping with Requirements Freedom,” In
Proc. of the Intl. Workshop on the Development of Intelligent Information Systems, pages
42-46, Ontario, Canada, April 1991.
[Firesmith 2003] Firesmith, D., “Specifying Good Requirements,” Journal of Object
Technology, vol. 2, no. 4, July-August 2003, pp. 77-87.
[Firesmith 2003b] Firesmith, D., “The Business Case for Requirements Engineering,” The
11
th
IEEE International Requirements Engineering Conference, 12 September 2003.
[Gause 1989] Gause, D.C., Weinbery, G.M., Exploring Requirements: Quality Before
Design. Dorset House, New York, NY, 1989.
[Gilb 1993] Gilb, T., and Graham, D., Software Inspection. 1993: Addison-Wesley.
[Goldin 1997] L. Goldin & D.M. Berry, “Abstfinder: A Prototype Natural Language Text
Abstraction Finder for Use in Requirements Elicitation,” Automated Software Engineering
Journal, 4(4), October 1997, 375-412.
[Grünbacher 2000] Grünbacher, P., “EasyWinWin Moderator's Guidebook.” JKU Linz,
USC-CSE 2000, GroupSystems.com.
[Grünbacher 2001] Grünbacher, P., Egyed A., Medvidovic N., “Reconciling Software
Requirements and Architectures: The CBSP Approach,” Proceedings of the 5th IEEE
International Symposium on Requirements Engineering (RE), Toronto, 2001, pp. 202-211.
[Grünbacher 2004] Grünbacher, P., Halling, M., Biffl, S., Kitapci, H., Boehm, B.W.,
“Integrating Collaborative Processes and Quality Assurance Techniques: Experiences from
Requirements Negotiation,” Journal of Management Information Systems, no. 4, vol. 20,
M.E. Sharpe, Inc., pp. 9-29, 2004, ISSN: 0742-1222, 2004.
[Guttag 1993] Guttag, J., Horning, J., Larch: Languages and Tools for Formal Specification.
Springer Verlag, 1993.
[Hall 1990] Hall, A., “Seven Myths of Formal Methods.” IEEE Software, 1990, pp.11-19.
[Hall 1996] Hall, A., “Using formal methods to develop an ATC information system,” IEEE
Software, 1996, pp.66-76
158

[Halling 2003] Halling, M., Biffl, St., Grünbacher, P., “An Economic Approach for
Improving Requirements Negotiation Models with Inspection,” Requirements Engineering
Journal, Springer, 2003.
[Hsia 1993] Hsia, P., Davis, A., Kung, D., “Status Report: Requirements Engineering,“
IEEE Software, November 1993, pp. 75-79.
[Hull 2005] Hull, M.E.C., Jackson, K., Dick, A.J.J. Requirements Engineering, Second
Edition. Springer-Verlag, 2005.
[IEEE 1997] IEEE Std 1074-1997, Standard for Developing Software Life Cycle Processes.
IEEE New-York, 1997.
[IEEE 1998] IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications. IEEE New-York, 1998.
[IEEE 1998] IEEE Std 1012-1998, IEEE Standards for Software Verification and Validation.
IEEE New-York, 1998.
[James 2000] James, L., “Providing Pragmatic Advice On How Good Your Requirements
Are - The Precept "Requirements Counselor" Utility,” Proceedings of the 2000 INCOSE
Symposium.
[Jones 1986] Jones, C.B., Systematic Software Development Using VDM. Englewood
Cliffs, NJ: Prentice-Hall, 1986.
[Kassel 2003] Neil Kassel and Brian A. Malloy. “An Approach to Automate Requirements
Elicitation and Specification,” Proceedings of the 7th International Conference on Software
Engineering and Applications (SEA 2003), November 3-5, 2003, Marina del Rey, CA, USA,
pages 544-549.
[Kasser 2003] Kasser, J. E., Tran, X-L, Matisons, S. P., “Prototype Educational Tools for
Systems and Software (PETS) Engineering,” Proceedings of AAEE Conference, Brisbane
2003.
[Kasser 2004] Kasser, J. E., “The First Requirements Elucidator Demonstration (FRED)
Tool,” System Engineering, 2004.
[Kotonya 1998] Kotonya, G., Sommerville, I., Requirements Engineering: Processes and
Techniques. John Wiley & Sons, 1998.
[Lami 2005] Lami, G., "QuARS: A Tool for Analyzing Requirements," Technical Report
CMU/SEI-2005-TR-014, 2005.
[Le Charlier 1998] Le Charlier, E., Flener, P., “Specification are necessarily informal, or,
some more myths of formal methods,” Journal of Systems and Software, (3)40, March 1998,
pp. 275-296.
159

[Leffingwell 2003] Leffingwell, D., Managing Software Requirements: A Use Case
Approach. Addison-Wesley, 2003.
[Leishman 2002] Leishman, T. R., and Cook, D. A., "Requirements Risks Can Drown
Software Projects," CROSSTALK April, 2002.
[Macias 1993] Macias, B., Pulman, S.G., “Natural Language Processing for Requirements
Specification,” (In) Safety-critical Systems, Chapman and Hall, 1993, pp.57-89.
[Maiden 1998] Maiden N.A.M., Cissa M., Perez H. & Manuel D., “CREWS Validation
Frames: Patterns for Validating Systems Requirements,” Fourth International Workshop on
Requirements Engineering: Foundations for Software Quality, Pisa, Italy, 1998.
[Marcus 2004] Marcus, B. S. & Marcinkiewicz, M.A., Santorini, B., Building a large
annotated corpus of English: The Penn Treebank. In Computational Linguistics, vol. 19, no
2, 2004, pp313-330.
[Meyer 1985] Meyer, B., “On Formalism in Specifications”, IEEE Software, 2(1), 1985, pp.
6-26.
[Mich 2000] Mich L., Garigliano R., "Ambiguity Measures in Requirement Engineering,"
Int. Conf. On Software Theory and Practice - ICS 2000, Beijing, China, Aug. 2000.
[Mich 2004] L. Mich, M. Franch, and P. L. Novi Inverardi. “Market research for
requirements analysis using linguistic tools,” Requirements Engineering, 9:40-56, 2004.
[Naber 2003] Naber, D., “A Rule-Based Style and Grammar Checker”, Diploma Thesis,
Bielefeld University, Germany, 2003.
[Nanduri 1995] Nanduri, S., Rugaber, S., “Requirements Validation via Automated Natural
Language Parsing,” 28th Hawaii International Conference on System Science, 1995.
[Nikula 2000] Nikula, U., Sajaniemi, J., Kalviainen, H., “A State-of-the-Practice Survey on
Requirements Engineering in Small- and Medium-Sized Enterprises,” TBRC Research
Report 1. Telecom Business Research Center Lappeenranta, 2000.
[Nunamaker 1996] Nunamaker J, Briggs R, Mittleman D, Vogel D, Balthazard P. “Lessons
from a Dozen Years of Group Support Systems Research: A Discussion of Lab and Field
Findings,” Journal of Management Information Systems vol. 13 ed. 3, pp 163-207, 1996.
[Nuseibeh 2000] Nuseibeh. B., Easterbrook, S., “Requirements Engineering: A Roadmap,
In: A. Finkelstein (ed.),” The Future of Software Engineering, ACM Press, 2000.
[Osborne 1996] Osborne, M., MacNish, C.K., “Processing natural language software
requirement specifications,” Proceedings of the 2nd IEEE International Conference on
Requirements Engineering, IEEE Press, 1996, pp.229-236.
160

[Pohl 1994] Pohl, K., Assenova P., Doemges R., Johannesson P., Maiden, P., Plihon, V.,
Schmitt, J.R. & Spanoudakis G., “Applying AI Techniques to Requirements Engineering:
The NATURE Prototype,” ICSE - Workshop on Research Issues in the Intersection Between
Software Engineering and Artificial Intelligence, Sorrento, Italy, May 1994.
[Reubenstein 1991] H. Reubenstein & R. Walters, The Requirements Apprentice:
Automated Assistance for Requirements Acquisition, IEEE Transactions on Software
Engineering, 17(3), March 1991, 226-240.
[Richards 2003] Richards, D. “Requirements Reconciliation using a Computer Supported
Collaborative Approach,” Journal of Integrated Design and Process Science, June 2003
7(2):113-129.
[Robertson 1999] Robertson, S., Robertson J., Mastering the Requirements Process,
Addison-Wesley Professional, 1999.
[Robinson 1998] Robinson, W. N. and Pawlowski, S., “Surfacing root requirements
interactions from inquiry cycle requirements,” In Proceedings of the Third IEEE
International Conference on Requirements Engineering (ICRE’98, Colorado Springs, CO).
IEEE Computer Society Press, Los Alamitos, CA. 1998, pp.82–89.
[Rolland 1992] Rolland, C., Proix, C., “A natural language approach for Requirements
Engineering,” Proceedings of the 4th International Conference on Advanced Information
System Engineering, 1992.
[Rolland 1998] Rolland, C., Ben Achour, C., “Guiding the Construction of Textual Use Case
Specifications.” Data & Knowledge Engineering Journal, 25(1-2), 1998.
[Rosenberg 1998] Rosenberg, L., Hammer, T.F., and Huffman, L.L., “Requirements, Testing
and Metrics,” In 15
th
Annual Pacific Northwest Software Quality Conference, Utah, 1998.
[Rumbaugh 1999] Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language
Reference Manual. Addison Wesley, 1999.
[Saeki 1989] Saeki, M., Horai, H., Enomoto, H., “Software Development Process from
Natural Language Specification,” Proceedings of the 11th International Conference on
Software Engineering (ICSE-11), IEEE Computer Society Press, 1989.
[Savransky 2000] Savransky, S.D., Engineering of Creativity: Introduction to TRIZ
Methodology of Inventive Problem Solving. CRC Press LLC, 2000.
[Scott 2004] Scott, W, Cook S.C. and Kasser, J.E., “Development and Application of a
Context-free Grammar for Requirements”, in Proceedings of Systems Engineering / Test and
Evaluation Conference, SETE 2004, Focusing on Project Success, Adelaide, 2004.
[Sommerville 1997] Sommerville, I., Sawyer, P., Requirements Engineering: A Good
Practice Guide. John Wiley & Sons, 1997.
161

[Spivey 1992] Spivey, J., The Z Notation: A Reference Manual (2nd ed.). Prentice Hall,
1992.
[Student 1908] Student, “The Probable Error of a Mean,” Biometrika 6, 1908.
[Standish 1995] The Standish Group. “CHAOS Report,” West Yarmouth, MA: The Standish
Group International, Inc., 1995.
[Standish 1999] The Standish Group. “CHAOS: A Recipe for Success,” West Yarmouth,
MA: The Standish Group International, Inc., 1999.
[Standish 2003] The Standish Group. “What Are Your Requirements?” West Yarmouth,
MA: The Standish Group International, Inc., 2003.
[Waitley 1985] Waitley D., The Double Win. Berkeley Books. New York, 1985.
[Wiegers 2000] Wiegers, Karl E., “When Telepathy Won't Do: Requirements Engineering
Key Practices," Cutter IT Journal, May, 2000.
[Wile 1983] Wile, D. S., "Program developments: formal explanations of implementations,"
Communications of the ACM, v.26 n.11, p.902-911, Nov. 1983.
[Wilson 1997] Wilson WM, Rosenberg LH and Hyatt LE., “Automated analysis of
requirements specification,” In: Proceedings of the Nineteenth International Conference on
Software Engineering, Boston, MA, 18-19 May, 1997.
[Zeroual 1991] K. Zeroual, “KBRAS: A Knowledge-Based Requirements Acquisition
System,” Proc. 6th Ann. Knowledge-Based Software Eng. Conf., IEEE Computer Society
Press, Los Alamitos, Calif., 1991, pp. 38.47.
162

Appendices
Appendix A: System and Software Requirements
Definition (SSRD) Outline
The following outline is a typical list of topics that appear in the MBASE Requirements
Document. For more details check [Boehm 2002].
1 SSRD Overview
2.1 Status of SSRD
2.2 References
2 Project Requirements
2.1 Budget and Schedule
2.2 Development Requirements
2.2.1 Tools Requirements
2.2.2 Language Requirements
2.2.3 Computer Hardware Requirements
2.2.4 Computer Hardware Resource Utilization Requirements
2.2.5 Computer Software Requirements
2.2.6 Computer Communication Requirements
2.2.7 Standards Compliance Requirements
2.3 Deployment Requirements
163

2.4 Transition Requirements
2.5 Support Environment Requirements
3 Capability Requirements
3.1 Nominal Requirements
3.2 Off-Nominal Requirements
4 System Interface Requirements
4.1 User Interface Standards Requirements
4.1.1 Graphical User Interface Standards
4.1.2 Command-Line Interface Requirements
4.1.3 Diagnostics Requirements
4.2 Hardware Interface Requirements
4.3 Communications Interface Requirements
4.4 Other Software Interface Requirements
5 Level of Service Requirements
5.1 Dependability
5.2 Interoperability
5.3 Usability
5.4 Performance
5.5 Adaptability
5.6 Reusability
6 Versions, States and Modes
7 Evolution Requirements
7.1 Project Evolution Requirements
7.2 Capability Evolution Requirements
164

7.3 Interface Evolution Requirements
7.4 Level of Service Evolution Requirements
8 Appendix
165

Appendix B: Requirements Types and Attributes List
Table 27 provides an overview of which requirements attributed are mandatory (M), optional
(O), or recommended (in comments column) for each type of requirements, and for some
Life Cycle Objectives (LCO) / Life Cycle Architecture (LCA) distinctions. Evolution
requirements can have less detail than their non-evolution counter parts.
Table 27: Requirements and Attributes Overview
Attribute Project
Requirement
Capability
Requirement
Interface
Requirement
Level of
Service
Requirement
Comments
Number, Name
M M M M
Description
M M M M Unambiguous,
testable
Priority
M M M M MSCW (Must /
Should / Could /
Want to have) –
with respect to next
increment
Input(s)
M M Type and units
recommended;
other attributes
optional
Source(s)
M M
Output(s)
M M Type and units
recommended;
other attributes
optional
Destination(s)
M M
Precondition(s)
M Nominal by LCO;
critical off‐nominal
by LCA; others
optional

166

Table 27: Continued
Attribute Project
Requirement
Capability
Requirement
Interface
Requirement
Level of
Service
Requirement
Comments
Post
Condition(s)
M Nominal by LCO;
critical off‐nominal
by LCA; others
optional
Measurable
O Optional
application to other
requirements types.
Templates only for
Level of Service
requirements
Achievable
O Optional
application to other
requirements types.
Templates only for
Level of Service
requirements
Relevant
O Optional
application to other
requirements types.
Templates only for
Level of Service
requirements
Specific
O Optional
application to other
requirements types.
Templates only for
Level of Service
requirements
API’s
O
Block Diagram
O
States and
Modes
O Should be in a
separate column
Scenarios
O Nominal by LCO;
critical off‐nominal
by LCA; others
optional
Traceability
M M M M Source of the
requirement
167

Appendix C: SSRD Requirements Templates
Table 28: Template for a Project Requirement in the SSRD
Project Requirement:
Give a reference number and name
Description:
Describe this project requirement
Priority:
Describe what the priority of the requirement is e.g. high (essential to the
system), medium (important to the system), or low (desirable for the
system usage, but deferrable)
Win‐Win
Agreement(s):
Give the win‐win agreement(s) this project requirement traced from

Table 29: Template for a Capability Requirement in the SSRD
Capability Requirement:
Give a reference number
Title:
Give a title
Priority:
Give Relative importance of the process to the business
Description:
Describe this capability requirement
Input(s):
Describe the input(s) of this functionality
Source(s):
Describe the source(s) of the input(s)
Output(s):
Describe the output(s) of this functionality
Destination(s):
Describe the destination of the output(s)
Precondition(s):
Describe the state(s) that workers, outside actors, and artifacts should
be in before functionality performed
Post Condition(s):
Describe the state(s) that workers, outside actors, and artifacts are in
after functionality performed
Win‐Win Agreement(s):
Give the win‐win agreement(s) this functionality traced from
168

Table 30: Template for a System Interface Requirement in the SSRD
System Interface
Requirement:
Give a reference number and name
Description:
Describe any applicable requirements on how the software should
interface with other software systems or users for input or output
Priority:
Describe what the priority of the requirement is e.g. high (essential to
the system), medium (important to the system), or low (desirable for
the system usage, but deferrable)
Win‐Win Agreement(s):
Give the win‐win agreement(s) this interface requirement traced from

Table 31: Template for a Level of Service Requirement in the SSRD
Level of Service
Requirement:
Give a reference number and name
Description:
Describe this Level of Service requirement
Priority:
Describe what the priority of the requirement is e.g. high (essential to the system),
medium (important to the system), or low (desirable for the system usage, but
deferrable)
Desired Level:
Describe what the desired level of service is for this service requirement
Accepted Level:
Describe what the acceptable level of service is for this service requirement
Measurable:
Indicate how this requirement can be measured with respect the specific
elements, include baselines, min and max tolerance, typical or expected values,
etc.
Achievable:
Describe briefly an approach of how this requirement is be satisfied, referring to
the analysis in Feasibility Rationale Description (FRD) for rationale as to why it is
possible within the constraints of other requirements and the design specified in
the System and Software Architecture Description (SSAD)
Relevant:
Describe which Capability Requirements this requirement is relevant to
Specific:
Describe what elements in particular within the Capability Requirements this
requirement involves
Win‐Win
Agreement(s):
Give the win‐win agreement(s) this service requirement traced from
169

Appendix D: Penn Treebank Tag Set
Here are the most important tags (see Table 32). For additional information check [Marcus
2004]
Table 32: Penn Treebank Tag Set
Tag Tag Description Example
CC Conjunction, coordinating and, or
CD Adjective, cardinal number 3, fifteen
DET Determiner this, each, some
EX Pronoun, existential there There
FW Foreign words
IN Preposition / Conjunction for, of, although, that
JJ Adjective happy, bad
JJR Adjective, comparative happier, worse
JJS Adjective, superlative happiest, worst
LS Symbol, list item A, A.
MD Verb, modal can, could, 'll
NN Noun aircraft, data
NNP Noun, proper London, Michael
NNPS Noun, proper, plural Australians, Methodists
NNS Noun, plural women, books
PDT Determiner, prequalifier quite, all, half
POS Possessive 's, '
PRP Determiner, possessive second mine, yours
PRPS Determiner, possessive their, your
RB Adverb often, not, very, here
170

Table 32: Continued
Tag Tag Description Example
RBR Adverb, comparative Faster
RBS Adverb, superlative Fastest
RP Adverb, particle up, off, out
SYM Symbol *
TO Preposition to
UH Interjection oh, yes, mmm
VB Verb, infinitive take, live
VBD Verb, past tense took, lived
VBG Verb, gerund taking, living
VBN Verb, past/passive participle taken, lived
VBP Verb, base present form take, live
VBZ Verb, present 3SG ‐s form takes, lives
WDT Determiner, question which, whatever
WP Pronoun, question who, whoever
WPS Determiner, possessive & question whose
WRB Adverb, question when, how, however
PP Punctuation, sentence ender ., !, ?
PPC Punctuation, comma ,
PPD Punctuation, dollar sign $
PPL Punctuation, quotation mark left “
PPR Punctuation, quotation mark right “
PPS Punctuation, colon, semicolon, elipsis :, ..., ‐
LRB Punctuation, left bracket (, {, [
RRB Punctuation, right bracket ), }, ]
171

Appendix E: Typical Problems for EasyWinWin
Requirements Negotiation
The IV&Vers check the WinWin artifacts according to the problems given in Table 33.
Table 33: Typical Problems in WinWin Artifacts
Typical Problem Definition
Incomplete
statement
Missing information
The information needed to clearly specify it may not be available at
the time of writing
Unclear statement
Contain words/phrases that introduce a degree of ambiguity into the
statement
Incorrect statement
The information provided is not exactly correct
Unverifiable
statement
Ambiguous terms
Contain words that introduce ambiguity for how to measure or test
the statement
Composite statement
Contain more than one statement, or idea
Negative statement
Express in the negative terms of what the system must not do
Typo error
Typing error, wrong word(s)
172

Appendix F: Software Engineering (SE) Course Projects
Table 34: List of Real-Client Projects for SE Course in fall 2005
Pr.
# Project Name Project Type Community
1
Open Source Discussion Board and Research Platform
‐ I
Interactive
Communication USC
2 Physics Education Research (PER) Web‐based USC
3 Pasadena High School Computer Network Study Computer Networking
Neighborhood
community
4 Virtual Football Trainer System Virtual Reality USC
5 Data Mining PubMed Results Data Analysis
Neighborhood
community
6 USC Football Recruiting Database
Automated Reference
Services USC
7 USC Equipment Inventory Database Inventory Database USC
8 Data Mining of Digital Library Usage Data Data Analysis USC
9 J2EE‐based Session Management Framework Extension Data Analysis Industry
10 Code Generator ‐ Template based Data Conversion Industry
11 dotProject and Mantis integration
Activity Monitoring
and Control Industry
12
Mule as a highly scalable distributed framework for
data migration Data Migration Industry
13 Develop a Web Based XML Editing Tool Data Migration USC
14 CodeCount Product Line with XML and C++ ‐ I Data Analysis CSSE, USC
15 COSYSMO Extension to COINCOMO
COTS Package
Extension CSSE, USC
16 Intelligent, 'diff'ing CodeCount Superstructure Data Analysis CSSE, USC
19 EBay Notification System Data Analysis Affiliate
21 Rule‐based Editor Data Processing Industry
22
Open Source Discussion Board and Research Platform
‐ II
Interactive
Communication USC
23 CodeCount Product Line with XML and C++ ‐ II Data Analysis CSSE, USC
173

Table 35: List of Real-Client Projects for SE Course in fall 2006
Pr.
# Project Name Project Type Community
1 California Science Center Newsletter System
Selective Dissemination of
Information
Neighborhood
community
2 California Science Center Event RSVP System
Activity Monitoring and
Control
Neighborhood
community
3
California Science Center Volunteer Tracking
System
Activity Monitoring and
Control
Neighborhood
community
4 Credit Card Theft Monitoring Project Data Analysis
Neighborhood
community
5 VBSE Game Game Evolution Analysis CSSE, USC
6 USC Diploma Order / Tracking Database System
Automated Reference
Services USC
7
USC Civil and Community Relations (CCR) Web
Application
Activity Monitoring and
Control USC
8 Student's Academic Progress Web Application
Selective Dissemination of
Information
Neighborhood
community
9 Personal Care Technology Help Line Interactive Communication
Neighborhood
community
10 Video Uploading and Conversion System Data Migration Industry
11 New Economics for Woman (NEW) Multimedia Archive
Neighborhood
community
12 Eclipse COCOMO II COTS Package Extension CSSE, USC
13 Web Portal for USC Electronic Resources COTS Package Extension USC
14 Early Medieval East Asian Tombs
Multimedia/Information
Archive USC
15 LANI Database Management System COTS Package Extension
Neighborhood
community
16 USC CONIPMO Data Analysis Industry
17 UAV Sensor Planning
Activity Monitoring and
Control CSSE, USC
18 Electronic Data Discovery COTS Package Extension
Neighborhood
community
19 An Eclipse Plug‐in for Use Case Authoring COTS Package Extension Industry
20 Online Requirements Negotiation Support System Data Migration CSSE, USC
21 African Millennium Foundation Multimedia Archive
Neighborhood
community

Abstract (if available)

Abstract For many software and systems developers, Requirements Engineering is one of the biggest problems they face. Without an accurate, consistent, and complete requirements specification it is very difficult to develop, change, and maintain software. It is now a generally accepted and frequently stated fact that one of the major causes of software development failures is poor requirements engineering. The CHAOS Surveys by the Standish Group report that 15% of the projects fail outright, and 51% are late, run over budget or provide reduced functionality. On average only 54% of the initial project requirements are delivered to the client. Inadequate specification of system requirements is considered to be one of the main causes for project failure.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

The incremental commitment spiral model process patterns for rapid-fielding projects

PDF

Deriving component‐level behavior models from scenario‐based requirements

PDF

WikiWinWin: a Wiki-based collaboration framework for rapid requirements negotiations

PDF

Security functional requirements analysis for developing secure software

PDF

A reference architecture for integrated self‐adaptive software environments

PDF

Quantitative and qualitative analyses of requirements elaboration for early software size estimation

PDF

Automated synthesis of domain-specific model interpreters

PDF

Using social networking technology to improve collaborative requirements elicitation, negotiation, prioritization and evolution

PDF

Using metrics of scattering to assess software quality

PDF

Architectural evolution and decay in software systems

PDF

Shrinking the cone of uncertainty with continuous assessment for software team dynamics in design and development

PDF

Techniques for methodically exploring software development alternatives

PDF

Quantifying the impact of requirements volatility on systems engineering effort

PDF

Automated repair of presentation failures in Web applications using search-based techniques

PDF

Formal analysis of data poisoning robustness of K-nearest neighbors

PDF

The effects of required security on software development effort

PDF

A search-based approach for technical debt prioritization

PDF

Assessing software maintainability in systems by leveraging fuzzy methods and linguistic analysis

PDF

Learning logical abstractions from sequential data

PDF

Integration of digital twin and generative models in model-based systems upgrade methodology

Asset Metadata

Creator Kitapci, Hasan (author)

Core Title Formalizing informal stakeholder inputs using gap-bridging methods

School Viterbi School of Engineering

Degree Doctor of Philosophy

Degree Program Computer Science

Publication Date 11/26/2007

Defense Date 07/27/2007

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag gap-bridging methods,hybrid method,inspection,keyword analysis,natural language processing,OAI-PMH Harvest,requirements definition,requirements engineering,requirements negotiation,requirements transformation,requirements validation,template refinement,winwin methodology

Language English

Advisor Boehm, Barry W. (committee chair), Medvidovic, Nenad (committee member), Settles, F. Stan (committee member)

Creator Email kitapci@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-m942

Unique identifier UC1322926

Identifier etd-Kitapci-20071126 (filename),usctheses-m40 (legacy collection record id),usctheses-c127-598488 (legacy record id),usctheses-m942 (legacy record id)

Legacy Identifier etd-Kitapci-20071126.pdf

Dmrecord 598488

Document Type Dissertation

Rights Kitapci, Hasan

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Repository Name Libraries, University of Southern California

Repository Location Los Angeles, California

Repository Email cisadmin@lib.usc.edu