Formalizing Requirements Through Use Cases Objectives youll learn

Formalizing Requirements Through Use Cases

Objectives you’ll learn • How we must anticipate all of the different roles that users will play when interacting with our future system • That we must assume each of the users’ viewpoints in describing the services that a software application as a whole is to provide • How to prepare use cases as a means of documenting all of the preceding requirements

What Are Use Cases? • In determining what the desired functionality of a system is to be, we must seek answers to the following questions: • Who will want to use our system? • What services will the system need to provide in order to be of value to the users? • When users interact with the system for a particular purpose, what is their expectation as to the desired outcome? • Use cases are a natural way to express the answers to these questions • Each use case is a simple statement, narrative or graphical in fashion, that describes a particular goal or outcome of the system, and who expects that outcome.

Functional vs Technical Requirements • Functional requirements are those aspects of a system that have to do with how it is to operate or function from the perspective of someone using the system. Functional requirements may in turn be subdivided into • “Goal-oriented” functional requirements: • “Look and feel” requirements: • Technical requirements, on the other hand, have more to do with how a system is to be built internally in order to meet the functional requirements; for instance, “The system will use the TCP/IP protocol. . . ” or “We will use a dictionary collection as the means for tracking students. . . ”. • Technical requirements for how programmers should tackle the solution, in contrast to functional requirements, which are a statement of what the problem to be tackled actually is.

Involving the Users • Because the intended users of a system are the ultimate experts in what they need the system to do, it’s essential that they be involved in the use case definition process. • Use cases are one of the first deliverables/artifacts to emerge in a software development project’s life cycle, but also one of the last things to be put to good use in making sure that the system is a success. • Use cases also lend themselves to the preparation of a requirements traceability matrix—that is, a final checklist against which the users can verify that all of their initial requirements have indeed been met when the system is delivered.

Actors • Actors represent anybody or anything that will interact with the system after it’s built; actors drive use cases. Actors generally fall into two broad categories: • Human users • Other computer systems • By providing information, we mean whether or not the actor inputs substantive information that adds to the collective data stored by the system • By consuming information, we mean whether or not the actor uses the system to obtain information

Identifying Actors and Determining Their Roles • We must create an actor for every different role that will be assumed by various categories of user relative to the system. • To identify such roles, we typically turn first to the narrative requirements specification, if one exists—that is, a statement of the functional requirements • Who would use our SRS?

Diagramming a System and Its Actors • Once we’ve settled on the actors for our system, we may wish to optionally diagram them. UML notation calls for representing all actors—whether a human user or a computer system—as stick figures, and then connecting these via straight lines to a rectangle representing the system,

Specifying Use Cases • Having made a first cut at what the SRS actors are, we’ll next enumerate in what ways the system will be used by these actors—in other words, the use cases themselves. • A use case represents a logical thread, or a series of cause-and-effect events, beginning with an actor’s first contact with the system and ending with the achievement of that actor’s goal for using the system in the first place. • Use cases emphasize “what” the system is to do—functional requirements—without concern for “how” such things will be accomplished internally;

Specifying Use Cases Some example high-level use cases for the SRS might be • Register for a Course • Drop a Course • Determine a Student’s Course Load • Choose a Faculty Advisor • Establish a Plan of Study • View the Schedule of Classes • Request a Student Roster for a Given Course • Request a Transcript for a Given Student • Maintain Course Information (e. g. , change the course description, reflect a different instructor for the course, and so on) • Determine a Student’s Eligibility for Graduation • Post Final Semester Grades for a Given Course

Specifying Use Cases • We may decompose any one of the use cases into steps, with each step representing a more detailed use case. For example, “Register for a Course” may be decomposed into these steps: 1. Verify that a student has met the prerequisites. 2. Check student’s plan of study to ensure that this course is required. 3. Check for availability of a seat in the course. 4. (Optionally) Place student on a wait list.

Matching Up Use Cases with Actors • Another important step is to match up use cases with actors. • The relationship between actors and use cases is potentially many-tomany, in that the same actor may initiate many different use cases, and a single use case may be relevant to many different actors. • By cross-referencing actors with use cases, we ensure that • We didn’t identify an actor who, in the final analysis, really has no use for the system after all. • Conversely, that we didn’t specify a use case that nobody really cares about.

Matching Up Use Cases with Actors

To Diagram or Not to Diagram? • The use case concept is fairly straightforward, and hence simple narrative text is often sufficient for expressing use cases. • UML does, however, provide a formal means for diagramming use cases and their interactions with actors. • Actors (whether people or systems) are represented as stick figures; • use cases are represented as ovals labeled underneath with a brief phrase describing the use case; and • the box surrounding the oval(s) represents the system boundaries

To Diagram or Not to Diagram?