|
|
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 them?
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 by whom that outcome is expected. For example, one goal of the SRS is to "enable a student user to register for a course," and thus we've just expressed our first use case! (Yes, use cases really are that straightforward. In fact, we need for them to be that straightforward, so that they are understandable by the users/sponsors of the system, as we'll discuss further in a moment.)
The purpose of thinking through all of the use cases for a system is to explore the system's functional requirements thoroughly, so as to make sure that a particular category of user, or potential purpose for the system, isn't overlooked. We differentiate between functional requirements and technical requirements as follows.
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: These provide a statement of a system's purpose without regard to how the requirement will "play out" from the user's vantage point—e.g., "The system must be able to produce tailorable reports." Avoid discussing implementation details when specifying goal-oriented requirements.
"Look and feel" requirements: These requirements get a bit more specific in terms of what the user expects the system to look like externally (e.g., how the graphical user interface will be presented), and how he or she expects it to behave, again from the user's perspective. For example, we might have as a requirement "The user will click a button on the main GUI, and a confirmation message will appear… ." A good practice is to write a concept of operations document to serve as a "paper prototype" describing how you envision the future system will look and behave, to stimulate discussion with intended users of the as-yet-to-be-built system before you even begin modeling.
| Note?/td> |
We present a sample concept of operations for the SRS application in Chapter 16. |
We emphasize goal-oriented functional requirements when preparing use cases.
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… ." One can think of these as 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. Technical requirements such as these don't play a role in use case analysis.
Although it's certainly conceivable that the users of our system may be technically sophisticated, it's best to express functional requirements in such a way that even a user who knows nothing about the inner workings of a computer will understand them. This helps to ensure that technical requirements don't "creep into" the functional requirements statement, a common mistake made by many inexperienced software developers. When we allow technical requirements to color the functional requirements, they artificially constrain the solution to a problem too early in the development life cycle.
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. If the intended users haven't (as individuals) been specifically defined or recruited, as with a software product that is to be sold commercially, their anticipated needs nonetheless need to be taken into account by identifying people with comparable experience to serve as "user surrogates." Ideally, the users or user surrogates will write some or all of the use cases themselves; at a minimum, you'll interview such people, write the use cases on their behalf, and then get their confirmation that what you've written is indeed accurate.
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.
They turn out to be quite useful as a basis for writing testing scripts, to ensure that all functional threads are exercised during system and user acceptance testing.
They 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. (Of course, a requirements traceability matrix must take into account all of the requirements for a system—functional as well as technical—of which use cases represent only a subset.)
Returning to the questions that we posed at the outset of this section, let's answer the first question—namely, "Who will want to use our system?"—which in use case nomenclature is known as identifying actors.
|
|