copyright 2010, henry johnson

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

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.


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


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


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.


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


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


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


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


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


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;


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.


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


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

http://en.wikipedia.org/wiki/Software_system

http://en.wikipedia.org/wiki/Software_system

http://en.wikipedia.org/wiki/Structure

http://en.wikipedia.org/wiki/System


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.


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


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.


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


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


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


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


CORE Yes Yes No No Yes Yes

Cradle 6.3

Yes Yes No No No Yes

Rational

Focal

Point


CaliberR

M

Yes Yes No No No Yes


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.


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.


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


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.


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.


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


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


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.


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.


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


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,


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


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.


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.


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


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.


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#


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.


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:


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.”


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.


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.


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


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.


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


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.


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.


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


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


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.


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.


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.


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


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


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


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.


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


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


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


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.


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.


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

http://en.wikipedia.org/wiki/Man-month


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


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.


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


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.


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.


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


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


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.


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.


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


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


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


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.


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

http://www.accept360.com/index.html

http://www.accompa.com/

http://www.sciencedirect.com/science/journal/13837621

http://www.sciencedirect.com/science/journal/13837621

http://www.sciencedirect.com/science?_ob=PublicationURL&_tockey=%23TOC%235673%232008%23999459993%23690583%23FLA%23&_cdi=5673&_pubType=J&view=c&_auth=y&_acct=C000055350&_version=1&_urlVersion=0&_userid=2605799&md5=6f54f5b3e3fb86ffd7e6ef424bfd339d

http://www.borland.com/us/products/caliber/index.%20html

http://www.borland.com/us/products/caliber/index.%20html

http://www.vitechcorp.com/

http://www.threesl.com/

http://www-01.ibm.com/software/rational/

http://www-01.ibm.com/software/awdtools%20%20%20%20/focalpoint/

http://www-01.ibm.com/software/awdtools%20%20%20%20/focalpoint/


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


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.


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.

copyright 2010, henry johnson

Documents