Metrics for use cases: a survey of current proposals

Metrics for Use Cases: A Survey of Current Proposals Beatriz Bernárdez1, Amador Durán1 and Marcela Genero2 1 Department of Computer Languages and Systems University of Seville Avda. Reina Mercedes, s/n. 41012 Sevilla (Spain) {beat,amador}@us.es 2ALARCOS Research Group, Department of Computer Science University of Castilla-La Mancha Paseo de la Universidad, 4. 13071 Ciudad Real (Spain) [email protected] 1 Introduction In this chapter, the current state–of–the–art of use case metrics is presented. Before describing the different proposals, the concept of use case itself is discussed. This discussion is necessary because of the different use case approaches that have been proposed since the original work by Jacobson et al. (1992) was published. These approaches vary from use cases expressed as informal, plain prose to extremely detailed message sequence diagrams, causing confusion about the concept and role of use cases in software development. This confusion has been increased by the ambiguity of the use–case specification in the UML standards (OMG, 2003), especially by the so–called use case relationships. Obviously, the concrete form in which use cases are used and expressed dramatically affects their measuring, as noted in Henderson-Sellers et al. (2002). Therefore, use case metrics must be always understood in the context of a specific use case format and purpose. After introducing the reader to the concept of use case in the next section, several proposals for use case metrics are discussed. The proposals are grouped depending on their measurement goal. In section 3, use case metrics for project estimation are presented, including proposals by Karner (Schneider and Winters, 1998), Marchesi et al. (1998) and Smith (1999). In section 4 use case metrics for improving the requirements engineering process are discussed, including proposals by Saeki (2003) and Bernárdez et al. (2004). Finally, in section 5 the conclusions and a summary of the main proposals are presented. The reader must always have in mind that the metrics proposals discussed in this chapter are still in a very early stage. Most of them are only initial proposals that have not been neither theoretically not empirically validated yet, as commented in the conclusions section. 2 The concept of use case Use cases are a scenario–based technique initially proposed by Jacobson et al. (1992) that can be used for different purposes in software development, especially during requirements engineering. As a scenario–based technique, use cases tell stories describing interactions between some so–called actors, i.e. people or other systems with some goal to be achieved, and a system under discussion (SuD) providing some services needed to achieve actors’ goals. The SuD has not necessarily to be a software system, it may be a computer–based information system encompassing hardware, software and people (see section Dimensions of use cases for details on use case scoping). 2.1 Roles of use cases in requirements engineering As commented in Cockburn (2001), one of the best books on use cases, they can play different roles in the requirements engineering process, the following being the most usual: As a mean of understanding and describing current business processes, where they are called business use cases by some authors like Cockburn (2001) or Leffingwell and Widrig (2000), or simply scenarios as in Leite et al. (2000). As a mean of focusing discussion about the requirements of the system to be built, but not to be the requirements description, i.e. as a requirements elicitation technique but not as a requirement documentation or specification technique. In this case, use cases are eventually transformed into lists of typical functional requirements. As part of the functional requirements of the system to be built, which is probably the role they play more often. This is the main purpose of use cases as described in the latest UML specification (OMG, 2003) and in other publications (Cockburn, 2001; Leffingwell and Widrig, 2000; Schneider and Winters, 1998). Notice that, as stated by Cockburn (2001), "they really are requirements but they are not all of the requirements". Other kinds of requirements like information requirements, business rules or non–functional requirements cannot be expressed as use cases but must be part of any complete requirements specification. At the moment of writing, use cases are the most popular requirements elicitation technique in software industry1 and they are becoming an actual alternative to typical specifications of functional requirements composed of hundreds of sentences starting with "the system shall". As discussed in Cockburn (2001), use cases can be considered as contracts for behavior, thus rising Meyer’s contract concept from programming to requirements. All of the analyzed proposals for use case metrics assume that the measured use cases are part of a system or software requirements specification. We will also make the same assumption in the rest of this chapter for the sake of simplicity. 1 The interested reader can see the article by Weidenhaput et al. (1998) for an excellent survey on how use cases are applied in European software industry. 2.2 Dimensions of use cases Other criteria for classifying use cases apart from their purpose are their scoping, goal level and visibility, as proposed in Cockburn (2001) and graphically depicted in figure 1 as three orthogonal dimensions. Figure 1. Cockburn’s dimensions of use cases 2.2.1 Scoping The scoping of a use case can be at an organizational level if describes stories between actors and organizations, which is the usual scope of the previously mentioned business use cases. The scoping is at a system level or component level if actors interact with a computer–based system or with a subsystem or a component of a computer–based system. The two latter scoping levels are the usual when writing system or software requirements specifications. 2.2.2 Goal level The goal level of a use case indicates its level of abstraction with respect to user goals. For expressing the goal level, Cockburn proposes a metaphor in which height relative to sea level resembles goal level. The sea level corresponds to the user goal level, which is the level at which most use cases are usually described. Those higher–level use cases in which interactions are themselves user goals are said to be at a summary or very high summary level, depending on their level of abstraction. Since these use cases are above the sea level, they are represented by a kite (summary) or by a cloud (very high summary)2. User–goal– level use cases are usually performed in no more than a few minutes (what Cockburn calls a single–sitting), whereas summary use cases requires the completion of several user goals to 2 A similar classification is described in Regnell et al. (1996), where environment, structure and event are proposed as levels of use case detail. be performed and can take longer to complete. 2.2.3 Visibility The visibility of a use case indicates whether it describes the internal structure of the SuD or only its external, observable behaviour. In the former case, the use case is said to have a white box visibility, whereas in the latter case it is said to have a black box visibility. Needless to say, the latter is the usual visibility when using use cases as specifications of functional requirements, following Davis recommendations (Davis et al., 1993). Most of the metrics proposed for use cases focus on use cases with the underlined characteristics in figure 1, i.e. use cases at system scope, at user goal level and with a black box visibility. Because of that, these will be considered as the default values of Cockburn’s dimensions for the rest of this chapter. 2.3 Specification of use cases Jacobson et al. (1992) made use cases very popular, but they did not provide much guidance on how to specify them. As a result, a plethora of use case templates, notations and writing guidelines have bloomed in the last years. Use cases, as a scenario–based technique, are fundamentally text–based. Others formats like UML activity and sequence diagrams or Petri nets can be used for specifying use cases but, as recognized by Cockburn (2001), Kulak and Guiney (2000) and other practitioners, stakeholders without a software engineering background usually understand written stories using the vocabulary of the problem domain better than any other software–oriented diagrammatic notation. Assuming that use cases are basically text, there are still many possible ways of specifying them, from plain prose to structured English. Regardless of the writing style, one commonly agreed point is that any use case specification must describe a sequence of interactions between actors and the SuD, usually numbering the steps performed during the interactions in order to achieve some actor’s goals. A thorough discussion of all the proposed templates for use case specification is out of the scope of this chapter, but a summary of some of them is essential in order to understand some of the metrics proposals. Notice that, as actual requirements templates, use cases templates usually include requirements attributes3 like a unique identifier, version, status, stakeholders, writers, dependencies on other requirements, associated non–functional requirements, etc. As commented in following sections, use–case metrics based on some of these attributes like the number of stakeholders with a stake on the use case, the number of dependencies of the use case or the number and type of associated non–functional requirements, should be taken into consideration when using use cases for effort estimation. 3 The interested reader can see Davis (1993) or Sommerville and Sawyer (1997) for more details on requirements attributes and requirements management. 2.3.1 Cockburn’s template One of the first, most widely used templates for use case specification was initially proposed in (Cockburn, 1997) and later reviewed by its author in (2001). Its most relevant elements are the following: Name, scope, level and visibility: the name of the use case is the primary actor’s goal in a short, active verb phrase. The primary actor is the actor requesting services from the system, usually triggering the use case. In Cockburn’s template, the use case name is decorated with the corresponding scope, level and visibility icons (see figure 1). Preconditions: the preconditions of a use case are assertions about the state of the SuD and its environment — the state of the world in Cockburn’s words — that will be checked before letting the use case start and that will not be checked again during the use case execution. Minimal and success guarantees: Cockburn considers two different groups of postconditions depending on whether the use case ends successfully or not, i.e. whether the primary actor’s goal is achieved or abandoned. Minimal guarantees must hold regardless of the success or failure of primary actor’s goal. Success guarantees must hold only when the use case concludes successfully. Trigger: a trigger is an event that fires the execution of a use case. Depending on the writing style, it can be considered as the first step of the use case or specified outside the main success scenario. Main success scenario: the main success scenario is a numbered sequence of steps performed during the execution of a use case that leads to a situation in which the primary actor’s goal is achieved. Apart from including another use case, Cockburn considers three possible kinds of action to be performed in a step: an interaction between two actors (considering the SuD as a special kind of actor), a validation step, and a internal change of the SuD (even if the visibility of the use case is black box). The number of actions to be included in a single step depends on the writing style4, although one or two actions are the usual number. Cockburn also recommends not using conditional steps in the main success scenario but considering them as extensions. Extensions: extensions are branches of the main success scenario depending on a particular condition — the extension condition — in a given step. Some of these branches can lead to success while other can lead to failure of the use case. Cockburn recommends using extensions for handling both situations, while other authors like Leite et al. (2000) or Durán et al. (2002) use conditional steps for successful, usual branches and exceptions for branches triggered by exceptional conditions usually leading to use case failure. 4 See Cockburn (2001), pages 93–95, for details about including a reasonable set of actions in a single step. Technology and data variations: Cockburn considers different ways of performing a step as variations, like using different payment methods, different data during an identification of a user, etc. They are not considered to be alternative branches, i.e. they have neither condition nor steps. 2.3.2 RUP template The Rational Unified Process (RUP) (Kruchten, 2000) is a software engineering methodology developed by the Rational company (now a company of IBM) after the Unified Process (UP) (Jacobson et al., 1999). One of its defined artefacts is the RUP use case template, including the following elements: Name: like in Cockburn’s template, the name of the use case in the RUP template is a short description of primary actor’s goal, although is augmented with a brief description in which a short summary of the use case is provided. Pre– and postconditions: in the RUP template, a precondition is defined as the state of the system that must be present before the use case starts. Postconditions are defined as a list of the possible states the system can be in after a use case has finished. Kruchten (2000) does not specify if postconditions must always hold or if they must only hold on successful ending of the use case, which seems to be the usual semantics. Notice that unlike in Cockburn’s template, pre– and postconditions in the RUP template do not take the SuD environment into consideration. Basic flow: the basic flow is a numbered sequence of steps describing what actors do and what the system does in response. In the RUP template, conditional branches are allowed provided they are composed of only a few steps. In case of complex alternative branches, using an alternative flow is preferred. As in Cockburn’s template, the action of a step can be a inclusion of another use case (or an extension if the step is conditional). Alternative flows: alternative flows describe alternative behavior usually due to exceptions that occur in specific steps in the main flow. When an alternative flow ends, the main flow is resumed unless otherwise stated. If needed, alternative flows can be divided into alternative subflows at arbitrary depth, although that use is discouraged. Extension points: in the UML 1.5 specification (OMG, 2003), an extension point is defined as a reference to one or a collection of locations in a use case where the use case may be extended. An extend relationship defines that a use case may be — i.e. depending on a extension condition— augmented with some additional behavior defined in another use case. From our point of view, one of the problems of this vague description of, a probably unnecessary, concept is that extensions points are not related to any step in neither the basic flow nor the alternative flow. In other words, they seem to be unattached labels for the starting points of alternative flows expressed as separate use cases. 2.3.3 Leite’s template Leite et al. (2000) proposes not only a scenario template but also a whole process for scenario construction. A important difference in this approach is that Leite’s scenarios are tightly coupled with a lexicon containing concepts from the problem domain. In this way, Leite ensures that scenarios are written using the vocabulary of customers and users, thus enforcing their communicability. The most relevant elements of this template are the following: Title and goal: Leite’s template includes both a name and a goal. Usually, the former is a short form of the latter. Context and resources: in Leite’s template, preconditions are part of the context of the scenario, which describes a geographical location, a temporal location and preconditions. Leite also includes information about relevant resources, i.e. physical elements or information, that must be available during the scenario performance. Postconditions are not considered in this template. Episodes: the episodes of Leite’s scenario template are basically the same as the numbered sequences steps of previously discussed templates. In this template, episodes can include other scenario or describe a simple interaction. Conditions can be included in the episode sequence, but they affect only one episode. For conditional branches composed of more than one episode, scenario inclusion must be used. Leite also considers optional episodes, i.e. steps that may or may not be performed depending on conditions that cannot be explicitly detailed. Notice that groups of non–sequential episodes can also be defined in a Leite’s template, thus allowing a parallel or indistinct sequential order. Exceptions: this section of Leite et al.’s template contains the specifications of exceptional situations due to the lack or malfunction of some of the previously mentioned resources. The main differences with other templates are that exceptions are not associated to specific steps, and that only one action can be specified as the exception treatment, although that action can be a scenario inclusion. 2.3.4 Durán’s template Durán’s template for use cases, formerly published in Durán et al. (1999), is one of the results of the PhD. thesis of one of the authors of this chapter (Durán, 2000). The most relevant characteristic of this template is that for a number of its elements some linguistic patterns are provided, thus easing use case writing5. Another interesting aspect of this template is that is fully supported by the free requirements management tool REM (Durán, 5 A description of linguistic patterns is out of the scope of this chapter. The interested reader can see Durán et al. (1999) for details. A more extensive work on the use of linguistic patterns for use cases can be found in Ben Achour et al. (1999), one of the results of the CREWS project. 2003), as shown in figure 2. Its basic elements are the following: Figure 2. Support for use cases in REM Name: the name of the use case is, as in Cockburn’s template, a short verb phrase stating the goal of the use case from the primary actor’s point of view. Description: the description is based on a linguistic pattern including the triggering event of the use case. The simplified structure of this linguistic pattern is "the system shall behave as described in the following use case when <triggering event>". Notice that Durán considers the triggering event at the business level, whereas the first step of the ordinary sequence is usually a request of service from an actor to the system (see figure 3 for an example). Preconditions: preconditions include assertions that must be true in order to reach the goal of the use case. Like in Cockburn’s and Leite’s templates, preconditions are expressed not only on the system state but also on its environment. Ordinary sequence: the ordinary sequence describes the steps performed to achieve the use case goal when everything goes right, including single conditional steps like in Leite’s template. The actions performed in any step can be actor actions (actor–to–actor or actor–to–system actions), system actions (usually only externally observable actions) or the performance of another use case (an UML inclusion or extension, depending on whether the step is conditional or not). Postcondition: postconditions include assertions about the system and its environment that must hold provided the use case ends successfully. Exceptions: exceptions have the same structure than in Leite’s template plus additional information specifying if the use case is resumed or canceled after exception treatment. UC–0015 Register Book Loan Dependencies • OBJ–0001 To manage book loans (objective) • OBJ–0005 To know library users’ preferences (objective) • CRQ–0003 Maximum number of simultaneous loans (business rule) • CRQ–0014 Return date for a loan (business rule) Description The system shall behave as described in the following use case when a library user requests a loan of one or more books. Precondition The library user has been identified by means of his or her identity card and has picked up the books to loan from the shelves. Ordinary sequence Step Action 1The librarian requests the system for starting the book loan registering process. 2The system requests for the identification of the library user requesting a loan. 3The librarian provides identification data of the library user to the system. 4The system requests for the identification of the books to be loaned. 5The librarian provides identification data of the books to be loan to the system. 6The system displays the return date for each of the books to be loan and requests loan confirmation for each of them. 7The librarian tells the user library the return dates displayed by the system and ask him/her if he or she still wants to loan each book. 8The library user confirms the librarian which books he or she wants to loan after knowing return dates. 9If some of the confirmed books have an associated multimedia item, then use case “Add item multimedia to loan” is performed. 10 The librarian re–confirms the book loans confirmed by the library user to the system. 11 The system informs that the book loans have been successfully registered. Postcondition The library user can take the loaned books away and the system has registered the book loans Exceptions Step Action 3If the library user has already reached the maximum number of simultaneous loans or has a penalty, the system informs of the situation, then this use case cancelled. Comments The maximum number of simultaneous book loans and the loan period depend on the library policy and can change in the future. See business rules CRQ–0003 y CRQ–0014. Figure 3. Use case example using a simplified version of Durán’s template 2.4 Use case diagrams Apart from their textual specification, use cases, their actors and their relationships can be depicted in the so–called use case diagrams. Use case diagrams were part of the initial proposal by Jacobson et al. (1992) and, with minor changes, they are also present in the current UML specification (OMG, 2003). As commented by some authors like Cockburn (2001) or Kulak and Guiney (2000), use case diagrams must be understood only as a table of contents of use cases, not as an alternative of their textual specification. In use case diagrams, only the name of the use cases, the participating actors and some use case relationships are shown. The essence of use cases, i.e. their sequence of actor–system interactions, cannot be in anyway derived from use case diagrams. An example of a use case diagram can be seen in figure 4, where the system boundary is represented as a box containing some use cases. Actors are In order to solve this problem there are some alternatives. Some of them suggest to classify use cases according to their detail level and then estimate the effort to implement them according to their assigned level. Other proposals count the number of analysis classes, which correspond to each use case, and based on this, they can estimate the effort of implementing it. 3.2.1 Karner’s proposal The proposal done by Karner (Rational Software) and collected in Schneider and Winters (1998) defines the concept use case points, analogue to the function points concept. Use case points is useful to estimate the effort (in man-hours) of development project. The metric use case points ( UCP ) is defined as: EFTCFUUCPUCP  Where:  UUCP is the metric called unadjusted use case points. This metric is calculated as the weighted sum in number of actors and number of use cases in the requirements specification. Each actor and use case can have a different complexity. This provokes the weighing in the calculation of UUCP . The weights of the actors figure in table 1. The complexity of use cases depends on one of two factors: the number of steps, and the number of analysis classes corresponding to the use case. Tables 2 and 3 show the possible weights of the use case.  TCF represents a technical complexity factor. This factor increases if there are complex non-functional requirements, for example, if the system is distributed, the code must be reusable or easy to change, etc. In table 4 you can see which factors have influence in TCF . Those factors have a weight between 0.5 and 2. According to the importance of this factor in the system, this weight will be multiplied by a number between 0 and 5 (0 means that the factor is not present in the system).  EF represents the level of experience of the technical personnel that work in the project. The stability of the project also has influence on the value of EF . Once the value of UCP is calculated, in order to estimate system effort Karner suggests applying the factor 20 man-hours per UCP . However, data obtained of its application in real projects advises that it is convenient to adjust this quantity. One of these revisions is shown in Schneider and Winters (1998) which comments that it would be beneficial to adjust this quantity depending on the EF value. If the EF is highly affected by change in staff, this will provoke more effort in training team members or provoke the convenience of solving instability problems. In this case Schneider advises to use 28 man-hours per UCP . In Banerjee (2001) it is also provided another possibility: to increase the number of man-hours to 36 per UCP . The reason for this approach is that negative numbers mean extra effort spent on training team members or problems due to instability. However, using this method of calculation means that even small adjustments of an environmental factor, for instance by half a point, can make a great difference in the estimate. Furthermore the use case points method has been applied to different types of projects. Thus, in Arnold and Pedross (1998) how to use in large-scale software systems is explained. Experiences, based on empirical data of a productivity benchmark of 23 measured projects, have revealed the usefulness of the method in order to measure the size of a software system. The method has also been applied in building Web Application Systems (Stoica, 2000) coming to the conclusion that this technique can be used by adding front-ends to the best existing cost models. Furthermore, some CASE tools solve the calculation of UCP . One of them is Enterprise Architect (Systems, 2003) a modelling UML tool. In our opinion, the most relevant thing of this approach is the consideration of the technical factors TCF and EF . More or less, this shows that it is insufficient in regards to the information collected in requirements specification to estimate effort because there are other factors whose influence is essential to take into account. Actor Type Description Factor Simple Program interface 1 Average Interactive, or protocoldriven interface 2 Complex Graphical interface 3 Table 1. Actor weighting factors Use case type Description Factor Simple 3 or fewer transactions 5 Average 4 to 7 transactions 10 Complex More than 7 transactions 15 Table 2. Transactionbased weights factors Use case type Description Factor Simple Fewer than 5 analysis classes 5 Average 5 to 10 analysis classes 10 Complex More than 10 analysis classes 15 Table 3.Analysis class-based weighting factors Factor number Factor description Weight T1 Distributed system 2 T2 Response or throughput perfomance objectives 1 T3 End-user efficiency(online) 1 T4 Complex internal processing 1 T5 Code must be reusable 1 T6 Easy to install 0.5 T7 Easy tu use 0.5 T8 Portable 2 T9 Easy to change 1 T10 Concurrent 1 T11 Includes special security features 1 T12 Provides direct access for third parties 1 T13 Special user training Facilities are required Table 4. Technical factors for system and weights 3.2.2 Smith’s proposal The approach described in this section presents a fundamental difference with the one described in the previous section; which is the detail level of the use cases object of the estimation. In the Karner’s proposal, it is necessary that use cases have sufficient detail level, in order to know how many analysis classes correspond to each use case. In brief, Smith (1999) defines four possible types of use cases according to detail level: Subsystem (L1), Group of subsystem (L2), System (L3) and System of subsystem (L4). A concrete use case can belong to a sole level, or to several of them in a concrete percentage. The concept of subsystem coincides with the concept proposed by UML (OMG, 2003). The concept of subsystem group coincides with CSCI7 (Computer Software Configuration Item) (DoD, 1993). 7 A configuration item for computer software, where a Configuration Item is an aggregation of hardware or software that satisfies an end use function and is designed by the acquirer for separate configuration management. The basic idea is that a use case of level L( i ) needs less effort than a level L( 1i ) to be implemented in C++ language. This is because a use case of level L( 1i ) comprises several use cases of level L( i ). On the other hand, the type of system also has influence in the effort of implementation of the use case. Thus, three types of systems are considered: simple business system, scientific system and complex command and control system. Table 5 shows the level size in SLOCS (Source Lines of Code). In order to build table 5, the following sentences are assumed, whose justification are in Smith (1999): A subsystem (L1) implements 8 classes. To implement a class in C++ approximately 850 SLOCS are necessary. The level L( 1i ) is composed by 8 components of the level L( i ). Level Size (SLOCS) L1 7,000 L2 56,000 L3 448,000 L4 3,584,000 Table 5. Size of system (in SLOCS) Once the level size is known it is necessary to take into account the following statements: to describe the functionality of 8 classes 300 scenarios are necessary. 10 use cases of level L1 can describe 300 scenarios. Now, if models like COCOMO and SLIM are applied, the results obtained in table 6 show the effort in hours/use case (h/UC) necessary to implement a use case of level and type of a system in particular. Level Effort h/UC simple business system Effort h/UC scientific system Effort h/UC complex command and control system L1 55 (range 40-75) 120 (range 90-160) 260 (range 190-350) L2 820 (range 710-950) 1,700 (range 1,5002,000) 3,300(range 2,900-3,900) L3 12,000 21,000 38,000 L4 148,000 252,000 432,000 Table 6. Effort of use case depending on detail level and system type In order to apply this estimation technique, we would have to take the set of use cases of the requirements specification and fit each of them in the suitable level L( i ) or partially in several of them. Furthermore, it is convenient to take into account the number of pages that fill each use case. Subjectively, Smith exposed that a use case of a simple business system must occupy an average length of 5 pages, a use case of a scientific system, 9 pages, and a complex command or control system, 12 pages. One example in Smith (1999) assumes a scientific system where the actual use cases count was 5, and one of them split at L4 and 4 at L3, further, the L4 use case is 12 pages and the L3 use cases average 10 pages, then the effort is: 28009102100049122501  staff months. The quotients 912 and 910 are used to account for the apparent complexity due to the 9 pages represented as the average length use case because the system is a scientific type. 3.2.3 Henderson-Sellers’s proposal Henderson-Sellers (2002) provides some metrics for size and complexity of use cases. According to the authors they could be useful for estimating external attributes (Fenton and Pfleeger, 1997), such as system effort and maintainability. In order to measure the size of a use case, the following metrics are suggested: Number of atomic actions in the main flow. Number of atomic actions in each alternative flow. The longest path between the first atomic action of the use case to the final atomic action of the use case. Number of alternative flows (alternative flows are measured from the start of the use case to its termination). On the other hand, the following environment factors contribute to the use cases complexity independently of size metrics shown above: Number of stakeholders. Number of actors. Total number of goals. The author argues that these metrics measure complexity in the presence of two use case models with similar values in defined size metrics, but different values in environment metrics, probably the one with greater values requires more effort in doing any change. This is because there are more elements that must be reviewed to solve possible conflicts. Other indirect metrics can be derived from the above metrics and include: Total number of atomic actions in the alternative flows. Total number of atomic actions in all flows. Number of atomic actions per actor. Number of atomic actions per goal. Number of goals per stakeholder. After showing different proposed metrics to measure use cases size and complexity, most of the authors coincide that the main factor that has influence in the use cases complexity is the increase of the resources required to do a change in the use case. The greater the effort required to do a change the greater the complexity of the specification will be. In these circumstances, also dependencies between requirements increase complexity. These dependencies appear in traceability matrix and in our point of view must be included as a factor to measure use cases complexity. 4 Metrics for Requirements Engineering Leaving aside the project estimation and focussing on requirements engineering process, there are reasons to think that it would be beneficial to define metrics. Nevertheless, because the requirements engineering is a recent discipline, there are not too many proposals. The reasons mentioned are as follows: In Kamstiems and Rombach (1997) the importance of early detection of requirements problems is recognized to improve the quality in the software development process. This is because the cost of repairing defects increases as the project moved forward (Boehm, 1975). In order to increase the control and monitoring during the development of this task, it is necessary to know in detail the requirements engineering process. The fact of control in the process allows knowing early needs for change. This has advantages because one of the main problems in the development process is changing requirements and specifications, as TSG (1995) shows. These changes affect technology, schedule, budget and staff organization as commented in Costello and Liu (1995) quoting the paper of Glaseman and Davis (1980). 4.1. Quality in requirements specification At the moment, there are not too many proposals, which specify how to predict quality requirements based on use cases. In spite of that, there are some proposals to evaluate quality of natural requirements. Generally, some of them can be applied to evaluate use cases quality. In this area, the following approaches exist: Manual verification of requirements: these approaches study aspects as stability, ambiguity or traceability of requirements. Some of them can be consulted in Davis et al. (1993), Costello and Liu (1995) or Hyatt and Rosemberg (1996). Automated verification of requirements: these proposals generally are based on NLP (Natural Language Processing). According to Fabbrini et al. (1998), the goal of NLP applied to requirements engineering is to know the vocabulary used, writing style, ambiguity (degree of syntactic and semantic uncertainty of the sentence), information conveyed by requirements, discovering underspecifications, missing information and unconnected statements. One of these proposals applied to use cases was collected in Fantechi et al. (2002). The idea of this proposal is to automatically identify defects in requirements specification. In order to achieve this goal, a tool CASE automatically identifies words in the text of use cases that denote lack of expressiveness (due to ambiguity or incompressibility), lack of consistency or incompleteness. On the other hand, some proposals to evaluate the design quality of use cases models have been done.For example, these metrics have been proposed: NumAss: The number of associations the use case participates in. ExtPts: The number of extension points of the use case. Including: The number of use cases which this one includes. Included: The number of use cases which include this one. Extended: The number of use cases which extend this one. Extending: The number of use cases which this one extends. Some of these metrics were automated by the tool SDMetrics (SDMetrics, 2003). 4.1.1. Saeki’s proposal The modifiability is one of the desiderable properties of the requirements specification. IEEE (1993) defines a modifiable requirements specification as one whose structure and style is so that any change can be performed in an easy, complete and consistent way maintaining its structure and style. In Saeki (2003) a set of metrics for use cases diagrams are defined. Based on these, the rate of modifiability can be calculated. The basic idea of the defined metrics is that if a use case needs a change, probably other use cases will also need a change: those that have a relationship with the originally changed use case. In short, include and extend relationships and the control8 and data9 dependency relationships are considered. The intuition suggests that, the more existing relationships in the model, the more difficult it will be to make any change. Another factor that has influence in the modifiability of use cases is the type of use case. Simplifying the idea, if a use case has several goals (types to Saeki), it is more susceptible of changing than if it only has one goal. In order to approximate the modifiability, the defined metrics are NOD (Number Of Dependencies) and NUCT (Number of Use Case Types). The next equation is the pattern that stands for extendsNO _ , usesNO _ , CDNO _ and DDNO _ metrics. These metrics express the modifiability index due to extend, include, control dependency and control data relationships, respectively. 8 Control dependency expresses the order of execution of use cases. 9 Data dependency expresses that one use case gives data to another. nciesAllDepende DependencynciesAllDepende NOD #  Where S# stands for the number of the elements of the set S , UseCase stands for the set of all use cases in the diagram, 2/))1(#(#  UseCaseUseCasenciesAllDepende is the set of all the possible dependencies that exist. In our opinion, term nciesAllDepende is a teorethical term since semantically it would not make sense that all use cases are connected between them in the model. On the other hand, the equation shown below expresses the modifiability index due to the fact that a use case covers more than one goal (types). )}},(|{{# 1 utuaggregateseUseCaseTyput NUCT AVE UseCaseu    Where UseCaseu  represents one of the use cases in the diagram, ),( utuaggregates means that a use case u has a type ut , )}({)( xsAVE xp means the average value of a set of numbers )(xs constructed from x such that )(xp . NUCT is the reciprocal number of an average of attached use case types for each use case. Based on these metrics the rate of modifiability ( ITYMODIFIABIL ) of the use cases diagram is computed as: NUCTwDDNOwCDNOwusesNOwextendsNOwITYMODIFIABIL  54321 ____ where each iw represents the weighting factor of the corresponding metric and the sum 5 4321 wwwww  may be equal to 1 and )5,...,1(10  iwi . One possible solution is proposed by Saeki: iwi 2,0 This manner of defining the metrics is not obvious but it is justifiable in our point out view. The goal achieved by the author was to find an indicator rate ( 10  ITYMODIFIABIL ) that would reveal the modifiability degree of a use cases model. This proposal is interesting because of its capability to measure one of the desiderable properties in requirements specifications, the modifiability. The traces existing between use cases should also be included in the calculation of modifiability because the traced requirements can change with the original requirements. In general, the coupling between use cases is caused by include and extend relationships and by the use cases connected in a traceability matrix which should be considered in the modifiability calculation. The control and data dependencies reveal that use cases technique has been used in an inferior specification level, close to the sequence diagram. 4.1.2. Bernárdez and Durán’s proposal Bernárdez et al. (2004) have empirically revised a set of heuristics to identify use cases that potentially can have defects. These heuristics, presented in Durán et al. (2002), are based on a set of use case metrics defined for the use cases model of REM (Durán, 2003). In this use cases model, a use case is seen as a sequence of steps that can be action-step, system-step or realize another use case as commented in section 2.3.4: Durán’s template. An example of a use case of this model can be seen in figure 3. The heuristics, based on the metrics shown in table 7, rely on a basic concept: there is a normal range of values for each metric m   21,mm , out of which the probability of a use case c presenting defects (   cPdef ) increases.         cPcPmmcm defdef  1, 21 Metric Description NOS Number of steps of the use case (NOS=NOAS+NOSS+NOUS) NOAS Number of actor action steps of the use case NOSS Number of system action steps of the use case NOUS Number of use case action steps of the use case (inclusion or extension) NOCS Number of conditional steps of the use case NOE Number of exceptions of the use case NIE Number of times the use case is included or extends other use cases NOAS/NOS Rate of actor action steps of the use case NOSS/NOS Rate of system action steps of the use case NOUS/NOS Rate of use case action steps of the use case CC Cyclomatic complexity of use case (NOCS+NOE+1) Table 7. Use case metrics which Durán’s heuristics are based In table 8, we will apply the outlined metrics to the use case example shown in figure 3. Metrics Value Explanation NOS 11 There are 11 steps in use case “Ordinary sequence” NOAS 6 There are 6 actor (librarian and library user) steps NOSS 4 There are 4 system steps NOUS 1 There is one include in step 9 NOCS 1 There is only a conditional step (step 9) NOE 1 There is only an exception associated to step 3 NIE 0 This use case is not performed during another use case execution (The “Description” of the use case not include other use cases) NOAS/NOS 0.54 6 divided by 11 NOSS/NOS 0.37 4 divided by 11 NOUS/NOS 0.09 1 divided by 11 CC 3 NOCS+NOE+1 (=1+1+1) Table 8. Use case metric values for the use case of figure 3 The normal range of values (see table 9) was set using data from 414 non-verified (i.e. containing defects) use cases from students of Computer Science at the University of Seville. Metrics Normal range NOS [3,9] NOAS/NOS [30%,70%] NOSS/NOS [40%,80%] NOUS/NOS [0%,25%] CC [1,4] Table 9. Use case metrics normal range In order to consolidate the intuition of these heuristics, Bernárdez et al. (2004) have verified 8 requirements specifications from their students, containing 127 use cases. Some of the results achieved reveal that use cases outside of the normal range are fault—prone requirements. This fact is confirmed in figure 6, which shows the percentage of use cases that have defects in and out of the normal range. Fetcke, T. A., Abran, A., and Nguyen, T. (1997). Mapping the OO–Jacobson Approach into Function Point Analysis. Proceedings of the 23th Technology of Object–Oriented Languages and Systems (TOOLS–23). Santa Barbara, California, pp. 1–11. Glaseman, S., and Davis, M. (1980). Software Requirements for Embedded Computers: A Preliminary Report. Document R-2567-AF. U. S. Air Force. Henderson-Sellers, B., Zowghi, D., Klemola, T. and Parasuram, S. (2002). Sizing use cases: How to create a standard metrical approach. Proceedings of the 8th Object–Oriented Information Systems 2002. Montpellier, France. Springer–Verlag, pp. 409–421. Hyatt, L., and Rosenberg, L. (1996). A Software Quality Model and Metrics for Identifiying Proyect Risk ans Assessing Software Quality. Proceedings of the 8th Software Technology Conference. Available in http://satc.gsfc.nasa.gov/support/STC_APR96/quality/sct_qual.html. IEEE (1993). IEEE Recommended Practice for Software Requirements Specifications (IEEE/ANSI Standard 830–1993). Institute of Electrical and Electronics Engineers. In, P., Kim, S., and Barry, M. (2003). Uml–based object–oriented metrics for architecture complexity analysis. Proceedings of Ground System Architectures Workshop. El Segundo, CA. Available in http://sunset.usc.edu/gsaw/gsaw2003/s8e/in.pdf. Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The unified software development process. Addison–Wesley. Jacobson, I., Christerson, M., Jonsson, P., and Övergaard, G. (1992). Object–oriented software engineering: A use case driven approach. Addison–Wesley. Kamsties, E., and Rombach, H. D. (1997). A Framework for Evaluating System and Software Requirements Specification Approaches. Proceedings of Requirements Targeting Software and Systems Engineering. Bernried, Germany, pp. 203–222. Kim, H., and Boldyreff, C. (2002). Developing Software Metrics Applicable to UML Models. Proceedings of the 6 th International Workshop on Quantitative Approaches in Object–Oriented Software Engineering. Málaga, Spain, pp. 67–76. Kruchten, P. (2000). The rational unified process: An introduction. Addison–Wesley. 2 nd edition. Kulak, D., and Guiney, E. (2000). Use cases: Requirements in context. Addison–Wesley. Leffingwell, D., and Widrig, D. (2000). Managing software requirements: A unified approach. Addison–Wesley. Leite, J. C. S. P., Hadad, H., Doorn, J., and Kaplan, G. (2000). A scenario construction process. Requirements Engineering Journal, Vol. 5 No. 1, pp. 38-61. Lilly, S. (1999). Use Case–Based Requirements: Review Checklist (Technical Report). SRA International, Inc. Marchesi, M. (1998). OOA Metrics for the Unified Modeling Language. Proceedings of the 2 nd EUROMICRO Conference on Software Manteinance and Reengineering, pp. 67–73. Meyer, B. (1997). Object–oriented software construction. Prentice–Hall. 2 nd edition. OMG (2003). OMG Unified Modeling Language Specification, v1.5. Regnell, B., Anderson, M., and Bergstrand, J. (1996). A hierarchical use case model with graphical representation. Proceedings of the IEEE International Symposium and Workshop on Engineering of Computer–Based Systems. Friedrichshafen, pp. 65–84. Plus, S. (2003). Use Case Toolkit for DOORS. Available in http://www.scenarioplus.org.uk. Saeki, M. (2003). Embedding Metrics into Information System Development Methods: An Application of Method Engineering Technique. Lecture Notes in Computer Science, Vol. 2681, pp. 374–389. Schneider, G., and Winters, J. P. (1998). Applying use cases: a practical guide. Addison– Wesley. SDMetrics (2003). SDMetrics: The Software Design Metrics tool for the UML. Available in http://www.sdmetrics.com/. Smith, J. (1999). The Estimation of Effort based on Use Cases (Rational Software white paper). Rational Software. Available in http://www.rational.com/media/whitepapers/finalTP171.PDF. Software Solutions on Time (2001). A fresh and innovative approach to systems development and software project management. Available in http://www.tasscsolutions.com/omx/pages/metric_data.htm#usecase-metrics. Sommerville, I., and Sawyer, P. (1997). Requirements engineering: A good practice guide. Wiley. Stoica, A. (2000). Aspect of Building Web Application Systems Using the MBASE Approach. Proceedings of the 15th International Forum on SCM/Focused Workshop. USC– CSE. Systems, S. (2003). Enterprise Architect: UML modeling and design tool. Available in http://www.sparxsystems.com.au. TSG (1995). The CHAOS Report. The Standish Group. Available in http://www.standishgroup.com/chaos.html. Weidenhaput, K., Pohl, K., Jarke, M., and Haumer, P. (1998). Scenarios in system development: Current practice. IEEE Software, Vol. 15 No. 2 , pp. 34–45. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2000). Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers. View publication statsView publication stats