| Toward the end of Inception, as well as occasionally during later phases, it's wise to spend some time updating your use-case model and glossary. - Step 9. In parallel with writing the detailed use-case descriptions, update the glossary or domain model. A good glossary will save you a lot of grief later in the project and will accelerate the writing of use cases. While writing use-case descriptions, did you run across any important concepts that need to be added to your glossary? Are your use cases referencing the correct glossary items/domain objects, or are concepts already defined reinvented?
Course Registration System: Use-Case Specification for Register for Courses -
Brief Description This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester. The main actor of this use case is the Student. The Course Catalog System is an actor within the use case. -
Flow of Events The use case begins when the Student selects to Register for Courses. 2.1 Basic Flow: Register for Courses -
The Student selects to Register for Courses. -
The system displays a blank schedule. -
The system retrieves a list of available course offerings from the Course Catalog System. -
The Student selects one or more primary and alternate course offerings from the list of available offerings. The user can at any time add or remove courses from the list of selected courses. Once the selections are complete the Student submits the schedule. -
For each selected course offering, the system verifies that the Student has the necessary prerequisites and that the course offering is open . -
If the Student has the necessary prerequisites, and the course offering is not full, the system adds the Student to the selected course offering. The course offering is marked as "enrolled in" in the schedule. -
If the Student does not have the necessary prerequisites, or if the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted. -
The system saves the schedule. 2.2 Alternative Flows 2.2.1 Modify Course Registration -
The Student selects to modify the current course registration schedule. -
The system retrieves and displays the Student's current schedule (the schedule for the current semester). -
The system retrieves a list of all the course offerings available for the current semester from the Course Catalog System. The system displays the list to the Student. -
The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student submits the schedule to indicate completion with the selection of courses. -
Subflow 2.1.5 is performed for each selected course offering. -
The system saves the schedule. 2.2.2 Delete Course Registration -
The Student selects to delete a schedule. -
The system retrieves and displays the Student's current schedule. -
The Student selects to delete the schedule. -
The system prompts the Student to verify the deletion. -
The Student verifies the deletion. -
The system deletes the schedule. 2.2.3 Save a Schedule At any point, the Student may choose to save a schedule without submitting it. The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as "selected" in the schedule. | Another thing to consider when you are working with the glossary/domain model is to revisit step 6. Go through the lifecycle of any new concepts defined, and make sure that you have use cases that describe how to create, maintain, and delete that concept.
- Step 10. You can structure your use-case model by creating relationships between actors and use cases, such as inheritance between actors, or includes, extends, or generalizations between use cases. The first thing we recommend is to use these constructs only if you are an expert use-case modeler. We see these constructs misused more often than not, and you can build perfectly fine systems without using them.
If you are interested in using these, we recommend you to wait until Elaboration, or at least until very late in Inception. We also recommend you not use a relationship except when you can make a convincing case for it. When in doubt, go for simplicity.
As you restructure your use-case model, you will need to revisit the use-case description for each use case involved.
Develop User-Interface Prototypes Analysts either develop user-interface prototypes or work closely with the people who develop them. The development of UI prototypes can be divided into two main groups: conceptual prototypes and use-case storyboards or prototypes. -
Conceptual Prototype. During Inception, in parallel with developing the vision, describing the most essential use cases, and producing a business case for the system, you need to develop a conceptual prototype to visualize and demonstrate key concepts and capabilities to enable stakeholders to understand better the system being built. Often, a conceptual prototype contains not only UI prototypes, but also some underlying functionality. The prototype should answer questions such as, "Are you proposing a new user paradigm?", "What capabilities will the application offer?", "To what user types will the application appeal ?", and "What is the potential functionality offered by the most critical use cases?" Answers, or potential answers, to all of these questions facilitate the big decision you make at the end of Inception: Should you develop the envisioned product? -
Use-Case Storyboard or Use-Case Prototype. In late Inception, throughout Elaboration, and into early Construction, you want to develop UI prototypes in parallel with use-case descriptions to enhance your understanding of the use cases. How much time you spend on this differs greatly depending on the application. Develop Use-Case Storyboard or Prototype For more technical applications with a strong focus on sequencing and interaction with other systems, you would create a use-case storyboard only for some key use cases to showcase a few different screens. For database-focused applications of the Create, Read, Update, Delete (CRUD) nature, you should try to do a UI prototype for each use case, not so much to mitigate risks associated with the UI, but to increase the speed and accuracy in developing use-case descriptions (see step 8). The following procedure has been used successfully to accelerate the development of use cases, while increasing the value of the use-case description feedback provided by users and customers: -
Have one person (the UI designer) responsible for UI prototypes to ensure consistency across use cases. For large projects with more than five to eight analysts, you may need more than one UI designer. -
When an analyst has produced a first draft of the use-case description, review it with the UI designer. Together sketch out what information needs to be displayed and what screens will be needed. Later, the UI designer may merge or split screens based on available space, so do not focus too much on details at this point. Doing this walkthrough allows the analyst to get valuable and early feedback on the use case. You will likely discover inconsistencies in information managed by the use cases, as well as in the flow of events. -
The UI designer creates a mock-up of the screens. This can be done rapidly using the GUI Builder of the IDE you are using, providing developers with a great starting point when designing, implementing, and testing the use case. Do not add any logic behind the screens; just print the screens for later review. In parallel, the analyst details the use-case description. -
The UI designer and analyst review the screen shots and use them to walk through the use case. Corrections are made to screen shots and to use-case descriptions as holes or discrepancies are identified. -
The analyst meets with the users and/or customers to walk through the use case. The review is done as a storyboard, where the screen shots are used to clarify the flow of events. It is often beneficial to leave the material on-site for a day or two after the meeting so it can be reviewed in detail. -
Update use cases and screen shots based on feedback. This approach normally provides many of the following benefits: -
Increased consistency in the UI -
Accelerated completion of use-case descriptions -
Improved feedback from users -
Accelerated design, implementation, and testing of use cases -
Enhanced communication between analysts and developers It should be noted that there is also a clear risk that users, UI designers, and analysts seek to perfect the UI prototypes, which could lead to analysis-paralysis. Your goal is not to finalize the UI ; your goal is to get a reasonably good UI to facilitate effective communication with the users on what the system should do, allowing you to finalize the use cases more rapidly. Note that projects with a very strong focus on user experience may choose to formally model the user interface using UML models. This is done by representing screens with stereotyped analysis classes, allowing you to show the interaction between the users (actors) and the screens through UML diagrams such as sequence diagrams. This is described in more detail in The User-Experience Modeling Plug-In for the RUP , available through the Rational Developer Network, as well as in Conallen 2000. Capture Nonfunctional Requirements Nonfunctional requirements typically have a significant impact on the architecture and on user satisfaction. These requirements may, however, not always be as clearly articulated by users and stakeholders as are the functional requirements. This means that the analyst needs to identify, document, and confirm the nonfunctional requirements, such as: -
Quality attributes, including usability, reliability, performance, and supportability requirements. -
Legal and regulatory requirements, and application standards. -
Other requirements, such as operating systems and environments, compatibility requirements, and design constraints. Nonfunctional requirements are captured primarily during Inception and early Elaboration, but they may be revised throughout the project. They are documented in the RUP artifact called the Supplementary Specification. It should be noted that a major objective in the Elaboration phase is to verify that you can sufficiently support many of the nonfunctional requirements such as usability, reliability, performance, operating systems, environments, and compatibility with other systems. |
