Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
An approach to software project management through requirements engineering
by
Henry Johnson, B.Tech
A Thesis
In
COMPUTER SCIENCE
Submitted to the Graduate Faculty
of Texas Tech University in
Partial Fulfillment of
the Requirements for
the Degree of
MASTER OF SCIENCE
Approved
Dr. Joseph Urban
Chairperson of the Committee
Dr. Michael Shin
Dr. Ralph Ferguson
Dean of the Graduate School
December, 2010
Copyright 2010, Henry Johnson
Texas Tech University, Henry Johnson, December 2010
ii
ACKNOWLEDGMENTS
I thank my professor, Dr. Joseph Urban, for his guidance, inspiration, and
patience in making this research successful. Special thanks to Dr. Michael Shin, for
serving on my thesis committee and for his reviews and suggestions.
I thank my wife, Shema Mathew, and my parents in supporting me in all hardship.
I am grateful to all my friends and colleagues at Texas Tech University, Lubbock,
for their extended support during my master‟s.
Texas Tech University, Henry Johnson, December 2010
iii
TABLE OF CONTENTS
ACKNOWLEDGMENTS ................................................................................................ ii ABSTRACT ....................................................................................................................... v
LIST OF TABLES ........................................................................................................... vi LIST OF FIGURES ........................................................................................................ vii I INTRODUCTION .......................................................................................................... 1
1.1 State of Problem ....................................................................................................... 1 1.2 Research Objectives ................................................................................................. 1 1.3 Research Methodology ............................................................................................ 3
1.4 Benefits of the Completed Research ........................................................................ 4 1.5 Summary .................................................................................................................. 5
II AN OVERVIEW OF REQUIREMENTS ENGINEERING TOOLS ....................... 6 2.1 Introduction ............................................................................................................. 6 2.2 Software Requirements and Formal Specification ................................................. 7 2.3 Requirements Engineering Process and its Tool Support ........................................ 8
2.3.1 Requirements Elicitation ................................................................................................ 9 2.3.2 Requirements Analysis .................................................................................................. 9 2.3.3 Requirements Negotiation ........................................................................................... 11 2.3.4 Requirements Documentation .................................................................................... 12 2.3.5 Requirements Validation ............................................................................................. 12
2.4 Requirements Engineering Tool Comparison ......................................................... 13
2.5 Advancement in Requirements Engineering Tool Support ................................... 15 2.6 Research Efforts on CASE Tools .......................................................................... 16
2.6.1 Natural Language Processing Tool Research ............................................................ 16 2.6.2 EA – Miner Tool .......................................................................................................... 18 2.6.3 Software Project Management Support Tool .............................................................. 20 2.6.4 Intelligent Risk Management Tools for Software Development .................................. 21
2.7 Summary ................................................................................................................ 23
III AN OVERVIEW OF DESCARTES SPECIFICATION LANGUAGE ................ 24 3.1 Introduction ............................................................................................................. 24 3.2 Data Structuring ...................................................................................................... 25
3.3 Specification Construction Using Descartes ........................................................... 28
3.4 An Example Specification ...................................................................................... 31 3.5 Summary ................................................................................................................. 32
IV REQUIREMENTS TOOL EVALUATION CRITERIA ....................................... 33 4.1 Introduction ............................................................................................................. 33 4.2 Evaluation Criteria and Procedure .......................................................................... 33
4.3 Tool Evaluations ..................................................................................................... 37 4.4 Summary ................................................................................................................. 39
V REQUIREMENTS FOR THE PROPOSED CASE TOOL ..................................... 41 5.1 Introduction ............................................................................................................ 41 5.2 Web-Based Tool ................................................................................................... 42 5.3 Requirements Engineering and Design .................................................................. 45
5.3.1 Requirements Management ........................................................................................ 46 5.3.2 Requirements Verification and Validation .................................................................... 48
Texas Tech University, Henry Johnson, December 2010
iv
5.4 Software Project Management Capabilities .......................................................... 51
5.5 Software Testing and Maintenance ....................................................................... 54 5.6 Implementation Methods ...................................................................................... 55 5.7 Validation of Requirements for the Proposed CASE tool ..................................... 57
5.8 Summary ................................................................................................................ 59
VI EVALUATION OF THE PROPOSED CASE TOOL BASED ON IEEE STD. 830-
1998................................................................................................................................... 61 6.1 Introduction ............................................................................................................ 61 6.2 Evaluation Based on IEEE std. 830-1998 .............................................................. 61
6.3 Summary ................................................................................................................ 65
VII SUMMARY AND FUTURE WORK ...................................................................... 66 7.1 Summary ................................................................................................................ 66 7.2 Future work ............................................................................................................ 68
REFERENCES ................................................................................................................ 70
Texas Tech University, Henry Johnson, December 2010
v
ABSTRACT
A software development process is a complex activity. As the demand for more
complex and effective software systems is increasing day by day, software project
managers and team members are expected to release the product in a less time. This
research effort compared previous research efforts on software requirements engineering
tools and project management tools similar to this thesis. The new Computer Aided
Software Engineering (CASE) tool presented in this thesis provides a platform for
software project management with significance for requirements engineering. The CASE
tool requirements presented in the thesis reduced the gap between the requirements
engineering phase and the design phase. This research effort has included the comparison
and evaluation of different requirements engineering support tools using IEEE std. 830-
1998 evaluation criteria. A new set of evaluation criteria was formalized in this research
to evaluate implemented CASE tools. The CASE tool requirements presented in this
thesis uses the Descartes specification language to analyze the requirements. This
research also provides an academic case study for an effective requirements engineering
process in software development.
Texas Tech University, Henry Johnson, December 2010
vi
LIST OF TABLES
2.1 Comparison of web-based requirements engineering tools ........................................ 14
4.1 Evaluation of the requirements engineering tools ...................................................... 38
4.2 Evaluation of the requirements engineering tools using the IEEE std. 830-1998 ...... 39
5.1 Traceability of operational features to primary requirements ..................................... 59
Texas Tech University, Henry Johnson, December 2010
vii
LIST OF FIGURES
3.1 Specification to output the number of words of an input document ........................... 31
5.1 Use Case diagram for the web-based CASE tool ....................................................... 45
5.2 Flow chart for the analysis of requirements to identify classes and the relationship
between classes. .......................................................................................................... 50
Texas Tech University, Henry Johnson, December 2010
1
CHAPTER I
INTRODUCTION
1.1 State of Problem
The current Computer Aided Software Engineering (CASE) tools for software project
development have many drawbacks in performing requirements engineering analysis and
software project management. Requirements engineering includes a process of
negotiating the final requirements for a software project [Luqi2007]. The existing tools
provide a software requirements management platform where the stakeholders and the
project team could create requirements for later reference. The automation of the
requirements in developing specifications, designing, and coding of the software has not
been achieved yet. Another problem faced in software projects is that the stakeholders of
a software project participate in the project from different geographical locations. A
solution is a web-based CASE tool that allows the stakeholders of a software project to
collaborate and access information from different geographical locations. The thesis
research included an evaluation of different tool capabilities and an analysis of the
specification of the proposed CASE tool that would provide support for software project
management and requirements engineering. The new tool will also reduce the gap
between the requirements engineering phase and the design phase.
1.2 Research Objectives
The thesis research objectives were to create a specification of a web-based software
tool for automation of software specification, designing and coding from the collected
Texas Tech University, Henry Johnson, December 2010
2
requirements. In software project development, the main constraints are time and
resources. The generated software tool Software Requirements Specification (SRS) from
this research has made way for the development of the proposed CASE tool. This CASE
tool will decrease the time and effort for the tasks performed in the software development
process. This reduction of time and effort in a software development process will be
possible by the automation of software development and project management through the
use of formal analysis. The proposed CASE tool was integrated with a web-based
capability where the stakeholders and the project team will be able to collaborate and
work together irrespective of their geographical location [Barney2008]. The objectives of
the proposed research were:
1. Evaluation of the features of some of the web-based software specification tools
to understand the effectiveness of these tools. The evaluation of these tools is set
using the evaluation criteria of the IEEE std. 830 -1998, recommended practice
for software requirement specification;
2. Use the Descartes executable specification language to understand the capabilities
of the language to produce a tool. The Descartes specification language gives a
specification as output from a set of requirements written in natural language;
3. Analysis of the features of the proposed software tool that could be developed for
the future. Generation of a specification from the software requirements, code
generation and formal analysis of resources are the planned research objectives.
Formal analysis includes project planning, estimations and risk management
Texas Tech University, Henry Johnson, December 2010
3
which will be included in the new tool that will help the software project
managers in the software projects;
4. A written specification of the new tool will be the final outcome of the proposed
research. The final report of the thesis research will include the conclusions from
the above three objectives
5. Improvement in CASE tools to provide support over the software development
life cycle of the software system is the main goal of the research.
1.3 Research Methodology
As discussed in Section 1.2 the final objective of the research is to create a
specification for the proposed CASE tool. The research effort consisted of these parts:
1. Acquiring the information from different software tools: Evaluation of some
existing major free software tools that support software specification and software
project management. The software tools were evaluated upon their features,
usability, robustness, functionality and enhancements. The tools were evaluated
by a set of criteria which were developed through the course of the research.
2. Adding new features: The proposed tool specification comprised of advanced
features for automation in software development. A research effort was made to
automate the software development process.
3. Understand the Descartes specification language: The Descartes specification
language is used to create the output specifications from a given input. The
Texas Tech University, Henry Johnson, December 2010
4
Descartes language has been useful in understanding how to analyze a
specification from the software requirements.
4. Specification for the new tool: the research has resulted in a document consisting
of the specifications for the proposed CASE tool. The new tool should be able to
create software specifications from natural which will help the users to simply the
transition to the next phase of software development life cycle [Weigang1997].
The proposed CASE tool specifications will make way to future development and
enhancements of the tool.
5. The research documentation had been done simultaneously with the research.
Each of the research finding will be well documented along with end results in the
final report.
1.4 Benefits of the Completed Research
A tool that could help in both requirements engineering and software project
management is important for any software development. The benefits of the completed
research are as follows.
1. Evaluation of the tools presently available in the market will give an
understanding of how computer aided software engineering tools have proved
successful. A chart of different web based project tools with their characteristics
and features will make the selection of the software tools for software
development much easier;
Texas Tech University, Henry Johnson, December 2010
5
2. The ability of the proposed CASE tool should automate software requirements
analysis. The resulting Software Requirement Specification (SRS) from the
research could be used for the actual development of the tool; and
This research effort helps in achieving the automation of the design phase and the coding
phase of software life cycle from the software requirements through the use of CASE
tools.
1.5 Summary
In this chapter, the work presented in the thesis is outlined in four sections. Section 1.1
explained the state of the problem. Section 1.2 described the objectives of the research.
Section 1.3 explained the method of the research. Section 1.4 explained the benefits of
the proposed research.
The following chapter discusses an overview of the requirements engineering tools and
a survey of some of the requirements engineering tool research efforts in improving the
tool productivity in software projects. In Chapter III, an overview of the Descartes
specification language is discussed. The tool evaluation criteria and tool evaluations are
described in Chapter IV. Chapter V describes the Software Requirements Specification of
the proposed CASE tool and Chapter VI describes the evaluation of the proposed CASE
tool. Chapter VII concludes the thesis with the summary and future work.
Texas Tech University, Henry Johnson, December 2010
6
CHAPTER II
AN OVERVIEW OF REQUIREMENTS ENGINEERING TOOLS
2.1 Introduction
This chapter briefly describes some of the tools that support the requirements
engineering process in software projects. A requirements engineering tool denotes a
Computer-Aided Software Engineering (CASE) tool that supports the requirements
engineering process. This chapter also describes some of the previous research efforts to
produce a software project management support tools and software requirements
engineering tools. Computer Aided Software Engineering (CASE) has proved useful in
quality software development. The CASE tools are used for different processes of the
software life cycle. Software requirements engineering tools and software project
management tools are used in software development processes in software industries. The
following sections discuss the CASE tool research efforts in the recent years which are
similar to this thesis research. This chapter is divided into six sections, namely, software
requirements and formal specifications, requirements engineering process and its tool
support, advancement in requirements engineering tool support, requirements engineering
tools, related research on CASE tools, and summary of the chapter.
The key aspects of a requirements engineering tool is to improve the effectiveness of
the requirements engineering process, reduce time and effort of software development,
and reduce the failure rate of a software project [Kotonya2003]. The requirements
Texas Tech University, Henry Johnson, December 2010
7
engineering process is the backbone of every software project. Many of the requirements
engineering tools in the market provide support in requirements management. The
requirements engineering process is the process of understanding end-user needs,
customer expectations, and acquirer‟s conditions and documenting the requirements. The
documented requirements are known as Concept of Operations document or Software
Requirements Specification (SRS). The requirements management process usually
denotes the process of documenting the requirements for future software development in
a readable format. The process automation of software specification and verification of
requirements documents are not yet available in the present requirements engineering
tools. Software specification is a document consisting of technical requirements in
standard format which reduces the gap between the requirements analysis and the
software design phases.
2.2 Software Requirements and Formal Specification
Software requirements are the definition of what the system should perform. Software
requirements consist of functional, non-functional, structural, and architectural
requirements [Kotonya2003]. A functional requirement defines a function of a software
system or its component. A function is described as a set of inputs, the behavior, and
outputs. Non-functional requirements deal with the quality of the system. Structural
requirements explain what has to be done by identifying the necessary structure of
a system. An architecture description is the standards, specifications, and formal
description of a system, organized in a way that supports reasoning about the structural
Texas Tech University, Henry Johnson, December 2010
8
properties of the system [Kotonya2003]. Non-functional requirements should explain all
the constraints or obstacles, quality attributes of the system, and goals of the system in
software design or implementations. The requirements engineering process is a feedback
process where the end-user and the stakeholders negotiate and finalize a software
requirements document consisting of the four types of requirements discussed earlier.
The requirements may change in every stage of negotiation and those changes produce a
new set of requirements.
In the field of computer science, the term formal specification is a mathematical
description of how the software (or hardware) should perform. In software development,
a formal specification is used to refine a requirements document. By the approach of
software development using formal specifications, it is possible to apply formal
verification techniques to demonstrate the correctness of system designs with respect to
the specification. This method of verifying the system design reduces the risk of loss of
investment on a faulty system. A formal specification enables the generation of test data
in the software testing and maintenance phases. Thus, generation of correct software
specifications should be a major milestone in every software development.
2.3 Requirements Engineering Process and its Tool Support
Different organizations tackle the requirements engineering process in different ways.
Most of the organizations have a common set of activities in the requirements
engineering process. Some of the major activities of the software requirements process
are discussed below with their tool support.
Texas Tech University, Henry Johnson, December 2010
9
2.3.1 Requirements Elicitation
Requirements elicitation is the activity in which system requirements are discovered
through consultation with the stakeholders, from system documents, domain knowledge
and market studies. In this activity, the stakeholders of the software project, the end user,
domain experts, and the requirements engineers discuss the set of requirements of the
project. This process is called an „interview‟. The discussed requirements are documented
in natural language. The requirements are partitioned into different categories for future
references. The tool support required for requirements elicitation is a word processor that
enables the user to input the requirements in natural language and then store each
requirement in the requirements engineering tool. The requirements engineering tool
should also allow the user to group the requirements under a particular category name. In
the process of requirements elicitation, the requirements raise conflicts among the
stakeholders. Requirements prioritization in a requirements engineering support tool
allows the stakeholders to set priorities to identify critical requirements and help the
decision making process.
2.3.2 Requirements Analysis
The process of requirements analysis is the process following requirements
elicitation. Each requirement is analyzed in detail and the stakeholders negotiate to
decide the accepted requirements [Kotonya2003]. In requirements analysis and
negotiation, the requirements are explained to the stakeholders with techniques such as
prototyping. Through requirements analysis and negotiation, stakeholders of the software
Texas Tech University, Henry Johnson, December 2010
10
obtain a clear understanding of the software requirements. Some of the activities in
software requirements analysis are as follows.
1. Necessity checking
The need for the requirements is analyzed in this activity. The requirements may
not contribute to the business goals of the organization or the specific problem addressed
in the project. The requirements engineering tools can provide a platform to the user to
check the set of requirements and edit those requirements if required [Kotonya2003].
2. Consistency and Completeness checking
The requirements are cross-checked for consistency and completeness
[Kotonya2003]. Consistency means that no requirements should be contradictory to other
requirements in the document; and completeness means that no services or constraints
which are needed are missed out. The requirements engineering tools support this process
by the ability of analyzing each requirement for any particular words called poor words
such as “shall”, “etc”, and “or”.
3. Prototyping
Prototyping is the technique by which the stakeholders obtain an understanding of
what the requirements of the system should perform [Kotonya2003]. Kotonya and
Sommerville explained, some of the prototype implementation methods which are
discussed below.
1. Paper prototyping: Paper prototyping allows the engineers to generate a graphical
representation of the output of the system on a piece of paper. Paper prototyping
improves the understanding of what the user wants from the system.
Texas Tech University, Henry Johnson, December 2010
11
2. „Wizard of Oz‟ prototyping: In the “Wizard of Oz‟ prototyping, an individual
simulates the responses of the system in response to the inputs from the user.
3. Automated prototyping: An engineer produces a system output for a particular
requirement for the user to create a more precise picture of the system capability.
In this method, a rapid development environment is used to develop an executable
prototype.
The requirements engineering support tools could provide features that could automate
the generation of prototypes or allow the requirements engineers to develop the
prototypes. Visual programming languages such as Visual Basic or ObjectWorks are
some of the tools that could be integrated to these requirements engineering support tools.
2.3.3 Requirements Negotiation
Requirements negotiation is the process of negotiating the elicited requirements
between the stakeholders and developers of the software project. The negotiations could
result in change with the requirements. The changed requirements are added with date of
change and the name of the person that initiated the change to the requirements document
along with the original requirements. Requirements negotiation leads to a set of agreed
requirements. Since real world software development projects undertake in a wide
geographical area, the requirements engineering tools should be web-based with a
distributed database and multiple user access. Distributed database allows users of the
requirements tool to track changes in the requirements and store the requirements in
Texas Tech University, Henry Johnson, December 2010
12
multiple locations. The distributed database can be controlled by a central database
management system (DBMS).
2.3.4 Requirements Documentation
All the requirements are documented at the appropriate levels of details. The
requirements document which is also known as Software Requirements Specification
(SRS) is created to be understood by all stakeholders of the project. Thus, these
documents are written in natural language and diagrams. As discussed earlier in this
chapter, requirements engineering support tools provide a word processor. The
documentation of the requirements is carried out at every stage of the requirements
engineering process. To produce a requirements document as a text file, export
functionality simplifies the process of creating a text file in different formats from the
database. The requirements document may also contain diagrams of the prototype of the
system. Therefore, the tool should also allow the user to attach diagrams while
documenting the requirements.
2.3.5 Requirements Validation
IEEE standard 830-1998 is the recommended standard for a good Software
Requirements Specification (SRS). The IEEE std. 830-1998 recommended practice of
software requirements engineering recognizes some characteristics for checking the
effectiveness of the requirements. Requirements verification allows the user to check for
the above characteristics of a requirements document. A requirements document is said to
Texas Tech University, Henry Johnson, December 2010
13
be complete and correct if the above characteristics are verified. The verification of any
requirements document is a time consuming process. The automation of requirements
verification could be the most important feature of any requirements engineering support
tool. The research effort by Kiyavitskaya, Zeni, Mich and Berry [Kiyavitskaya2008] uses
parse trees to process a software requirements document written in natural language.
2.4 Requirements Engineering Tool Comparison
The present requirements engineering tools are mostly requirements management
tools that are used to store the requirements. The tools are equipped with features for
manually verifying the requirements, modeling, and analyzing the requirements. The
tools selected for the tool comparison are web-based requirements management tools that
are used extensively in the software industries. The tools selected were Accept 360
[Accept2010], Rational DOORS [DOORS2010], Accompa [Accompa2010], CORE
[Core2010], Cradle 6.3 [Cradle2010], Rational Focal Point [Focalpoint2010], and
CaliberRM [Caliber2010].
Table 2.1 shows a comparison of the web based tools. The tools selected were web-
based tools. The features compared were web-based, requirements management, software
project management capabilities, automated requirements verification, extension to all
phases of software development, and communication between users. All the tools
evaluated do not provide the automated requirements verification. The evaluated tools
also lack in reducing the gap between the requirements engineering phase and other
Texas Tech University, Henry Johnson, December 2010
14
phases of software development. Most of the tools does not provide support to all the
phases of the software development life cycle. Some of the evaluated tools Accept 360,
Accompa, and Focal point provide the software project management capabilities. The
project management capability of Accept 360 included agile development methods, risk
management and project planning methods. The Accompa requirements engineering tool
provides risk management and collaborate with customers and internal stake holders. The
Rational Focal Point tool provides risk management, customer collaboration.
Table 2. 1: Comparison of web-based requirements engineering tools
Tools
Features
Web -
based
tool
Require-
ments
manage-
ment
Software
project
manageme-
nt
capabilities
Automated
Requirements
verification
Extension to
all phases of
software
development
Commu-
nication
between
users
Accept 360
Yes Yes Yes No No Yes
Rational
DOORS
Yes Yes No Yes No No
Accompa
Yes Yes Yes No No Yes
CORE Yes Yes No No Yes Yes
Cradle 6.3
Yes Yes No No No Yes
Rational
Focal
Point
Yes Yes Yes No No Yes
CaliberR
M
Yes Yes No No No Yes
Texas Tech University, Henry Johnson, December 2010
15
2.5 Advancement in Requirements Engineering Tool Support
Software development can take place from different geographical areas. This
geographical distribution in software projects has raised interest in a web-based
Computer-Aided Software Engineering (CASE) tool. The CASE tools of the future are
expected to be developed as web applications. These web-based CASE tools should
accommodate the features such as high level security, centralized control and automation
in requirements analysis, and verification. These features should be included in the future
development of requirements engineering support tools.
Requirements engineering support tools should not be restricted to the requirements
engineering phase. These tools should be able to support the entire software development
life cycle including the software testing and maintenance phase. This thesis research
effort has introduced a CASE tool that can reduce the gap between the requirements
engineering phase and rest of the software development life cycle. The method used in
the proposed CASE tool is automatically generating specifications from the requirements
document. This process is extended to a requirements engineering tool by use of the
Descartes specification language developed by Urban [Urban1977]. The use of formal
analysis provides software project managers with the ability to automatically estimate
and plan a software project. The proposed CASE tool is extended with support for
software planning, risk management, and quality assurance.
Texas Tech University, Henry Johnson, December 2010
16
2.6 Research Efforts on CASE Tools
This section discusses the research efforts on requirements engineering tools and
software project management tools. The requirements engineering tool research described
in this section points out the method used in automation of requirements verification and
validation. The software project management tool research efforts in this section explain
the enhancements required in software project management tools. The research efforts
explained in this section were selected since they are similar to the proposed CASE tool
explained in this thesis. The tool described in each research effort explains the
automation and improvement of both the requirements engineering and the software
project management tool support. The features of the tools explained in this section are
compared with the features in the proposed CASE tool.
2.6.1 Natural Language Processing Tool Research
LOLITA is natural language processing system which uses parse trees. In the paper
by Kiyavitskaya, Zeni, Mich and Berrry [Kiyavitskaya2008] describe the research
conducted on software specification tools.
Methodology: The paper described a two step approach to identify ambiguities during
natural language processing. First, the tool applies a set ambiguity measures in order to
identify ambiguity and then the tool shows what specifically is potentially ambiguous in
the analyzed sentence.
Texas Tech University, Henry Johnson, December 2010
17
The methodology used in the research is by case study on an existing natural language
processing system called LOLITA. T1 and T2 are the phases of the described tool design
in the paper which are formulated from LOLITA.
Features: LOLITA is a tool used for calculating lexical, syntactic, and semantic
ambiguities of words and sentences. With the method of calculating lexical, syntactic,
and semantic ambiguities of words and sentences, the new tool described in the paper has
the following features:
1. T1
Each sentence of a natural language requirements specification is numbered. Each
sentence is then analyzed and a penalty weighted ambiguity is assigned. A word in a
sentence S is italicized with the highest syntax-weighted lexical ambiguity. The penalty-
weighted ambiguity has a low value of 1 and a high value of 72 where the value of
greater than or equal to 20 means highly ambiguous. Thus, the tool identifies the potential
ambiguous sentences in the specification document.
2. T2
In the second phase of the tool, the identified ambiguous sentences are analyzed to find
the potential ambiguity in the sentence. Through this research effort, the authors
concluded that the most common problems were
(a) use of plural;
(b) presence of passive voice;
(c) presence of definite articles with no referents; and
Texas Tech University, Henry Johnson, December 2010
18
(d) use of synonyms.
Comparison: The research result described above explains how to automatically check
ambiguity in a natural language document using a software tool. The research effort in
this thesis is a tool that can generate software specification from natural language using
the language developed by Urban [Urban1977] called the Descartes specification
language. This related research effort helps in understanding how to determine an
ambiguous requirement.
2.6.2 EA – Miner Tool
Another example of automation in requirements engineering is the EA-Miner tool
which was developed at the Lancaster University Computing Department
[Sampaio2005]. EA-Miner is an automation tool used in Aspect-Oriented requirements
identification.
Methodology: Aspect Oriented Requirements Engineering (AORE) is a requirements
engineering process that helps to modularize requirements and effectively achieve the
separation of crosscutting concerns at the requirements level. Crosscutting concerns are
comprised of security, distribution and real-time constraints. The authors describe an
extension to a software requirements engineering tool that automatically identifies the
ambiguities in the specification document.
Texas Tech University, Henry Johnson, December 2010
19
Features: The EA-Miner tool uses the WMATRIX natural language processor to pre-
process the requirements document in natural language. WMATRIX uses part-of-speech
and semantic tagging, frequency analysis, and concordances to identify ambiguities. The
WMATRIX identify base concern, the early aspects and crosscutting relations using the
Natural Language Processing (NLP) features. Each sentence in the requirements
document is decomposed into a single requirement. The output of the WMATRIX
processor is an XML file containing parts of speech and semantic tagging for each word
of the input file. The most commonly occurring nouns and adjectives are tagged. These
words are then converted into objects in JAVA using the EA-Miner tool. The EA-Miner
tool also performs specification generation from the requirements document. The EA-
Miner tool thus reduces the time taken for identifying and structuring base concerns
(which are root conditions), aspects (modularized abstraction), and crosscutting
relationships in a requirements document.
Comparison: The EA-Miner tool helps to understand the natural language processing
which is used for identifying the ambiguities in a requirements document. The proposed
CASE tool specified in this thesis research consists of automation of software
requirements engineering analysis. The proposed CASE tool requirement analysis uses
the Descartes specification language. The Descartes specification language uses
structures and trees to represent a specification.
Texas Tech University, Henry Johnson, December 2010
20
2.6.3 Software Project Management Support Tool
Hanakawa and Okura [Hanakawa2004] described a software project management tool
for improving communication for agile software development. This tool is based on a
communication model that uses formal methods.
Methodology: The software tool was designed in accordance with a new communication
model for software project management. The new model focuses on relationships
between communication and project states. In each state of a software project, there
exists various conditions; fair, normal, confused, and steady. The method was to classify
the project communication model for a bad project and good project. The research was
undertaken by analyzing cross communication between the stakeholders and the software
developers of a software project.
Features: The tool introduces the concept of an Empirical Project Monitor (EPM). The
purpose of the EPM is to record the activities in the software development process
automatically. The recordable activities are debugging, programming, communication
with email, and check-in and check-out time from the source code modules. Based on the
analyzed data the tool formulates the state of the project based on this communication
model.
Comparison: The paper gives an idea on how software development is supported by a
CASE tool which helps in mapping the communication between the stakeholders of the
Texas Tech University, Henry Johnson, December 2010
21
software project. This thesis research effort developed tool support for traditional
software project management. The traditional software project management requires
accurate software requirements analysis compared to the agile method for software
project management. The proposed CASE tool in this research could reduce the time and
cost for a traditional software management by automated support for software project
management and requirements engineering.
2.6.4 Intelligent Risk Management Tools for Software Development
The authors [Dhlamini2009] described an intelligent model for risk management and
a tool based on that model for software development. The authors have demonstrated a
tool which is system independent and can be used for both agile and traditional software
development.
Methodology: The authors approached software development using a new risk
management model. According to the authors, Software Risk Management (SRM)
methodologies framework for software risk management is supported by the following
practices:
Software Risk Evaluation (SRE);
Continuous Risk Management (CRM); and
Team Risk Management (TRM)
The risk management tools that have already being implemented in software industries.
The risk management tools explained in the paper were Riskit, Risk guide, and Risk
Texas Tech University, Henry Johnson, December 2010
22
Radar Enterprise (RRE). The authors then described the gap between risk management
tool and intelligent risk management tools. In the paper, the authors also discussed the
different proposed framework for risk management.
Features: With the survey of the existing tools for risk management, the authors
described two risk assessment and management categories: repository-based management
and knowledge-based risk assessment and management. The tool described by authors is
an intelligent risk management tool that requires the ability to learn, and adapt to change
in behavior of the project. The ability to learn and adapt to change in behavior of the
project feature overcomes the weakness of lack of deductive power in repository based
risk management and deductive capability tied to specific technology or development
methodologies in knowledge based tools. Thus, the developed tool in [Dhlamini2009]
uses a neural network approach which could show the ability to adapt and learn like a
human brain.
Comparison: This thesis research effort gives an insight on the use of risk management
CASE tools for software development. The authors offer an idea for risk management
using intelligent agents which integrates formal methods and heuristic approaches. The
proposed tool in this thesis research has fostered the risk management feature for a
software development process.
Texas Tech University, Henry Johnson, December 2010
23
2.7 Summary
This chapter discussed an overview of requirements engineering support tools. The
importance of these tools is to produce an effective requirements engineering process.
Section 2.4 discussed some of the requirements engineering tools currently available.
Some of the requirements engineering basic support features of the tool are discussed in
Section 2.2. The chapter mainly aims to create an understanding of the term requirements
engineering support tools. This thesis research effort explains the requirements tool
support for automation of requirements analysis and extended support of the
requirements engineering support tools for software project management support.
Chapter V discusses the specification requirements, features, and methodologies for the
implementation of a proposed CASE tool.
The research efforts explained in this chapter are some of the previous efforts in the
field of requirements engineering automation and software project management tool
support. The features and methods illustrated in the papers are useful components for the
proposed CASE tool in this thesis research effort. Software development starts from the
process of requirements engineering.
The use of formal methods and specification languages is the key to develop the
proposed CASE tool requirement analysis feature. In the papers [Kiyavitskaya2008,
Sampaio2005], the authors described the automation of requirements engineering process
implemented using formal methods. [Hanakawa2004, Dhlamini2009] described new
tools for software project management support. The next chapter provides an overview of
the Descartes specification language.
Texas Tech University, Henry Johnson, December 2010
24
CHAPTER III
AN OVERVIEW OF DESCARTES SPECIFICATION LANGUAGE
3.1 Introduction
The Descartes specification language is a formal executable specification language.
The Descartes specification language and its processor were developed by Urban
[Urban1977]. The Descartes language and interpreter provide software developers with
the capability to automate the analysis of requirements documents and prototyping
capabilities in the software development life cycle. The functional model, in which the
specifications are described by defining the input data, then relating the output data to the
input data as a function of the input data is the basis of Descartes specification language
[Joo1994]. The main goal for developing such a language is to automate the simple
functional specification of a software system from a text document to eliminate the
ambiguity.
Many developments have occurred to the Descartes specification language since its
introduction in 1977. The Descartes language processor was enhanced with a graphic
capability [Lee1991]. Wohlenberg developed a basic methodology to aid design from a
Descartes specification [Wohlenburg1992]. The Descartes specification language was
extended to Descartes-RT to support real-time software specification by Sung
[Sung1992] and a language processor for Descartes-RT was developed by Cheng
[Cheng1992]. A visual syntax-directed editor for Descartes was developed by Khwaja
Texas Tech University, Henry Johnson, December 2010
25
and Tung [Khwaja1993, Tung1993]. In 1994, an automated test data generation
methodology was developed by Joo [Joo1994].
This chapter discusses an overview of the Descartes specification language. This
chapter also describes the data structuring methods and Hoare trees, which constitute the
basic data structures for the Descartes language as described in Section 3.2. Specification
construction is illustrated in Section 3.3 and an example is given in Section 3.4. Section
3.5 contains the summary of the chapter.
3.2 Data Structuring
In the Descartes specification language, the data structures are specified in terms of
Hoare trees. The concept of Hoare tree formalism was first developed by Urban. These
trees separate input data into parts, then describes the output data in terms of these parts.
Using this formulation, a specification can be developed top-downwards into modular
specification units [Urban1977]. Each module forms a partial specification in the
Descartes specification language. A Hoare tree thus provides a simple notation for
describing the input and output data of a document. A direct product is used to define a
node which is a concatenation of the set of elements [Joo1994].
To describe data in a Hoare tree, the terminal node name denotes the actual data item
or abstract execution. Each intermediate node of the tree has a meaningful name that
describes the data given in the subtree [Urban1977]. Thus, for example,
Texas Tech University, Henry Johnson, December 2010
26
complex
X
Y
Here “complex” is the node name and “X” and “Y” are the two subtrees of the node
“complex”.
There are three data structuring methods (direct product, discriminated union, and
sequence) in a Hoare tree. These data structuring methods are used to structure the
subtrees from the intermediate nodes of a Hoare Tree. In the Descartes specification
language, direct product is the default when a discriminated union or a sequence is not
indicated in the specification document. The discriminated union is denoted by a plus
sign (+). Example as follows:
address
street_name
city_name
The above indicates that “address” is composed of “street_name” followed by “city
_name”. The example below is of a discriminated union. This denotes that “boolean” can
be either “true” or “false”.
boolean+
true
false
An asterisk (*) as a suffix to a node name is used to indicate a sequence of zero or more
occurrences of elements. For example,
string*
character
Texas Tech University, Henry Johnson, December 2010
27
represents “string” that is a sequence of zero or more elements, each of which is a
character. A sequence of nodes has at least one immediate subnode. These could be a
sequence of direct product or discriminated union written as a single node. Thus,
according to [Urban1977]
“ x* x*
y or y+
a a
b b
c c
can also be written as
x* x*+
or
a a
b b
c c ”
The range of a sequence is specified as follows:
password (1..8)
character
In the above example, the lower bound is one and upper bound is eight. Blank space is
used to indicate that there is no upper bound. For example
integer (1.. )
digit
The node name integer (8..8) is used to denote a precise range of digits. Here, eight is the
precise length of the sequence of integers.
Texas Tech University, Henry Johnson, December 2010
28
In Descartes, a literal is a string enclosed in single quotes. Thus,
name
„Bob‟
The above example denotes the name is “Bob”. The next section discusses, how a
specification is constructed using Descartes.
3.3 Specification Construction Using Descartes
A Hoare tree is a notation used in the Descartes specification language to define the
expected input data and produce the output data. If the input is considered as a sequence
of character, then the Hoare tree can match the pattern specified by the specification
described in the language. The expected input and the produced output, and functional
relationship that exist between the input and the output are described by the Descartes
specification language. The root node of the matching Hoare tree becomes a name of the
entire string and each intermediate and terminal node becomes a name for the part of the
string that it matches [Urban1977]. The specification is developed using the top-down
approach where the entire input is divided into modular units. The Hoare tree is thus
refined until no further refinement is possible. Thus, the final product is a fully
synthesized input data. Modules reference the data at the abstract level to the current
level of data definition.
Texas Tech University, Henry Johnson, December 2010
29
A module title is a natural language phrase that describes the function value in
terms of the arguments. For example, the title
THE_REAL_OF_A_(COMPLEX_NUMBER)
The above example has “COMPLEX_NUMBER” as the only argument.
The arguments in the module title represent the input data to the module. The module
title is constructed to describe output data. The analyzed data from the tree will be useful
in synthesizing the Hoare tree. The module lists analysis and synthesis Hoare tree after
the module title. The Hoare tree describes the data corresponding to the argument within
the „calling‟ module. Module calls when it appears as an argument, the module call must
be executed. The value of the module becomes the value of the argument.
In a Hoare tree, individual nodes of the Hoare tree are of two types: match and
reference. Match node appears as lower case letter and a reference node appears in upper
case letters. A match node acquires values as a result of matching whereas a reference
node acquires the value of the previously matched node with the same name. The
analysis or synthesis past a node is determined by an intermediate reference node. The
processing continues on to the subtree of the reference node when the intermediate
referencing node is associated with a previously matched node with the same name. A
reference node can also be used to denote terminal literal node, module title nodes, and
module call nodes.
If the root nodes of Hoare trees are reference nodes that indicates the Hoare tree is an
analysis tree. Root nodes of the Hoare tree that are match nodes indicate the Hoare tree is
Texas Tech University, Henry Johnson, December 2010
30
a synthesis tree. These are some of the features of the Descartes specification language
for constructing specification.
Matching and Referencing: All nodes can acquire values during analysis or synthesis.
Some nodes may not acquire values, therefore all types of nodes is either defined or
undefined. For example,
Input
letter+
„d‟
„f‟
„g‟
Here, if the character “d” is the only input string, after the match is performed “‟f‟” and
“‟g‟” will be undefined literals. The matching process of direct product and discriminated
unions are performed as in a SNOBOL pattern match for concatenation and alteration,
respectively. For example
x+
end_of sequence
NULL
continuation of sequence
a
next_x
x
The number of elements matched in a sequence node can be referenced by that
reference node with the suffix #. The return match node is used to determine the output of
a specification module.
Texas Tech University, Henry Johnson, December 2010
31
Descartes has the ability of abstract execution. Descartes allows the user to write a
specification in a top-down manner [Joo1994]. In this method each Hoare tree is partially
refined. A Hoare tree with at least one finite path in the tree will terminate with a match
node. Terminal match nodes are refined later. This abstract execution capability allows
the software engineers to validate partial specifications.
3.4 An Example Specification
Figure 3.1 shows an example of a Descartes specification directly from [Urban1977].
The input for the module is a text document and the output from the module execution is
the number of words in the input. This specification consists of two modules
THE_NUMBER_WORDS_(TEXT) and LETTER.
Figure 3.1: Specification to output the number of words of an input document
THE_NUMBER_WORDS_(TEXT)
TEXT
leading_blanks_or_nl*+
„ „
NL
word_section(1. . )
word (1. . )
LETTER
word_delimiter(1. . ) +
„ „
NL
return
„The text‟
„has‟
WORD_SECTION#
Texas Tech University, Henry Johnson, December 2010
32
„words.‟
NL
LETTER
return+
„a‟
„b‟
„c‟
„d‟
.
.
„z‟
The module, THE_NUMBER_WORDS_(TEXT), has an analysis tree, TEXT, and a
synthesis tree, and return. The analysis tree analyzes the input whereas the synthesis tree
returns the output.
3.5 Summary
This chapter described the Descartes specification language which is a formal
specification language. Descartes specification language uses Hoare trees for data
structuring methods. The Descartes specification language can be used to produce test
data generation, to analyzing requirements document, and to generate specification in a
simple format. The Descartes specification language aims in simplifying the specification
of documents in the software development process and validate the errors in the early
phases of the life cycle. The following chapter discusses a set of requirements tool
evaluation criteria and evaluation of a few requirements engineering tools using the
evaluation criteria.
Texas Tech University, Henry Johnson, December 2010
33
CHAPTER IV
REQUIREMENTS TOOL EVALUATION CRITERIA
4.1 Introduction
This chapter describes a set of evaluation criteria for requirements engineering tools.
The requirements engineering tools are evaluated to understand the future development
of tools that would allow for a fully automated requirements engineering process. Section
4.2 discusses the evaluation criteria and procedure for the evaluation. In Section 4.3 a few
of the most popular web-based requirements engineering support tools in the market
which is determined by the number of companies. These tools are evaluated based on the
evaluation criteria in Section 4.2. Section 4.4 discusses the summary of the chapter.
4.2 Evaluation Criteria and Procedure
Each of the requirements engineering tool were evaluated with a scale of 1 – 5 where 5
is the best case and 1-worst case for each criterion discussed below.
An ability to produce a good SRS (IEEE std. 830-1998 recommended practice for
software requirements specification) is the criteria used to check whether the
requirements engineering tool can produce a good requirements document. The
characteristics of the IEEE std. 830-1998 recommended practice for Software
Requirements Specification (SRS) are:
Texas Tech University, Henry Johnson, December 2010
34
Correct: According to the IEEE standard 830-1998 [IEEE1998a], “An SRS is correct if,
and only if, every requirement stated therein is one that the software shall meet.”
Unambiguous: According to the IEEE standard 830-1998, “An SRS is unambiguous if,
and only if, every requirement stated therein has only one interpretation.”
Complete: According to IEEE standard 830-1998, “An SRS is complete if, and only if, it
includes the following elements:
a) All significant requirements, whether relating to functionality, performance, design
constraints, attributes, or external interfaces. In particular any external requirements
imposed by a system specification should be acknowledged and treated.
b) Definition of the responses of the software to all realizable classes of input data in all
realizable classes of situations. Note that it is important to specify the responses to both
valid and invalid input values.
c) Full labels and references to all figures, tables, and diagrams in the SRS and definition
of all terms and units of measure.”
Internally Consistent: According to IEEE standard 830-1998, “An SRS is internally
consistent if, and only if, no subset of individual requirements described in it conflict.”
Ranked for importance and/or stability: According to IEEE standard 830-1998, “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.”
Texas Tech University, Henry Johnson, December 2010
35
Verifiable: According to IEEE standard 830-1998, “An SRS is verifiable if, and only if,
every requirement stated therein is verifiable. A requirement 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: According to IEEE standard 830-1998, “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: According to IEEE standard 830-1998, “An SRS is traceable if the origin of
each of its requirements is clear and if it facilitates the referencing of each requirement in
future development or enhancement documentation.”
The next set of evaluation criteria is used to evaluate the developed CASE tools. In
this thesis research, the set of evaluation criteria explained below are used for
comparative evaluation of the implemented requirements engineering tools. These
evaluation criteria enable the developers to develop a user friendly and effective tool.
Information in the Tool
The information given in the tool is clear, concise, and informative.
The language used in the tool is nondiscriminatory.
The information is based on empirical data that are current and valid. This
evaluation criterion is determined using a comparison of each tool features.
Texas Tech University, Henry Johnson, December 2010
36
Career development process
The tool helps individuals to develop software development skills.
The tool allows integrating previous project requirements in the new
requirements document.
User interaction
The tool is easy to use. Tools could be evaluated using comparing the
materials with other CASE tools.
Prerequisites are identified and instruction is provided in the software guides
so individuals can run the tool and understand its results.
Interactive support when the user enters invalid input.
The tool allows the users to communicate with different users in the system.
Technical aspects of the software and materials
The system uses standard equipment that is reliable, widely available, and
applicable to a variety of uses.
Computer capabilities such as graphics, color, or sound are used for
appropriate instructional reasons.
The server software is compatible with windows/Unix/Solaris servers.
The tool is reliable in normal use.
Texas Tech University, Henry Johnson, December 2010
37
Support services
The site coordinator's manual explains the content and process involved in
server updates.
The help documents included in the tool are understandable.
The technical support for the tool could be contacted for more information.
Upgrades are available through the product website.
The tool can be mastered in less time.
4.3 Tool Evaluations
In the following section, the tools were evaluated using the above evaluation criteria.
The requirements engineering tools are evaluated in the tables below are the web-based
requirements engineering support tools in software development. The tools used in this
evaluation were Accept360 [Accept3602010], DOORS [DOORS2010], Accompa
[Accompa2010], Core [Core2010], Cradle [Cradle2010], Focalpoint [Focalpoint2010]
and Caliber [Caliber2010]. All the requirements engineering tools were evaluated by the
data from their corresponding web pages. Each tool was spent the approximately the
same amount of time understand the features and functionalities of the corresponding
tools.
Table 4.1 shows the evaluation using the comparison of these tools using the scale 1-5.
The scores provided in the table gives a comparative analysis. A tool that strongly
supports a criterion received a score of 5. The tool with a score of 4 supports the
Texas Tech University, Henry Johnson, December 2010
38
corresponding evaluation criterion. The tool with a score of 3 has small support towards a
criterion. Scores 2 and 1 is for the least support and no support respectively of the tool for
that particular criterion.
Table 4. 1: Evaluation of the requirements engineering tools
Tools
Criteria
Accept360 DOORS Accompa Core Cradle Focalpoint Caliber
Informatio
n in the
tool
4 4 5 5 5 4 5
Career
developme
nt
4 3 4 3 5 4 4
User
Interaction
4 4 3 4 3 4 3
Technical
Aspects
4 5 4 4 5 5 5
Support
services
4 4 3 5 4 4 5
Table 4.2 shows each of the tools evaluated with scores 1-5 based on the IEEE std.
830-1998 characteristics. A score that is less than 3 denotes the support from the
requirements tool to check the particular characteristic of the IEEE std. 830-1998 is
minimal. The tool with a score greater than 3 supports that particular criterion. The tool
which strongly supports the criterion received a score of 5. The future advancements for
the CASE tools should include support of IEEE std. 830-1998 characteristics of good
SRS.
Texas Tech University, Henry Johnson, December 2010
39
Table 4. 2: Evaluation of the requirements engineering tools using the IEEE std. 830-
1998
Tools
Criteria
Accept360 DOORS Accompa Core Cradle Focalpoint Caliber
Correct 2 3 3 3 3 2 3
Complete 1 2 1 2 3 2 2
Consistent
3 3 3 3 3 3 3
Traceable
4 4 3 4 4 4 4
Ranked for
importance or
stability
4 4 5 5 4 4 4
Modifiable 5 5 5 4 5 4 5
Verifiable 2 3 2 3 2 3 1
Unambiguous 4 4 3 4 3 4 4
4.4 Summary
In this chapter, the corresponding evaluation criteria were discussed in Section 4.2
and the software evaluation of the requirements engineering tools was described in
Section 4.3 and. The evaluation of the present requirements engineering tools provides a
way of understanding the requirements engineering tools. This evaluation facilitates the
need for further research in the area of automation of requirements verification and
validation. The evaluated tools do not provide automated requirements verification and
validation. The agreed requirements may be interpreted in different ways leading to
Texas Tech University, Henry Johnson, December 2010
40
delays or failures in the software development. Thus, to reduce the failure in software
development, the requirements engineering process has to be supported by an automated
requirements engineering tool that could generate a formatted specification from the
requirements document.
In the following chapter, the proposed CASE tool is discussed. The proposed CASE
tool is a requirements engineering tool that supports the software project management at
every phases of the software development.
Texas Tech University, Henry Johnson, December 2010
41
CHAPTER V
REQUIREMENTS FOR THE PROPOSED CASE TOOL
5.1 Introduction
This chapter describes the requirements for the proposed CASE tool introduced in
this thesis effort. The proposed CASE tool is an enhancement for the current
requirements management tools. Requirements management is the systems engineering
activity principally concerned with finding, organizing, documenting, and tracking
requirements for software systems. The goal of this research was to advance in the field
of automation of requirements engineering support in the software development process.
An automated requirements process allows rapid and low cost software development
process. Documenting the research effort allows the development of a new generation of
software requirements engineering support tools. The proposed CASE tool will support
software project management through every phase of software project.
In this chapter, Sections 5.2 to 5.6 describes the requirements of the proposed CASE
tool. The requirements are the initial phase of the development of the proposed CASE
tool. Section 5.2 describes the web-based capabilities of the proposed CASE tool. In
Section 5.3, the requirements engineering process support is explained. In Section 5.4,
the software project management capabilities are discussed. In Section 5.5, the software
testing and maintenance support of the proposed CASE tool is described. In Section 5.6
suggests the implementation methods for the development of this CASE tool.
Texas Tech University, Henry Johnson, December 2010
42
5.2 Web-Based Tool
The requirements engineering for software development may be divided
geographically where the clients (or customers) and software development team are in
different states, countries, or continents. In a software development project, a centralized
documentation is favorable to produce the requirements document. The distributed
database allows the users to store data in different locations thus improving reliability.
The requirements for the web based feature of the proposed CASE tool are as follows:
1.1 The tool must have two interfaces, the client interface and the server interface. The
client interface is a web-based interface which is accessed using a browser. The
server interface allows the administrator to control the access and the database of the
server software.
1.2 The tool must have a server application that has access to a relational database
management system. The use of relational database management system allows the
query and selection of the data in the database much reliable than a centralized
database.
1.3 The client interface of the tool must function in standard web browsers. A web-based
interface using a web browser has many chances of crashing at the time of runtime.
By defining standard web browsers such as Safari, Internet explorer, Google chrome,
Mozilla Firefox, and Opera allows the developer to test the tool in these web
browsers to limit the crashes.
1.4 The user must be provided access privileges for the server and database access. The
users of the requirements engineering tool may vary as customers, software
Texas Tech University, Henry Johnson, December 2010
43
engineers, software project managers, requirements engineer, and other stakeholders
of the project may use the CASE tool. The tool must provide limited access or full
access depending on the task required by the user of the CASE tool. The access
privilege may vary from different users and also different projects for the same user.
1.5 The user must be provided with a login ID and password by the administrator. The
provision of registering a user in a closed group project is crucial. The tool
administrator should be in charge assigning user access privileges for each project.
These access privileges may vary from time to time depending on the project
requirements, change in management, or change in customers. Therefore,
administrator should be able to change the user‟s access at any time in the software
project development life cycle.
1.6 The tool must be installed and configured on a server. The tool must follow
configuration procedures at the server side. A software company should be provided
with the server software which should be installed in a secure server. The server
should be able to support a large database depending on the number of projects and
users that will access the CASE tool. The server software should be independent of
the operating system platform of the installed server. The server shall be connected
to the World Wide Web (WWW) to provide access to all users across geographical
boundaries.
1.7 The user account must be unique and secure. Each user is given a login ID and
password by the administrator. There should not be more than one identical login ID
Texas Tech University, Henry Johnson, December 2010
44
to access the server software. The password should be able to be changed by the user
of the CASE tool after the first login by the user.
1.8 The user privilege must specify the project access and access privileges. The project
access of a user may vary from one to many projects. The access privilege in each
project will vary according to the type of the project. In the case of a software
engineer, that user may have only one project access, but a software project manager
can have access to more than one project.
1.9 The access privileges for the user must be either read/edit or read only. The read
only access allows user to view the requirements and not make any changes to the
requirements. The software engineers, customers, and end users of the software
project should have only the read access. The read/edit access allows users to both
view and update the requirements in the CASE tool. Usually the requirements
engineers or the project managers have the read/edit access privilege.
1.10 The user must be able to login to the server using a web browser. The server
software can be accessed using the specific URL for each of the specific servers. The
URL takes the user to the login page. The login page prompts the user to enter the
login ID and password. Only then will the user gain access to the CASE tool.
1.11 The user must be able to navigate through each of the web pages of the tool. The
index page of CASE tool is the project access summary and the user activities in the
past. Every web page of the CASE tool must have a Home button to navigate to
index page. The CASE tool must have all the tabs for each support offered by the
tool in every page.
Texas Tech University, Henry Johnson, December 2010
45
1.12 The server application must be able to handle at most one hundred users at a time.
Depending on the industry requirements and the database that a server can handle
the maximum number of users should be limited to one hundred users for each
server application in each server.
Figure 5.1: Use Case diagram for the web based CASE tool
5.3 Requirements Engineering and Design
The requirements engineering process is a systematic analysis of the requirements.
The requirements engineering support by the proposed CASE tool can be divided into
two categories: requirements management, requirements verification, and validation.
Texas Tech University, Henry Johnson, December 2010
46
5.3.1 Requirements Management
Requirements management is the process of identifying, eliciting, analyzing,
documenting, tracing, prioritizing, and agreeing on requirements and then controlling
change and communication with stakeholders. The requirements engineers are
responsible for this phase of software development. A requirement is a capability to
which a project outcome (product or service) should conform. The purpose of
requirements management is to organize requirements documents and allow the users to
view and/or edit the requirements. Requirements management begins with the analysis
and elicitation of the objectives and constraints of the software system. The requirements
for the requirements management support of the proposed CASE tool are as follows:
2.1.1 The user with read/edit privileges must be able to enter and submit the requirements
in natural language. The user can enter text to submit each requirement in the CASE
tool. The submission text box should be equipped with spell and grammar checks.
The submitted requirements are saved in the database
2.1.2 The tool must generate a requirements ID for each requirement. The requirements
ID format can be selected by the user. The requirements ID by default, is a unique
identifier for each requirement. The requirements ID allows the tool to save the later
changes to that requirement and the original requirement on that requirements ID.
2.1.3 The user with read/edit privileges must be able to group the requirements into
different groups. The first digit of the requirements ID denotes the group to which
the requirement belongs. The group is a set of requirements which has similar
functionalities in the software system. The last digit of the requirements ID denotes
the number of the requirement in that particular group.
Texas Tech University, Henry Johnson, December 2010
47
2.1.4 The user must be able to read the submitted requirements of the project. A user with
both read and read/edit privileges should be able to view all the requirements on a
single screen. The requirements negotiation requires the customers and software
project team to sit and verify each requirement.
2.1.5 The user with read/edit privileges must be able to edit and resubmit the submitted
requirement. The requirements negotiations and changes to the requirements might
take place at different steps of the requirements engineering phase. Only the users
with the read/edit privileges should edit the requirements. The user‟s name and date
on which the requirement changed should be specified on the changed requirements.
The original requirement must not be deleted from the database. The requirements
ID maps to the new requirement for the automated analysis of the requirements
2.1.6 The user must be able to prioritize the requirements using a scale of 1-5 with 5
having highest priority. Prioritizing requirements is used to denote the importance of
each requirement in the software system. The most important or stable requirements
can be given a score of 5 and the least score is 1. The prioritization of requirements
gives an understanding of the most important requirements for the designers of the
software system. The unique requirement ID applied to each requirement
differentiates the requirements in the SRS.
2.1.7 The tool must automatically trace dependencies for each requirement to other
requirements. After submitting each requirement, the tool will automatically check
for the requirements that depend on the submitted requirement. Dependencies of a
requirement means, changes to the requirement may affect other requirements. The
Texas Tech University, Henry Johnson, December 2010
48
requirements ID of the dependent requirement is assigned to trace ID block in the
database of that particular requirement.
5.3.2 Requirements Verification and Validation
The requirements engineering tool must automate the requirements verification and
validation of the requirements document. The Descartes specification language should be
used to formalize the requirements verification and validation feature of the proposed
CASE tool. The Descartes specification language satisfies all the characteristics of the
IEEE std. 830-1998. Using the Descartes specification language, a natural language
requirements document can be analyzed to automatically generate formal specification.
When the input is considered as a sequence of characters, the Hoare tree can match the
patterns using specification in Descartes. By analyzing the specification, the tool should
automatically generate candidate classes and their associated relationships in the software
using the requirements documents. The specification should also allow the requirements
engineers to understand the requirements document more clearly than a natural language
specification. Another use of software specification is to automatically check whether the
requirements are correct, consistent, and unambiguous. The proposed CASE tool should
be able to automatically trace dependencies between each requirement to every other
requirement.
2.2.1 The tool must be able to analyze the Software Requirements Specification (SRS).
After the analysis of the requirements, the CASE tool should output a formatted
specification. This formatted specification is only applicable for architectural or
Texas Tech University, Henry Johnson, December 2010
49
functional requirements. Each requirement has tool parts: the actor and the action.
The action and the actor are usually connected using a key phrase „must‟, „shall‟ or
„should‟. The tool should be able to extract the actor and the action from each
requirement.
2.2.2 The tool must analyze the candidate classes and their associated relationships
among the classes. The analyzed specification can generate the possible classes of
the software system. The „IS-A‟ and „HAS-A‟ relationships of each classes can also
be generated using this analysis.
2.2.3 The tool must generate a report of the SRS analysis. The report consists of
formatted specification, classes, and class relationship. The report is produced by
user‟s prompt.
2.2.4 The server must store the report for each SRS. Each report generated at the
requirements analysis phase should be stored for future references at different
stages of software development.
2.2.5 The tool must allow a user to check for poor words in each requirement
automatically. The poor words such as „etc‟, „might‟, and „may‟ are some of the
poor words often found in requirements. Requirements with such poor word are
usually incomplete and may require further validation. The actual purpose of the
requirements is to give a clear idea of what the software system should perform or
certain constraints in software development.
2.2.6 The user with read/edit privileges must be able to change and confirm the reports
and change the analyzed requirements in the SRS. The reports generated by the tool
Texas Tech University, Henry Johnson, December 2010
50
consist of formatted specification, possible classes and class relationships. Any user
can view the reports, but only the user with the read/edit privileges can change the
reports and submit them to the database.
2.2.7 The user can analyze of requirements at any time in the scope of the software
project. The best case for analysis of a requirements document is at the
requirements engineering phase. In real world projects, the requirements may vary
at any time due to the changes in the needs of the customer. The changes in
requirements improvise a change in the design. Thus, the requirements analysis at
any time is important for effective software development.
Figure 5.2 shows the flow chart diagram of the identification of the classes and their
relationships from the natural language requirements in the proposed CASE tool. The aim
of the identification process is to report the classes and their relationship to the users and
the users can further elaborate and then confirm the report. The identification process can
lead to automation steps in the design phase.
Texas Tech University, Henry Johnson, December 2010
51
Figure 5.2: Flow chart for the analysis of requirements to identify classes and the
relationship between classes.
5.4 Software Project Management Capabilities
Software project management using requirements engineering tools can speed up
software development. CASE tools for requirements engineering can be extended to
software project management for effective planning and budgeting of the software
projects. The requirement tools thus produced could allow for the use of formal methods
for software project planning, budgeting, and estimation. The area of risk analysis in the
Texas Tech University, Henry Johnson, December 2010
52
software project could also be included in the requirements engineering tools. The
requirements for the tool to enable the software project management capabilities are:
3.1 The user must be able to enter the estimated Lines Of Code (LOC) for each
requirement. The user can enter the LOC required for the particular requirements in
the LOC block of the database. The tool can also automatically generate the LOC at
the requirements analysis from previous reports and similar requirements. The tool
must trace the requirement from previous project and assign the LOC to the new
requirement.
3.2 The tool must be able to calculate the duration, budget and number of staff members
required for the project. The sum of LOCs of all the requirements and the salary for
each staff-month is used to calculate the number of staff members and budget,
respectively, for the software project. There are many estimation models for software
development [Fairly2009]. Calculation of budget and number of staff members
allows the customers and software company to understand approximate estimation of
the project.
3.3 The tool must use three different formal methods in software project estimation. The
higher the number of estimation method, the better will be the estimated values. The
average values of all the estimations used in the tool should be considered for the
software development effort. The estimation of software allows the project manager
to effectively plan the project.
3.4 The tool must analyze the risk automatically by the users‟ prompt. Risk analysis of
requirements is the identification of poor word which may affect the later design
Texas Tech University, Henry Johnson, December 2010
53
phase of the software development. The risk of each requirement may vary and may
cause a failure of the software system.
3.5 The risk analysis report is generated to the user. The risk reports should be developed
using bar charts each requirement risk is denoted on each bar. The requirements
showing the higher risks should be reviewed by the user to avoid failure in software
design.
3.6 The user with read/edit privileges must be able to change and confirm risk for each
requirement. The users with read/edit privileges should be able to change the risk
levels manually.
3.8 The tool must allow the online users of the same project to securely communicate
using text messages. Short message communication allows effective and fast
information sharing between the users of the tool. The chat messages are quick and
can be archived for future reference. Activities such as requirements negotiation or
requirements elicitation can be achieved using the chat message communication
between the customers and the requirements engineers.
3.9 The user with read/edit privileges must be able to create a software project
management plans. Software project management template was tailored from the
IEEE standard 1058-1998 [IEEE1998b] for software project plans document. The
tool should allow the user to create a software project plan template with a front
matter with the title, revision history, preface, table of contents, list of figures, and list
of tables. The project summary in the project plan template consists of purpose, scope
and objectives, assumptions, constraints, project deliverables, schedule and budget
Texas Tech University, Henry Johnson, December 2010
54
summary. The project plan template further includes evolution of the plan, references,
and definition. The tool allows the users with read/edit privileges to input the data for
each section.
5.5 Software Testing and Maintenance
In any software project development at least 50% of the project scope is the software
maintenance phase and almost 10% is software testing phase [Fairley2009]. Automated
test data generation, easy access to the SRS document, and design documents are the
features added in this CASE tool. Generating test data for software testing can be
developed using the Descartes specification language [Joo1994]. The SRS document and
the design document of the software project are required for software maintenance.
4.1 The tool must be able to generate test data from the analyzed SRS document. The
requirements could be analyzed using the Descartes specification that can be used to
automatically generate test data using the Descartes specification language [Joo1994].
Automation of generating test data could simplify the effective software testing
process.
4.2 The user must be able to extract a copy of the SRS as a whole document and reports
from the server. The Software Requirements Specification (SRS) is a single document
consisting of all the requirements, diagrams with labels, and references. The SRS is
required for all the phases of software development. The extraction of the SRS from
the tool gives software engineers a reference of the final requirements document.
Texas Tech University, Henry Johnson, December 2010
55
4.3 The user must be able to search for keywords in the SRS document. The tool must be
able to provide all the requirements and its dependent requirements of the searched
key words. The keywords search is useful for the testing and maintenance phase to
check whether the output of a software system is similar to that specified in the
requirements.
5.6 Implementation Methods
The tool development should start from the client interface using a web page. The
client will be using a web browser to access the information from the server using the
internet. The server data must be encrypted to provide controlled access to each project
and each individual in different organizations. Software reuse could be an important
method to implement the interface. The project created by Puchala [Puchala2010] could
be the implementation base for the new tool. The project implemented by Puchala is a
web-based requirements engineering tool with all the features of the requirements
management of the proposed CASE tool. Some extra tabs and buttons have to be added
to the client interface. The development of the client interface unveils the server side
development.
The SRS documents and reports of a project must be stored in the server side
database. After the development of the interface for the web pages, the analysis engine
must be developed. In the analysis engine, the Descartes specification for formatting the
input natural language must be used. The requirements are analyzed to create a formatted
specification document.
Texas Tech University, Henry Johnson, December 2010
56
The Descartes specification language will be used also to generate the test data.
Another important method to be implemented is the software project planning and
estimation. The estimation calculations will be carried out at the server. The methods of
estimation [Fairley2009] that should be enabled in the tool are:
1. COCOMO model
The COCOMO model is used to estimate the time and people required for a software
project. The COCOMO model has the following equations for the calculation of effort,
development time, and the people required.
Effort = ab(KLOC)b
b in staff-months
Development Time = cb(Effort)d
b in months
People required = Effort / Development Time in count
The coefficients ab, bb, cb and db are the constant values depending on the size of the
project. KLOC denotes the Lines of Code in thousands. If the lines of code required is
estimated in the requirements engineering process the development time and the effort
applied could be calculated to finish the project. In the COCOMO model
ab, bb, cb and db are the coefficients that have predefined values. Since the proposed
CASE tool allows the user to enter the Lines Of Code for each requirement, the tool
automatically calculates the project estimates. The coefficient values are stored in the
CASE tool. The proposed CASE tool adds up all the LOC values of the requirements and
then calculates the development time, effort and people required.
2. SLIM model
Texas Tech University, Henry Johnson, December 2010
57
The minimum development time, Td of software project can be calculated using the
SLIM model. The equation for the SLIM model is
Td = (K/C)0.33
In the above equation T d is in years, K is in staff - years, and C is a constant in the
range of 14 to 15. The equation could be rewritten by converting years to months, staff -
years to staff - months, and letting C = 14.5 which is the average case results in the
following equation, Td = 2.15(E)0.33
Where, T d is in months and E is effort in staff – months. The effort calculated from the
COCOMO model should be used to calculate the minimum development time using the
value of K in staff - years.
The proposed CASE tool should also be able to create software project planning
documents. The user interface will consist of a form where the user enters the
information corresponding to each section and the document is automatically generated
by the proposed CASE -tool.
5.7 Validation of Requirements for the Proposed CASE tool
The requirements described in this chapter presented a proposed CASE tool for
requirements engineering, software design, and software project management. In this
section, the requirements document is reviewed and analyzed for completeness,
correctness, and consistency. The requirements are categorized into specific
functionalities of the proposed CASE tool. Each requirement is numbered with a
requirement ID. The requirement ID is followed by the first sentence which is the
Texas Tech University, Henry Johnson, December 2010
58
primary requirement of the proposed CASE tool. The description of each requirement
follows the primary requirement. The description includes the operational requirements,
functionality, and constraints of that requirement. The entire requirement document for
the proposed CASE tool is consistent in the same format.
The requirements document presented in this chapter describes a proposed web-based
requirements engineering tool with software project management capabilities. In
comparison to other requirements engineering tools in the market, the requirements for
the proposed CASE tool described the primary requirements. The requirements of a web-
based tool, requirements management, requirements verification and validation, and
software project management capabilities are mentioned in the requirements document.
The implementation methods that could be used for the proposed CASE tool are also
presented in Section 5.6. Thus, the requirements can be said to be complete according to
other product requirements similar to the proposed CASE tool. Further analysis of each
requirement has revealed that the requirements are correct and all the requirements meet
the software specification of the proposed CASE tool.
Table 5.1 shows the traceability of operational features to primary requirements of the
proposed CASE tool. The primary requirements corresponding to the operational
requirements were discussed in the table below.
Texas Tech University, Henry Johnson, December 2010
59
Table 5.1: Traceability of operational features to primary requirements
Primary
requirements
Operational
features
1.7 1.10 1.9 1.8 2.1.7 2.1.6 2.2.1 2.2.3 3.3 3.4 4.1 4.2
Security X
Web-based
user access
X
Access
privilege
X
Project
estimation
X
Requirements
prioritization
X
Risk analysis X
Requirements
analysis
X
Test data
generation
X
Report
extraction
X
Trace
dependences
X
Analysis
report
X
5.8 Summary
This chapter discussed the requirements for the proposed CASE tool. The proposed
CASE tool requirements enhance the requirements engineering tool functionality. The
proposed CASE tool could use the Descartes specification language to automate
requirements analysis and validation. Project planning, estimation, risk management, and
project documentation are requirements for the proposed CASE tool. Developing the
automated generation of test data could provide tool support in the software testing phase.
Sections 5.2 described the web based tool requirements. In Section 5.3, the requirements
Texas Tech University, Henry Johnson, December 2010
60
engineering support for the proposed tool was discussed. Section 5.4 discussed the
software project management support capabilities of the tool. Section 5.5 explained the
software testing and maintenance support of the new tool. Section 5.6 described some of
the implementation methods that could be used for the development of the proposed
CASE tool. Section 5.7 discussed the validation of requirements of the proposed CASE
tool.
The proposed CASE tool discussed in this chapter describes the requirements for future
advancements to the present requirements engineering tools used by the software
industry. The automated analysis of requirements, generating specifications, and
generating classes and their relationships, test data generation, and software project
management capabilities are some of the features described in this chapter. The next
chapter discusses the evaluation of the proposed CASE tool.
Texas Tech University, Henry Johnson, December 2010
61
CHAPTER VI
EVALUATION OF THE PROPOSED CASE TOOL BASED ON IEEE STD. 830-
1998
6.1 Introduction
In this chapter the evaluation of the proposed CASE tool for requirements
engineering and software project management is discussed. In chapter IV, the IEEE std.
830-1998 evaluation criteria based on the characteristics for a good Software
Requirements Specification (SRS) were discussed. The set of evaluation criteria other
than the characteristics of IEEE std. 830-1998 developed in this thesis should be used to
evaluate the tool after implementation. The proposed CASE tool features described in
this thesis are evaluated in this chapter. In Section 6.2, each characteristic of the IEEE
std. 830-1998 is used to evaluate the CASE tool and in Section 6.3 describes the
summary of the chapter.
6.2 Evaluation Based on IEEE std. 830-1998
The IEEE standard 830-1998 criteria were used to evaluate the enhancements to the
proposed CASE tool which uses the Descartes specification language for requirement
analysis. The IEEE standard 830-1998 which is the recommended practice for Software
Requirement Specification (SRS) [IEEE1998a] lists the following characteristics. The
proposed CASE tool should generate a set of software requirement specifications that are:
correct; unambiguous; complete; consistent; ranked for importance and/or stability;
verifiable; modifiable; and traceable.
Texas Tech University, Henry Johnson, December 2010
62
Correct: The Descartes specification language provides a top down modular approach for
software system specification. The proposed CASE tool allows the users to change the
requirements into higher order specification that enables the users to check for the
correctness of the specification. The tool could use the Descartes specification language
to generate the specifications from the natural language text, which is yet to be
developed. The tool also provides an object oriented analysis and reports a set of classes
and their relationships. By the object oriented analysis, the user can ensure the
correctness of the software specification. There is no such tool or procedures to fully
check the correctness of the specification.
Unambiguous: In the proposed CASE tool, the automated generation of the specifications
allows the user to check any ambiguity in the requirements document. The proposed
CASE tool automatically checks the dependencies of each requirement to other
requirements in the CASE tool. The language processor of the Descartes specification
language also supports unambiguous specifications. The requirements that are verified by
the proposed CASE tool can be considered unambiguous. Thus, the proposed CASE tool
supports the „unambiguous‟ characteristic.
Complete: Since the proposed CASE tool uses Descartes specification language to
analyze the requirements, the proposed CASE tool checks for the completeness of the
requirement. The Descartes specification language uses Hoare trees as the data
Texas Tech University, Henry Johnson, December 2010
63
structuring method. The Hoare trees describe the expected input, output produced, and
the relationship between the input and output. This property of the Descartes
specification language satisfies the completeness characteristics of a good SRS. Thus,
the proposed CASE tool also satisfies the completeness characteristics of a good SRS in
analyzing requirements.
Consistent: In the proposed CASE tool, the consistencies of the requirements are
analyzed by the Descartes specification language. The higher order specification allows
the user to check whether the subset of individual requirements does not conflict. The
formal methodology used by the Descartes specification language ensures the
specifications are consistent. Thus, the proposed CASE tool satisfies this criterion.
Ranked for importance and/or stability: The proposed CASE tool allows the user to
create a requirements identifier for each requirement. The requirements identifier is
specific for each requirement in a particular software project. The user can also assign a
priority for each requirement to rank the requirements according to importance. This
feature allows the proposed CASE tool to satisfy the characteristic of ranked for
importance and/or stability of a good SRS.
Verifiable: The proposed CASE tool for requirements engineering stores each
requirement in the database. Each of these requirements can be analyzed manually or
automatically using the Descartes specification language. Output of the system is a
Texas Tech University, Henry Johnson, December 2010
64
product that meets the requirements of the customer. In the Descartes specification
language, specifications are written by functionally relating output with the input. The
functionality of the specification language to relate the output as a function of input,
determines whether the software meets a particular requirement.
The user always has an option of manually verifying each requirement. In both
approach the requirements are modifiable and both the old and new requirements is
stored in the same database.
Modifiable: The proposed CASE tool satisfies this criterion as the requirements are
stored in a database and the user with the read and write access privilege is able to
modify the requirements at any time. Each requirement submitted in the CASE tool
database is automatically traced to every other dependent requirement of the software
project. This prompts the user to make necessary changes to all other dependent
requirements of the modified requirements.
Traceable: The proposed CASE tool uses the requirements identifier for each
requirement. Each requirement can be traced for dependencies manually or automatically
to every other requirement using the proposed CASE tool. By using the automatic
traceability feature of the proposed CASE tool, the tool satisfies this criterion. The Hoare
tree structure used by the Descartes specification language allows identification of the
origin of each requirement.
Texas Tech University, Henry Johnson, December 2010
65
6.3 Summary
The proposed CASE tool was evaluated using the characteristics of IEEE std.
830-1998 in this chapter. The requirements engineering support of the proposed CASE
tool was evaluated in this chapter. The addition evaluation criteria discussed in Chapter 4
will be used to evaluate the proposed CASE tool at the implementation phase. This
evaluation denotes that the requirements document generated in the new tool should be a
good SRS according to IEEE std. 830-1998. In the next chapter, the thesis summary and
future work are discussed.
Texas Tech University, Henry Johnson, December 2010
66
CHAPTER VII
SUMMARY AND FUTURE WORK
This chapter summarizes the thesis by describing the accomplished research
objectives and the future of the research effort. The challenging task regarding the
research is discussed in Section 7.1 Section 7.2 describes the future work related to this
particular thesis research objective. The future work also explains the actual
implementation of the proposed CASE tool.
7.1 Summary
Requirements management tools have been in the market for at least a decade.
More and more software industries are moving to a systematic software development
process. The software industries are required to meet the high quality of software
systems. Software companies are struggling with scheduled software release and to
develop highly complex software systems. To reduce the cost and increase the quality of
software systems, this thesis research effort explains the use of a proposed CASE tool
that allows the software project managers to improve the software development process.
The thesis effort was used to describe the requirements engineering support
tool, evaluation criteria for requirements engineering tools, overview of the Descartes
specification language, and the set of requirements for a proposed CASE tool that will
improve the current requirements engineering tool development. The challenging task in
this thesis was to understand the ability of CASE tools to support software development.
Most of the requirements engineering tools today, lack automatic analysis of
Texas Tech University, Henry Johnson, December 2010
67
requirements, generating specification, and generating test data from the set of
requirements. This thesis research effort discussed a proposed CASE tool which has
extended the requirements management tool to requirement analysis, software design,
software testing, and software project management support tool. The use of Descartes
specification language reduced the gap between requirements engineering phase and
design phase. Thus, the proposed CASE tool is an approach of performing the software
project management using the requirements engineering support tool.
Software projects can start from the requirements phase and ends at the
maintenance phase. The project managers are responsible for validated requirements,
software design, software development, software testing, and maintenance. Chapter I was
an introduction to the thesis research effort. Chapter II explained an overview of the
requirements engineering tools with some real world software requirements engineering
tools on the market. The chapter also described the related research efforts. Chapter III
discussed the overview of the Descartes specification language. The evaluation criteria
were discussed in Chapter IV for the requirements engineering tool. The IEEE std. 830-
1998 recommended practice for a good SRS document was the main evaluation criteria
used. The proposed CASE tool requirements in Chapter V described the extension of a
requirements management tool to a software project management tool. The formal
methods implemented in the proposed CASE tool enable software project planning and
risk management. Chapter VI described the evaluation of the proposed CASE tool based
on the IEEE std. 830-1998 characteristics. The thesis research effort has developed an
understanding of the requirements engineering tools and how these tools support software
Texas Tech University, Henry Johnson, December 2010
68
projects. The research has also accomplished the initial step in the use of requirements
engineering tools with software project management capabilities by providing support to
all phases of the software engineering life cycle.
The proposed CASE tool presented in this thesis effort should comply with the
IEEE std. 830-1998 recommended practice for SRS and allows the user/customer to
verify and validate their requirements automatically. The proposed CASE tool should
reduce the time and cost of the requirement engineering process. From the academic
standpoint, this thesis provides an understanding of the requirements engineering and its
support tools. This research could lead to implementation of advanced requirements
engineering tools.
This section offered a synopsis of the thesis effort. The next section addresses the
future research areas established from this thesis effort.
7.2 Future work
Requirements engineering is the starting phase of any software engineering project.
The proposed CASE tool requirements in this thesis should provide a platform for
automated requirements engineering support. This thesis serves as an explanation for the
use of the requirements engineering tool to support software project management.
The future research work could include reviewing some of the related work in the field
of requirements analysis to develop a knowledge-base of all the key phrases to verify the
requirements [Kiyavitskaya2008]. The next phase will implement the Descartes
specification for requirements analysis. Each component of the tool has to be designed
Texas Tech University, Henry Johnson, December 2010
69
for this research to proceed to the next phase. The future research could also include
automated software project estimation capabilities. Software project estimation will be
implemented tracing the Lines Of Codes (LOC) of current software project requirements
which are similar to previous software project requirements.
Future developments shall include automated programming from requirements in
natural language. Analysis of requirements can allow the design of software system
which can be converted into code. This process can be achieved if the natural language
requirements are converted into formatted specification.
This section offered insight into future directions of this research effort. Future
research areas and the enhancements that can be made from this thesis effort were
addressed.
Texas Tech University, Henry Johnson, December 2010
70
REFERENCES
[Accept2010] Accept Corporation, Accept360, http://www.accept360.com/index.html,
Aug 2010
[Accompa2010] Accompa Inc, Accompa, http://www.accompa.com/, Aug 2010
[Barney2008] S. Barney, A. Aururn, and C. Wohlin, A Product Management Challenge:
Creating Software Product Value Through Requirements Selection, Journal of
Systems Architecture Volume 54, Issue 6, Pages 576-593, June 2008.
[Caliber2010] CaliberRM, Borland, http://www.borland.com/us/products/caliber/index.
html, Aug 2010
[Cheng1992] H. Cheng, “A Language Processor for Real –Time Descartes Specification
Language,” M.S. Thesis, Department of Computer Science and Engineering,
Arizona State University, June 1992.
[CORE2010] CORE, Vitech , http://www.vitechcorp.com/, Aug 2010
[Cradle2010] Cradle, 3SL, http://www.threesl.com/, Aug 2010
[Dhlamini2009] J. Dhlamini, I. Nhamu, and A. Kachepa, “Intelligent Risk Management
Tools for Software Development,” Southern African Computer Lecturers
Association (SACLA), South Africa, 2009
[DOORS2010] DOORS, IBM, http://www-01.ibm.com/software/rational/, Aug 2010
[Fairley2009] R. E. Fairley, “Estimation techniques,” in Managing and Leading
Software Projects, 1st ed, John Wiley & Sons, Inc., Hoboken, New Jersey, 2009.
[Focalpoint2010] Rational Focal point, IBM, http://www-01.ibm.com/software/awdtools
/focalpoint/, Aug 2010
Texas Tech University, Henry Johnson, December 2010
71
[Hanakawa2004] N. Hanakawa and K. Okura, “A Project Management Tool Using
Communication for Agile Software Development,” Proceedings of the 11th
Asia-
Pacific Software Engineering Conference (APSEC), pp. 316-323, 2004
[IEEE1998a] ANSI/IEEE, “IEEE Standard 830-1998 Recommended Practice for
Software Requirements Specification,” ANSI/IEEE, 1998.
[IEEE1998b] ANSI/IEEE, “IEEE Standard for Software Project Management Plans,”
ANSI/IEEE, 1998.
[Joo1994] H. Joo, “Automated Test Case Generation from Descartes Specifications,”
M.S. Thesis, Department of Computer Science and Engineering, Arizona State
University, Dec 1994.
[Khwaja1993] A. A. Khwaja, “A Visual Syntax-Directed Editor for the Descartes
Specification Language,” M.S. Thesis, Department of Computer Science and
Engineering, Arizona State University, May 1993.
[Kiyavitskaya2008] N. Kiyavitskaya, N. Zeni, L. Mich, and D.M. Berrry, “Requirements
for Tools for Ambiguity Identification and Measurement in Natural Language
Requirements Specifications,” Requirements engineering archive, Volume 13,
Issue 3 pp. 207-239, 2008
[Kotonya2003] G. Kotonya and I. Sommerville, “Requirements Engineering Processes,”
in Requirements Engineering Processes and Techniques, John Wiley & sons
Ltd., July 2003
Texas Tech University, Henry Johnson, December 2010
72
[Lee1991] L. Lee, “Visual Representation of Descartes Specifications,” M.S. Thesis,
Department of Computer Science and Engineering, Arizona State University,
June 1991.
[Luqi 2007] K. Luqi and F. Kordon, Advances in Requirements Engineering: Bridging
the Gap between Stakeholders From Stakeholders' Needs and Formal Designs,
14th Monterey Workshop, 2007.
[Puchala2010] S. Puchala, “Analysis and Implementation of Various Techniques for
Software Requirements Engineering,” M.S. Project, Department of Computer
Science, Texas Tech University, Aug 2010.
[Sampaio2005] A. Sampaio, R. Chitchyan, and A. Rashid, “EA-Miner: A Tool for
Automating Aspect-Oriented Requirements Identification,” Proceedings of the
20th
IEEE/ACM International Conference on Automated Software Engineering
(ASE), ACM, pp.353-355, 2005
[Sung1992] K. Sung, “Real-Time Extensions to the Descartes Software Specification
Language,” Ph.D. Dissertation, Department of Computer Science and
Engineering, Arizona State University, Dec 1992.
[Tung1993] Y. Tung, “A Language-Based Visual Editor for the Descartes Specification
Language,” M.S. Thesis Department of Computer Science and Engineering,
Arizona State University, May 1993.
[Urban1977] J.E. Urban, “A Specification Language and Its Processor,” Ph.D.
Dissertation, Computer Science Department, University of Southwestern
Louisiana, Dec 1977.
Texas Tech University, Henry Johnson, December 2010
73
[Wohlenburg1992] G. S. Wohlenburg, “An Object-Oriented Software Design Aid for
Use with a Formal Software Specification Language,” M.S. Thesis, Department
of Computer Science and Engineering, Arizona State University, May 1992.