Applications of use case in software planning
1. Functionality description
One of the uses of use case is in the functional description. Use case models are used in object-oriented requirement analysis for capturing and describing the functional requirements of a system [4]. It is a dynamic modeling technique which corrects the limitations of structured modeling which is static modeling technique [5]. This modeling technique is so important to software development since it uses diagram as a modeling tool. Knowing that software is intangible, using use case model makes it tangible and therefore visible. Several methods for estimating software development effort are based on attributes of a use case model.
2. Project Cost estimation
Another use of use case in project planning is in cost estimation. The best use case for cost estimation is the use case point. In general, projects with large, complicated use cases take more effort to design and implement than small projects with less complicated use cases [6]. The use case points method is a useful model of estimating effort and cost on software development projects [7]. The number and weight of the use cases identified is the most important component in the calculation of the complexity of the use case points. The size of a system is calculated from the unadjusted use case points by adjusting them with the technical complexity factor, obtained from a consideration of the system's technical properties. In general, projects with large, complicated use cases take more effort to design and implement than small projects with less complicated use cases.
Project duration estimation
The time it takes to finish project depends on the number of use case points which also depend on the size of the application. The duration of the project is obtained from the use case point and the progress rate of the team. The number of use case points in a project is a function of the following [8]:
· The number and complexity of the use cases in the system
· The number and complexity of the actors in the system
· Various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
· The environment in which the project will be developed
3. Deriving Test Cases
Another use of use case is in writing functional test cases. It is used to estimate how a program should behave if it is working properly [9]. Deriving test cases from use cases proved to be easy since the interest is how the user would interact with the program to accomplish various tasks. Each test case represented one specific scenario of interaction with the system, within the context of one of the essential use cases. The test case might result in a successful transaction, or it could generate an anticipated error response of some kind. A use case provided enough detail to permit writing many test cases. Having test cases in hand this early in the development process provided several benefits:
· We could use the test cases to "test" the dialog map. As we walked through the conceptual test cases derived from the SRS, I traced the corresponding paths on the dialog map with a highlighter pen. This revealed allowable execution paths we had missed in the test suite, as well as identifying test cases that could not be "executed" according to the current dialog map, indicating errors in either the dialog map or the test cases.
· We could establish traceability between each test case and the requirements it addressed. Any requirements that were not covered meant writing more test cases; any test cases that relied on functions not present in the requirements document showed that some requirements were missing.
· We could use the suite of test cases to evaluate commercial products that might meet the needs of the project, enabling us to decide whether to build or buy. We simply had to walk through the test cases with an evaluation copy of the commercial package to see which cases it handled and which it did not. The test cases that mapped to top priority use cases were the ones to focus on.
· Developing test cases early in the project reinforced the developer’s fundamental philosophy that quality activities must not be left to the end of the development cycle, but should permeate the entire project from the outset.