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. Note that an actor always initiates a use case; actions initiated by a system on its own behalf don't warrant the development of a use case (although they do warrant expression as either a functional or technical requirement, as defined earlier in the chapter).
Use cases emphasize "what" the system is to do—functional requirements— without concern for "how" such things will be accomplished internally, and aren't unlike method signatures in this regard. In fact, you can think of a use case as a "behavioral signature" for the system as a whole.
Some example high-level use cases for the Student Registration System 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.
Determine a student's eligibility for graduation.
Post final semester grades for a given course.
Remember that a use case is initiated by an actor, which is why we didn't list other functionality called out by the SRS requirements specification, such as "Notify student by email," as use cases.
We may decompose any one of the use cases into steps, each step representing a more detailed use case; for example, "Register for a course …" may be decomposed into these steps:
Verify that a student has met the prerequisites.
Check student's plan of study to ensure that this course is required.
Check for availability of a seat in the course.
(Optionally) Place student on a wait list.
and so forth. Use cases may be interrelated in parent-child fashion, with more detailed use cases being shared by more than one general use case; for example, the "Request a student roster …" and "Post final semester grades …" general use cases may both involve the more detailed "Verify that professor is teaching the course in question" use case.
Unfortunately, as is true of all requirements analysis, there is no magical formula to apply in order to determine whether or not you've identified all of the important use cases or all of the actors, and/or whether you've gone into sufficient depth in terms of sub use cases. The process of use case development is iterative; when subsequent iterations fail to yield substantial changes, you're probably finished! Copious interviews and reviews with users, along with periodic team walkthroughs of the use case set as a whole, go a long way in ensuring that nothing important has been missed.