Software Requirement Engineering Through Use Case
Software Requirement Engineering through Use case Mrs Mirza Zainab, Lecturer in IT Dept, M. H. S. S. COE, Byculla, India Mirza_zainab@yahoo. com ABSTRACT By now, it is well known that shortcomings in requirements definition and management lead to excessive rework on software projects and products that fail to achieve full customer satisfaction.
In systems engineering and software engineering, requirements analysis encompasses all of the tasks that go into the investigation, scoping and definition of a new or altered system.
Requirements analysis is an important part of the system design process, whereby requirements engineers and usiness analysts, along with systems engineers or software developers, identify the needs or requirements of a client. Once the client’s requirements have been identified, the system designers are then in a position to design a solution. Software requirements engineering is a communication-intensive activity, at a minimum involving analysts, developers, business stakeholders and end users.
The paper describes how use cases can be used effectively to model requirement of system and how it can be used as a means of communication between analyst and end users.
KEYWORDS Software requirement engineering, use cases, actor, include, extend INTRODUCTION Software development involves perhaps 50 percent computing and 50 percent communication. Unfortunately, most teams are better at the computing part, and requirements are almost entirely about communication.
There are many links in the requirements communication chain, like end user, sales representative, marketing, product manager, developer, and tester. A breakdown in any of these links leads to significant problems. The inevitable outcome of requirements errors is time consuming and costly rework. Analysts report that rework can consume 30 to 40 percent of the total effort expended on a software project.
Multiple studies have indicated that roughly 50 percent of the defects identified on software projects can be traced back to errors in the requirements.
One analysis of the potential return on investment from better requirements suggests that requirements errors can consume between 70 and 85 percent of all project rework costs [1]. The first step in finding an appropriate solution to given problem is to understand the problem and its domain ie detailed problem and domain analysis . Without analysis there is a real danger ot designing and implanting system that do not meet the user’s n eeds, simply because the users needs were not adequately identified and defined Figure 1.
Relative cost to correct a requirement defect depending on when it is discovered Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved.
New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer.
Analysis requires a great deal of interaction with the people who will be affected by the system, including the actual users and anyone else on whom its creation will have an impact For extracting information about the system , analyst can use four tools that is interview, Questionnaire ,observation and examination of existing system documents [2 USE CASES AND ACTORS As we think further about the way in which the system needs to do its Job for the user, we might find it beneficial to employ the Use case technique for further escribing system behavior.
This technique has been well developed in a number of books [Jacobson 1992] and is also an integral technique in the industry-standard Unified Modeling Language (UML) [Booch 1999]. Technically, a use case describes a sequence of actions, performed by a system that yields a result of value to the user.
In other words, the use case describes a series of user and system interactions that help users accomplish something they wanted to accomplish. Stated differently, the use case describes HOW users and the system work together to realize the identified eature.
Use cases also introduce the construct of an actor, which is simply a label for someone who is using the system at a given time. In IJML, a use case is represented by a simple oval; an actor is represented by a stick figure with a name. So we can illustrate both with a simple diagram like the one below. Actors are basically users of the system.
They are actually user types or categories. Actors are external entities (people or other systems) who interact with the system to achieve a desired goal. Use Cases are what happens when actors interact with the system.
An actor uses the system to achieve a desired goal. By recording all the ways our system is used (“cases of use” or Use Cases) we accumulate all the goals or requirements of our system. Therefore a use case is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors), relating to a particular goal.
The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly. Any system behavior that is irrelevant to the actors should not be included in the use cases.
Actors can be a primary . The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal ot the primary actor. Secondary actors are those actors that the system needs assistance from to achieve the primary actors goal.
A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system’s declared responsibilities, showing how the primary actor’s goal might be delivered or might fail. Use cases are goals that are made up of scenarios.
Scenarios consist of a sequence of steps to achieve the goal; each step in a scenario is a sub (or mint) goal of the use case. As such each sub goal represents either another use case(subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition. This hierarchical relationship is needed to properly model the requirements of a system being developed.
A complete use case analysis requires several levels. In addition the level at which the use case is operating at it is important to understand the scope it is addressing.
The level and cope are important to assure that the language and granularity of scenario steps remain consistent within the use case. ELABORATING THE USE CASES In many systems, it’s helpful to organize the specification activity by refining the use cases defined earlier and developing additional use cases to fully elaborate the system. Using this technique, we refine the steps of the use case into more and more detailed system interactions. We’ll also need to define pre-conditions and post- conditions (states the system assumes before and after the use case), alternative actions due to exception conditions, and so on.
Since use cases are semantically well defined, they provide a structure into which we can organize and capture the system behavior. Use cases treat the system as a “Black Box” and the interactions with the system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements and avoids the trap of making assumptions about how this functionality will be accomplished. Here is an elaboration of validate user use case in a text clearly enough for outsider to understand it easily.
Use case name : Validate ATM user Actor Bank Client Brief Description: This use case is to validate card holder before allowing him to perform any transaction.
Main flow of Events: The use case starts when the system prompts the client for a PIN number. The client can now enter a PIN number via the keypad. The client commits the entry by pressing the Enter button. The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case. Exceptional flow of event : If the client enters an invalid PIN number, the use case restarts.
If this happens three times the system cancels the entire transaction, and ard will be retained by system . Exceptional flow of event:: The client can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the client’s account. t condition The bank DB gets updated, and transaction gets recorded USES AND EXTEND RELATIONSHIP IN USE CASE An include relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base.
The included use case never stands alone, but is only instantiated as part of some larger base that includes it.
You can think of include as the base use case pulling behavior from the supplier use case. You use an include relationship to avoid describing the same flow of events several times, by putting the common behavior in a use case of its own (the use case that is included by a base use case). The include relationship is essentially an example of delegation.
You take a set of responsibilities of the system and capture it in one place (the included use case), then let all other parts of the system (other use cases) include the new aggregation of responsibilities whenever they need to use that functionality. Figure: include relationship Use the extends relationship when you have a use case that is similar to another use case but does a bit more. Extensions are used instead of modeling every extra case by a single use case and creating a complex use case that covers all variations.
Extensions mean the use case is more specialized like subclass.
To capture the extended use case first capture the simple normal use case and then ask a question ” what could go wrong here ? ” and plot all variation as extension of a given use case . lt is quit possible to get fairly high number of variation of a given use case . Listing the extensions separately makes things easier to understand. The similarities between extends and uses are that they both imply factoring out common behavior from several use cases to a single use case that is used by several other use cases or extended by other use cases.
From the actor’s viewpoint extends means, both the normal use case and the extension are performed by the actor, uses means, there is often no actor associated with the common use case.
Figure: Extend relationship CONCLUSION The main objective of software requirement gathering is to capture a complete, nambiguous and consistent picture of the requirement of the system and what the system must do to satisfy the user requirement and needs Use cases are very effective requirement gathering tools.
Its a very effective communication tool between analyst and users of the system. It can capture the complete requirement of the system . A use case contains a textual description of all the ways which the intended users could work with the software through its interface. Use case do not describe any internal working of the software nor do they explain how that software
