Requirements Verification and Validation

The requirements engineering tool must automate the requirements verification and validation of the requirements document. The Descartes specification language should be used to formalize the requirements verification and validation feature of the proposed CASE tool. The Descartes specification language satisfies all the characteristics of the IEEE std. 830-1998. Using the Descartes specification language, a natural language requirements document can be analyzed to automatically generate formal specification. When the input is considered as a sequence of characters, the Hoare tree can match the patterns using specification in Descartes. By analyzing the specification, the tool should automatically generate candidate classes and their associated relationships in the software using the requirements documents. The specification should also allow the requirements engineers to understand the requirements document more clearly than a natural language specification. Another use of software specification is to automatically check whether the requirements are correct, consistent, and unambiguous. The proposed CASE tool should be able to automatically trace dependencies between each requirement to every other requirement.

2.2.1 The tool must be able to analyze the Software Requirements Specification (SRS). After the analysis of the requirements, the CASE tool should output a formatted specification. This formatted specification is only applicable for architectural or

Texas Tech University, Henry Johnson, December 2010

49

functional requirements. Each requirement has tool parts: the actor and the action. The action and the actor are usually connected using a key phrase „must‟, „shall‟ or „should‟. The tool should be able to extract the actor and the action from each requirement.

2.2.2 The tool must analyze the candidate classes and their associated relationships among the classes. The analyzed specification can generate the possible classes of the software system. The „IS-A‟ and „HAS-A‟ relationships of each classes can also be generated using this analysis.

2.2.3 The tool must generate a report of the SRS analysis. The report consists of formatted specification, classes, and class relationship. The report is produced by user‟s prompt.

2.2.4 The server must store the report for each SRS. Each report generated at the requirements analysis phase should be stored for future references at different stages of software development.

2.2.5 The tool must allow a user to check for poor words in each requirement automatically. The poor words such as „etc‟, „might‟, and „may‟ are some of the poor words often found in requirements. Requirements with such poor word are usually incomplete and may require further validation. The actual purpose of the requirements is to give a clear idea of what the software system should perform or certain constraints in software development.

2.2.6 The user with read/edit privileges must be able to change and confirm the reports and change the analyzed requirements in the SRS. The reports generated by the tool

Texas Tech University, Henry Johnson, December 2010

50

consist of formatted specification, possible classes and class relationships. Any user can view the reports, but only the user with the read/edit privileges can change the reports and submit them to the database.

2.2.7 The user can analyze of requirements at any time in the scope of the software project. The best case for analysis of a requirements document is at the requirements engineering phase. In real world projects, the requirements may vary at any time due to the changes in the needs of the customer. The changes in requirements improvise a change in the design. Thus, the requirements analysis at any time is important for effective software development.

Figure 5.2 shows the flow chart diagram of the identification of the classes and their relationships from the natural language requirements in the proposed CASE tool. The aim of the identification process is to report the classes and their relationship to the users and the users can further elaborate and then confirm the report. The identification process can lead to automation steps in the design phase.

Texas Tech University, Henry Johnson, December 2010

51

Figure 5.2: Flow chart for the analysis of requirements to identify classes and the

relationship between classes.

5.4 Software Project Management Capabilities

Software project management using requirements engineering tools can speed up software development. CASE tools for requirements engineering can be extended to software project management for effective planning and budgeting of the software projects. The requirement tools thus produced could allow for the use of formal methods for software project planning, budgeting, and estimation. The area of risk analysis in the

Texas Tech University, Henry Johnson, December 2010

52

software project could also be included in the requirements engineering tools. The requirements for the tool to enable the software project management capabilities are: 3.1 The user must be able to enter the estimated Lines Of Code (LOC) for each

requirement. The user can enter the LOC required for the particular requirements in the LOC block of the database. The tool can also automatically generate the LOC at the requirements analysis from previous reports and similar requirements. The tool must trace the requirement from previous project and assign the LOC to the new requirement.

3.2 The tool must be able to calculate the duration, budget and number of staff members required for the project. The sum of LOCs of all the requirements and the salary for each staff-month is used to calculate the number of staff members and budget, respectively, for the software project. There are many estimation models for software development [Fairly2009]. Calculation of budget and number of staff members allows the customers and software company to understand approximate estimation of the project.

3.3 The tool must use three different formal methods in software project estimation. The higher the number of estimation method, the better will be the estimated values. The average values of all the estimations used in the tool should be considered for the software development effort. The estimation of software allows the project manager to effectively plan the project.

3.4 The tool must analyze the risk automatically by the users‟ prompt. Risk analysis of requirements is the identification of poor word which may affect the later design

Texas Tech University, Henry Johnson, December 2010

53

phase of the software development. The risk of each requirement may vary and may cause a failure of the software system.

3.5 The risk analysis report is generated to the user. The risk reports should be developed using bar charts each requirement risk is denoted on each bar. The requirements showing the higher risks should be reviewed by the user to avoid failure in software design.

3.6 The user with read/edit privileges must be able to change and confirm risk for each requirement. The users with read/edit privileges should be able to change the risk levels manually.

3.8 The tool must allow the online users of the same project to securely communicate using text messages. Short message communication allows effective and fast information sharing between the users of the tool. The chat messages are quick and can be archived for future reference. Activities such as requirements negotiation or requirements elicitation can be achieved using the chat message communication between the customers and the requirements engineers.

3.9 The user with read/edit privileges must be able to create a software project management plans. Software project management template was tailored from the IEEE standard 1058-1998 [IEEE1998b] for software project plans document. The tool should allow the user to create a software project plan template with a front matter with the title, revision history, preface, table of contents, list of figures, and list of tables. The project summary in the project plan template consists of purpose, scope and objectives, assumptions, constraints, project deliverables, schedule and budget

Texas Tech University, Henry Johnson, December 2010

54

summary. The project plan template further includes evolution of the plan, references, and definition. The tool allows the users with read/edit privileges to input the data for each section.