CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 9 Requirements II
2
Administration
Quiz 1 If you did not pick it up on Thursday,
you can collect your quiz from reception at 301
College Avenue Feasibility Study Comments have
been sent to several groups. I plan to have them
all sent out by the end of today.
3
Weekly Progress Report
Every project will be assigned a Teaching
Assistant. Weekly progress reports Every Friday
beginning, February22 Send email to Teaching
Assistant Three short sections (total less
than one page) -gt What has been accomplished in
the past week (list of tasks)? -gt What is
planned for the next week? -gt Have any problems
arisen?
4
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. 2. Do not allow assumptions about
the design to influence the requirements analysis.
5
Models Useful Texts
Grady Booch, James Rumbaugh, Ivar Jacobson, The
Unified Modeling Language. Addison-Wesley
1999. Grady Booch, Object-Oriented Analysis and
Design with Applications, second edition.
Benjamin/Cummings 1994. Rob Pooley, Perdita
Stevens, Using UML Software Engineering with
Objects and Components. Addison-Wesley 1999.
6
Models
A model is a simplification of reality. We
build models so that we can better understand the
system we are developing. We build models of
complex system because we cannot comprehend such
a system in its entirety. Models can be informal
or formal. The more complex the project the
more valuable a formal model becomes. BRJ

7
Principles of Modeling
The choice of what models to create has a
profound influence on how a problem is attacked
and how a solution is shaped. Every model
can be expressed at different levels of
precision. The best models are connected to
reality. No single model is sufficient.
Every nontrivial system is best approached
through a small set of nearly independent
models. BRJ
8
The Unified Modeling Language
UML is a standard language for modeling software
systems Serves as a bridge between the
requirements specification and the
implementation. Provides a means to specify
and document the design of a software system.
Is process and programming language
independent. Is particularly suited to
object-oriented program development.
9
Rational Rose
Rational Rose is an IBM-owned system for creating
and managing UML diagrams. It is available for
Computer Science Department computers.
10
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.
11
Actor and Use Case Diagram
An actor is a user of a system in a
particular role. 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.
BookBorrower
Borrow book
Use cases make more precise the concept of
viewpoint analysis.
12
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.
13
Accessibility Profile
Accessibility Creating computer systems that can
be used by people with special needs, e.g., poor
vision, lack of hearing, disabilities,
etc. Profile A description of a user with
special needs, e.g., an elderly person with
20/70 vision who is unable to control a
mouse a 20 year old student who is red-green
color blind
14
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.
15
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. Firefox 2.0 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.

16
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. 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.
17
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.
18
Modeling Scenarios as Use 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. There is a detailed
discussion of use cases in Wikipedia. The
approach used in this course is less complex than
the Wikipedia article.
19
Specification 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.
20
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
21
Use Case Diagram for Quiz System
TakeQuiz
QuizTaker
CheckGrades
RequestRegrade
22
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.
Regrade
23
Relationships Between Use Cases ltltincludesgtgt
ltltincludesgtgt
TakeQuiz
Authenticate
QuizTaker
CheckGrades
ltltincludesgtgt
24
Relationships Between Use Cases ltltextendsgtgt
ConnectionFails
ltltextendsgtgt
TakeQuiz
QuizTaker
ltltincludegtgt is used for events that are in the
flow of events of the source use
case. ltltextendsgtgt is used for exceptional
conditions, especially those that can occur at
any time.
25
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.
26
Documentation General
Reasons for documentation visibility (e.g.,
project plan, interim report) user
support (e.g., user manual) team
communication (e.g., interface specifications) ma
intenance 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
--gt Quality not volume
27
Documentation of 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)
28
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
29
Requirements Specification Purpose
3. It records the requirements for the future
An essential part of system evolution 4. It may
be a contractual document
30
Requirements Specification Details
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.
31
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.