CS 501: Software Engineering
Lecture 8
Requirements II
1
CS 501 Spring 2005
Administration
Quiz 1
Collect after class or from reception at 301 College
Avenue
Assignment 1: Feasibility study
Due Friday at 5:00 p.m.
Remember to submit your questionnaires
Remember to send a copy to your client
2
CS 501 Spring 2005
Diagrams and Specification in UML
A diagram is the graphical representation of a set of
elements, usually rendered as a connected graph of vertices
(things) and arcs (relationships).
Each diagram is supported by technical documentation that
specifies in more detail the model represented by the
diagram.
A diagram without documentation is of little value.
3
CS 501 Spring 2005
Actor and Use Case Diagram
• An actor is a user of a system in a
particular role.
BookBorrower
Borrow book
An actor can be human or an external
system.
• A use case is a a task that an actor
needs to perform with the help of the
system.
Use cases make more precise the concept of
viewpoint analysis.
4
CS 501 Spring 2005
Use Cases and Actors
• A scenario is an instance of a use case
• Actor is role, not an individual
(e.g., librarian can have many roles)
• Actor must be a "beneficiary" of the use case
(e.g., not librarian who processes book when borrowed)
In UML, the system boundary is the set of use cases.
5
CS 501 Spring 2005
Scenario
A scenario is a tool used during requirements analysis to walk
through a specific interaction with a proposed system.
Example
The requirements are being developed for a system that will
enable university students to take quizzes online from their own
rooms using a Web browser.
Create a scenario for a typical student.
6
CS 501 Spring 2005
Scenario: a Typical Student
Individual: Philip Glass, senior at Cornell, major in computer
science, location Risley Hall.
Equipment: Dell laptop attached to Cornell dormitory network.
Mozilla 5.1 browser and Sidecar authentication system
installed.
Scenario:
1. PG powers up computer and authenticates using Sidecar.
2. PG starts browser and types URL of Quiz system.
3. Quiz system displays list of options.
7
CS 501 Spring 2005
Scenario (continued)
4. PG selects CS 501 Quiz 1.
5. A list of questions is displayed, each marked to indicate
whether completed or not.
6. PG selects a question and specifies whether he will submit
a new answer or edit a previous answer.
7. For the first question, he is submitting a new answer. He
has a choice whether to type the solution into the browser
or to attach a separate file. He decides to attach a file.
8
8. For the second question, he is editing a previous answer. He
chooses to delete a solution previously typed into the
browser, and to replace it with an attached file.
CS 501 Spring 2005
Scenario (continued)
9. PG has now completed the quiz. He selects an
option that submits the quiz to the grading
system.
10. PG now wishes to change a solution. The system
does not permit changes once the solution has
been submitted.
11. PG logs off.
9
CS 501 Spring 2005
Modeling Scenarios as User Cases
A scenario is useful in discussing a proposed system with a
client, but needs to be generalized as part of the
requirements modeling.
A use case provides such a model.
10
CS 501 Spring 2005
Use Cases for Quiz System
TakeQuiz
QuizTaker
CheckGrades
Request
Regrade
11
CS 501 Spring 2005
Use Cases for Quiz System
SetQuiz
Instructor
Grade
Note that actor is a role.
An individual can be a
QuizTaker on one occasion
and an Instructor at a
different time.
12
Regrade
CS 501 Spring 2005
Relationships Between Use Cases:
<<includes>>
TakeQuiz
<<includes>>
Authenticate
QuizTaker
13
CheckGrades
<<includes>>
CS 501 Spring 2005
Relationships Between Use Cases:
<<extends>>
<<extends>>
QuizTaker
TakeQuiz
Connection
Fails
<<include>> is used for events that are in the flow of events
of the source use case.
<<extends>> is used for exceptional conditions, especially
those that can occur at any time.
14
CS 501 Spring 2005
Use Cases in the Development Cycle
• Use cases are a tool in requirements analysis
• Intuitive -- easy to discuss with clients
• Use cases are often hard to translate into class models
• Scenarios are useful to validate use cases and the design
of a system.
15
CS 501 Spring 2005
Documentation
Reasons for documentation:
visibility (e.g., project plan, interim report)
user support (e.g., user manual)
team communication (e.g., interface specifications)
maintenance and evolution (e.g., requirements)
Characteristics of documentation:
accurate and kept current
appropriate for audience
maintained online (usually)
simple but professional in style and appearance
Documentation is expensive --> Quality not volume
16
CS 501 Spring 2005
Requirements Specification: Purpose
1. Document that describes the requirements to the
stakeholders in a precise manner
• Expressed in the terms that the stakeholders understand
• As precise and specific as possible
• Comprehensible from many viewpoints
• Reviewed by stakeholders so that they understand
implications
• Must be clear about assumptions (things left out)
17
CS 501 Spring 2005
Requirements Specification: Purpose
2. It describes the requirements to the implementers
• As precise and specific as possible
• Expressed in terms that they understand
• Comprehensible to new team members
18
CS 501 Spring 2005
Requirements Specification: Purpose
3. It records the requirements for the future
• An essential part of system evolution
4. It may be a contractual document
19
CS 501 Spring 2005
Details in Requirements
Requirements must be specific
Examples -- university admissions system
Requests for information received by email must be answered
within one business day.
An admissions officer who is talking to an applicant by
telephone must be able to retrieve the applicant's records
within 10 seconds.
No financial aid offer may exceed the maximum defined in
Section 8.7.
20
CS 501 Spring 2005
Documentation of Use Case
Name: TakeQuiz
Actor(s): QuizTaker
Flow of events:
1. QuizTaker connects to the Quiz server.
2. Quiz server checks whether student is already authenticated and
transfer to Sidecar for authentication if necessary.
3. QuizTaker selects a quiz from a list of options.
4. QuizTaker repeatedly selects a question and either types in a
solution, attaches a file with a solution, edits a solution or attaches
a replacement file.
CS 501 Spring 2005
21
Specification of Use Case (continued)
Flow of events (continued):
5. QuizTaker either submits completed quiz or saves current state.
6. If a completed quiz is submitted, Quiz server checks that all
questions have been attempted and either sends acknowledgement
to QuizTaker, or saves current state and notifies QuizTaker of
incomplete submission.
7. QuizTaker logs out.
Entry conditions:
1. QuizTaker must have Cornell NetID.
2. Computing requirements: CIT supported browser and Sidecar
22
CS 501 Spring 2005
Requirements Specification: Process
The client must understand the requirements
specification.
• Do not assume that anybody has read a document.
• Do not assume that anybody understands a document.
Go through the requirements specification with the
client, line by line.
It is usual for the client and developer to sign the
requirements document when it is agreed.
[Compare with the plans to build a house. This is the
specification of the system that you are about to build.]
23
CS 501 Spring 2005
Requirements Analysis v. System Design
Dilemma.
• Requirements analysis should make minimal assumptions
about the system design.
• But the requirements definition must be consistent with
computing technology and the resources available.
In practice, analysis and design are interwoven. However:
1. Do not to allow the requirements analysis to prejudge the
system design.
*24
2. Do not allow assumptions about the design to influence
the requirements analysis.
CS 501 Spring 2005