Henry Johnson, B.Tech. A Thesis COMPUTER SCIENCE

Transcription

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 December, 2010

2 Copyright 2010, Henry Johnson

3 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. ii

4 TABLE OF CONTENTS ACKNOWLEDGMENTS... ii ABSTRACT... v LIST OF TABLES... vi LIST OF FIGURES... vii I INTRODUCTION State of Problem Research Objectives Research Methodology Benefits of the Completed Research Summary... 5 II AN OVERVIEW OF REQUIREMENTS ENGINEERING TOOLS Introduction Software Requirements and Formal Specification Requirements Engineering Process and its Tool Support Requirements Elicitation Requirements Analysis Requirements Negotiation Requirements Documentation Requirements Validation Requirements Engineering Tool Comparison Advancement in Requirements Engineering Tool Support Research Efforts on CASE Tools Natural Language Processing Tool Research EA Miner Tool Software Project Management Support Tool Intelligent Risk Management Tools for Software Development Summary III AN OVERVIEW OF DESCARTES SPECIFICATION LANGUAGE Introduction Data Structuring Specification Construction Using Descartes An Example Specification Summary IV REQUIREMENTS TOOL EVALUATION CRITERIA Introduction Evaluation Criteria and Procedure Tool Evaluations Summary V REQUIREMENTS FOR THE PROPOSED CASE TOOL Introduction Web-Based Tool Requirements Engineering and Design Requirements Management Requirements Verification and Validation iii

5 5.4 Software Project Management Capabilities Software Testing and Maintenance Implementation Methods Validation of Requirements for the Proposed CASE tool Summary VI EVALUATION OF THE PROPOSED CASE TOOL BASED ON IEEE STD Introduction Evaluation Based on IEEE std Summary VII SUMMARY AND FUTURE WORK Summary Future work REFERENCES iv

6 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 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. v

7 LIST OF TABLES 2.1 Comparison of web-based requirements engineering tools Evaluation of the requirements engineering tools Evaluation of the requirements engineering tools using the IEEE std Traceability of operational features to primary requirements vi

8 LIST OF FIGURES 3.1 Specification to output the number of words of an input document Use Case diagram for the web-based CASE tool Flow chart for the analysis of requirements to identify classes and the relationship between classes vii

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

10 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 , 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 2

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

12 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; 4

13 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. 5

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

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

16 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. 8

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

18 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. 10

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

20 multiple locations. The distributed database can be controlled by a central database management system (DBMS) 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 Requirements Validation IEEE standard is the recommended standard for a good Software Requirements Specification (SRS). The IEEE std 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 12

21 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 webbased 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 13

22 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 Requirements management Automated Requirements verification Extension to all phases of software development Software project management capabilities Communication 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 CaliberR M Yes Yes Yes No No Yes Yes Yes No No No Yes 14

23 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. 15

24 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 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. 16

25 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 penaltyweighted 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 17

26 (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 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. 18

27 Features: The EA-Miner tool uses the WMATRIX natural language processor to preprocess 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. 19

28 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 , 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 20

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

30 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. 22

31 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. 23

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

33 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, 25

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

35 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 b c a b 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. 27

36 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. 28

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

38 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. 30

39 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# 31

40 LETTER return+ words. NL a b c d.. z Texas Tech University, Henry Johnson, December 2010 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. 32

41 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 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 recommended practice for Software Requirements Specification (SRS) are: 33

42 Correct: According to the IEEE standard [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 , An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Complete: According to IEEE standard , 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 , 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 , 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. 34