Step 1 - Requirement modeling with use case
16 June 2009, HUT - Nguyen Thi Thu Trang
I.
Main activities
The goal of this step is to find actor and use case then construct use case diagram. Finally, we make use
case specification.
1. Extraction of Actor
2. Extraction of Use Case (UC)
3. UC diagram Contruction
4. UC Specification
II.
User needs
First, we gather user needs and get the following brief description:
The system manages course registration in university. It manages course information for semesters of past
one year and next semester. Course registration can be done for only next semester. Course information
for past one year is only for viewing.
Course managers, lecturers and students use the system. Course managers manage course information
through course manager GUI. Course managers add, delete and update basic information of courses for
preparing course information of the next semester. When adding/updating a new course, course managers
assign lecturers for it.
Lecturers make input and update course information of corresponding assigned course through lecturer GUI.
After completion of preparation for all course information of the next semester, course managers open
course information to students. After that, students can register for course. At the end of course
registration period, course managers close course registration. After closing course registration, student
cannot register nor cancel registration.
Students make registration for courses through student GUI. Students retrieve course list for the next
semester. Students can view detailed course information when clicking each course in the list. Students
register for the course from detailed course information GUI. Students can view the list of own registration
courses. Students can cancel course registration from registration list GUI.
Course managers and lecturers can view lists of students who registered for courses after registration
period. Course managers can view all lists. Lecturers can view only lists for corresponding assigned courses.
Course managers, lecturers, students can view course list for all semesters and search course information
using keyword.
III.
Requirement analysis
We do the requirement analysis using UC. There are some basic concepts and some guidelines for this
process.
A.
Extraction of Actors
An actor represents a coherent set of roles that users of the system play when interacting with
these use cases. Typically, an actor represents a human, a hardware device, or some other
external system. In UML 2, actors should be named whenever possible.
1
Some guidelines when extracting actors:



Pay attention to a noun in the problem description, then extract a subject of action as a Actor.
Ensure that there are no any excesses and deficiencies between the problem description and
Actors extracted.
Actor names
o should clearly convey the actor’s role
o good actor names describe their responsibilities
Put some questions to find actors:






Who or what uses the system?
Who or what gets information from this system?
Who or what provides information to the system?
Where in the company is the system used?
Who or what supports and maintains the system?
What other systems use this system?
An actor can be a human, a hardware device or a external system. In the Course Registration Case study,
may be this system will interact with other system but for simplicity, we only concentrate on human.
Therefore, we have 3 actors: Student, Lecturer and Course Manager.
B.
Extraction of Use case
A use case is a sequence of actions a system performs to yield an observable result that is of value to a
particular actor. A use case describes what a system does, but it does not specify how
it does it. Whenever space permits, put the name of the use case inside the icon.
Some guidelines when extracting use cases:





Pay attention to a verb in the problem description, then extract a series of Actions as a UC.
Ensure that there are no any excesses and deficiencies between the problem description and Use
cases extracted.
Check the consistency between Use Cases and related Actors.
Conduct a survey to learn whether customers, business representatives, analysts, and developers
all understand the names and descriptions of the use cases
A use case name should:
 Be unique, intuitive, and self-explanatory
 Define clearly and unambiguously the observable result of value gained from the use case
 Be from the perspective of the actor that triggers the use case
 Describe the behavior that the use case supports
 Start with a verb and use a simple verb-noun combination
Put some questions to find use cases:





What are the goals of each actor?
Why does the actor want to use the system?
Will the actor create, store, change, remove, or read data in the system? If so, why?
Will the actor need to inform the system about external events or changes?
Will the actor need to be informed about certain occurrences in the system?
2
C.
UC diagram Contruction
A Use-Case Diagram describes a system’s functional requirements in terms of use cases. It is a model of the
system's intended functionality and its environment. The Use-Case Diagram serves as a contract between
the customer and the developers. Because it is a very powerful planning instrument, the Use-Case Diagram
is generally used in all phases of the development cycle.








When the customer approves the Use-Case Diagram, it’s a mutual understanding with the
development team of what the customer wants. You can use the model to discuss the system with
the customer during development.
Potential users use the Use-Case Diagram to better understand the system.
Designers use it as a basis for their work and to get a system overview.
Testers use it to plan testing activities (use case and integration testing) as early as possible.
Those developing the next version of the system use it to understand how the existing version
works.
Documentation writers use the use cases as a basis for writing the system user guides.
The architect uses the Use-Case Diagram to identify architecturally significant functionality.
The manager uses it to plan and follow up on use-case modeling and subsequent design.
Some remain issues:



The above use case diagram has so many use cases and it is difficult to view the
relationship between actor and use cases.
What are system requirements? For example, manage users...
Can we go to next step with only a use case diagram? What is the input/output and
condition for Register for course?
3
 Solutions:
- Use relationships in UC diagram but not recommended to use many times:
o Between actors: generalization, association
o Between actor and use cases: association
o Between use cases: generalization, include, extend
- Group some related use cases to a use case then make a use case diagram level-2 for this
merged use case.
- Ask your customer to add more requirement to the description
- Make the Use case more detail with UC specification/scenario.
D.
Use case Specification/Scenario
The use case has a set of properties as shown in the graphic. The use-case properties may be documented
in use-case specifications, which can include the items listed below:










Use case Code: Numbering UC to manage easier
Brief description describes the role and purpose of the use case
Flow of events is textual descriptions of what the system does with regard to the use case. There
can be multiple flows of events — for example, a basic flow and alternative flows.
Relationships are associations. The use case can include and extend relationships that the use case
participates in.
Activity diagrams can be used to illustrate the structure of the flow of events.
Use-case diagrams can be used to show the relationships involving the use case.
Special requirements is a textual description that collects all use-case requirements, like
nonfunctional requirements, that are not considered in the Use-Case Model, yet need to be taken
care of during design or implementation.
Pre-conditions define a constraint on the system regarding when the use case may start.
Post-conditions define a constraint on the system that applies after the use case has terminated.
Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures
from a user-interface prototype.
4
Some guidelines to make UC specification:




UC Scenario description for each UC: External Interface, Permanent data are identified.
Excess and deficiency check between between the problem description and Requirements
Consistency in the Requirements
Feasibility of later phase
This is a simple specification for “Add course” Use case:
UC Code (UC #)
UC001
Actor
Course manager
Pre-condition
Course registration mustnot be opened
Main Success Scenario
(Flow of event)
No.
1.
2.
3.
4.
5.
6.
UC Name
Doer
Add course
Action
Course manager
goes to Add course
System
loads the initial data
Course manager
enters course information (lack in the description)
Course manager
submits to add course
System
checks if there is any blank mandatory field (which are the
mandatory fields? – not specified in the description)
System
notifies successful course addition (any other validations? – not
specified in the description)
Extension Scenarios
(Alternative flows)
No.
6a.
Doer
System
Action
notifies error: Lack of mandatory fields
Some remain issues:



Some red marks in the “Add course” specification
More information for other use case: What is the condition for student to register a
course successfully? …
Other constraints such as Performance, Usability…
 Solution:
- Ask your customer to get the detail description for the system then refine the use case diagram
and use case specification
IV.
New user requirement and new requirement analysis results
This is the new user requirement after gathering more detail information about the Course Registration.
The blue and italic paragraphs are added.
The system manages course registration in university. It manages course information for semesters of past
one year and next semester. Course registration can be done for only next semester. Course information
for past one year is only for viewing.
Users have to login to use the system via Internet. After completing their work, they can log out the system
because of security. Admistrators can manage users in the system including search, add, delete and update
users.
Course managers manage course information through course manager GUI. Course managers add, delete,
and update basic information of courses for preparing course information of the next semester.
5
Information about each course, such as course ID* (must be unique and entered by course manager with the
pattern XX9999, where XX is department, 9999 is 4 digits), course title*, start date, end date, description,
goal, lecturer and prerequisies will be included to help students make informed decisions.
Lecturers make input and update course information of corresponding assigned course through lecturer GUI.
After completion of preparation for all course information of the next semester, course managers open
course information to students for registration. After that, students can register for courses. At the end of
course registration period, course managers close course registration. After closing course registration,
students cannot register nor cancel registration.
Students make registration for courses through student GUI. Students retrieve course list for the next
semester and register for the course after choosing it. Students can view the list of own registration
courses. Students can cancel course registration from registration list GUI.
The registration for a course of next semester by a student allows the student to study the course. A course
will have a maximum of 30 students and minimum 3 students. Student cannot register for course which has
already maximum registrations or the same time with registered courses of the student. If the student
satisfies the prerequisites, the registration during the specified period can be accepted. A course with fewer
than 3 students will be canceled. If a course is canceled, system must notify students who registered the
course about this cancellation.
Course managers and lecturers can view lists of students who registered for courses after registration
period. Course managers can view all lists. Lecturers can view only lists for corresponding assigned courses.
Users can search course information using keyword. Users can view detail information of each course after
choosing it.
Multiple users must be able to perform their work concurrently. The system shall support up to 500 users to
operate simultaneously “Course Registration” operation and all users can receive the result of the operation
within 10 seconds.
There may be some freshman students using the system who do not have any experience in Web application
including Course Registration System. There should be some help documents or video for users.
The system shall be available 24 hours a day, 7 days a week, with no more than 10% down time.
With new requirements, the specification for “Add course” use case is modified as the
following:
UC Code (UC #)
UC001
Actor
Course manager
Pre-condition
Course registration mustnot be opened
Main Success Scenario
(Flow of event)
No.
1.
2.
3.
4.
5.
6.
7.
UC Name
Doer
Add course
Action
Course manager
goes to Add course
System
loads the initial data
Course manager
enters course information (described below)
Course manager
submits to add course
System
checks if there is any blank mandatory field.
System
checks if Start Date and End Date is valid and if
End Date is greater than Start Date
System
checks if the Course ID already exists
6
8.
Extension Scenarios
(Alternative flows)
No.
System
notifies successful course addition
Doer
Action
6a.
System
notifies error: Lack of mandatory fields
7a.
System
notifies error: Invalid Start Date and/or End Date
8a.
System
notifies error: Course ID already exists
Input Data for course information:
No
1.
Data item
Course ID
Mandatory
Yes
Course Title
Description
Course identifier, which should be entered by the
course manager with XX9999 where XX is department,
9999 is 4 digits.
Title of the course
2.
3.
Lecturer
Choose from a list of lecturers
No
4.
Start Date
No
5.
End Date
No
6.
Description
No
7.
Goal
8.
Prerequisites
V.
Condition
Unique
Yes
Valid date, Must be less
than End Date
Valid date, Must be
greater than Start Date
No
Choose some prerequisite courses for the new course
No
Homework
Based on the new requirement, please refine the use case diagram and write the specification for “Register
for course” use case.
7