Henry Johnson, B.Tech. A Thesis COMPUTER SCIENCE

(1)

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

(2)

(3)

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.

(4)

iii

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.

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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

(12)

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;

(13)

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.

(14)

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

(15)

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

(16)

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.

(17)

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

(18)

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.

(19)

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

(20)

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

(21)

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

(22)

14

phases of software development. Most of the tools does not provide support to all the phases of the software development life cycle. Some of the evaluated tools Accept 360, Accompa, and Focal point provide the software project management capabilities. The project management capability of Accept 360 included agile development methods, risk management and project planning methods. The Accompa requirements engineering tool provides risk management and collaborate with customers and internal stake holders. The Rational Focal Point tool provides risk management, customer collaboration.

Table 2. 1: Comparison of web-based requirements engineering tools

Tools Features Web -based tool Require-ments manage-ment Software project manageme-nt capabilities Automated Requirements verification Extension to all phases of software development Commu-nication between users

Accept 360 Yes Yes Yes No No Yes

Rational DOORS

Yes Yes No Yes No No

Accompa Yes Yes Yes No No Yes

CORE Yes Yes No No Yes Yes

Cradle 6.3 Yes Yes No No No Yes

Rational Focal Point

Yes Yes Yes No No Yes

CaliberR M

(23)

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.

(24)

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.

(25)

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;

(26)

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.

(27)

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.

(28)

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

(29)

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

(30)

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.

(31)

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.

(32)

24

CHAPTER III

AN OVERVIEW OF DESCARTES SPECIFICATION LANGUAGE

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

(33)

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,

(34)

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*

(35)

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.

(36)

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.

(37)

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

(38)

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.

(39)

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#

(40)

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.

(41)

33

CHAPTER IV

REQUIREMENTS TOOL EVALUATION CRITERIA

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:

(42)

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

(43)

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.

(44)

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.

(45)

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

(46)

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.

(47)

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 ₂ ₃ ₃ ₃ ₃ ₂ ₃ 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

(48)

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.

(49)

41

CHAPTER V

REQUIREMENTS FOR THE PROPOSED CASE TOOL

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.

(50)

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