CS 5150
Software Engineering
Lecture 8
Requirements 2
Administrivia
CS 5150
•
Quizzes being graded
•
Feasibility study/plan due Friday
•
Sign-up online for presentation slots
2
Your Feasibility Reports
•
•
•
TAs convinced me to use CMS
•
Shorter does not mean less quality
Most important points
•
•
CS 5150
Will update the website with proper links
Clear on scope. What’s in, what’s out? If
you’re uncertain, discuss the uncertainty.
Plan with reasonably detailed effort
estimates and a few high-level milestones
3
Some Suggestions
•
•
•
CS 5150
Make one person responsible for the final edit
•
Inconsistencies within a document leave a
bad impression
Explain any jargon that might not be clear to
non-computer people or people outside the
domain of your project
If possible, get an edit from someone with
native-level English fluency
4
•
Last Lecture: Functional
Requirements
Functional requirements describe what the
system should do, not how it should do it
•
•
•
•
•
CS 5150
High-level functions
Services
Data
User interfaces
Any questions inspired by your role-playing
last time?
5
Other Kinds of Requirements
•
•
•
•
CS 5150
Product requirements
•
Performance, reliability, portability, ...
Organizational requirements
•
Delivery, training, standards compliance, ...
External requirements
•
Legal, interoperability, ...
Marketing and public relations
•
Must work well on a particular benchmark or
data set, ...
6
•
•
•
Example of Non-Functional
Requirements
Library of Congress Repository
Use technology that is familiar to existing staff
•
•
•
Databases (Oracle)
Programming languages (C/C++)
Client’s (federal government) special
constraints
•
•
CS 5150
Systems (IBM/UNIX)
Regulations governing contracting,
accessibility, ...
Importance of respect of other institutions
7
Requirements Analysis vs System
Design
•
•
Where is the line between defining what a
software system should do and how it should
do it?
•
What we have are guiding principles:
•
•
CS 5150
There is no such hard line!
Do not allow assumptions and constraints
about system implementation affect
functional requirements
Do not allow high-level requirements
analysis to predetermine system design
8
Scenarios/Stories/Use Cases
•
•
A scenario is a tool used during requirements
analysis to describe a user's interactions with
a proposed system. Scenarios capture the
system as visualized by the user, by use of
specific examples.
Some people think “scenario” should only be
used for complete user interactions
•
CS 5150
I don’t see a need to fuss about this
terminology
9
Developing a Scenario with a Client
•
•
In general, scenarios can be written by the
client, users or developers/designers
One example of how to develop a scenario in
collaboration with a client
•
CS 5150
Developing a system that will allow college
students to take exams from their own
rooms using a web browser
10
A Typical Student
•
•
•
CS 5150
Individual: Jane Smith is a senior at Cornell
studying computer science; she wants to move
to California and work for Facebook. [Would
anything be different at a different university?]
Situation: Jane lives in an on-campus dorm
and likes to do work in the engineering library.
[Does on-campus versus off-campus matter?]
Equipment: Jane has an ASUS laptop on
which she installed a custom version of Linux.
[What software and/or hardware requirements
are there?]
11
A Typical Interaction (1/4)
1. JS opens her computer and connects to the
service. [How does she know the service
exists? How does she find it?]
2. JS logs in. [How does she authenticate? Is
integration with other authentication systems
needed?]
3. JS peruses the list of exams. [Is it tailored to
specific users? What does she do if the exam
she’s expecting to take isn’t there?]
CS 5150
12
A Typical Interaction (2/4)
4. JS selects CS 1234 Exam 2. [Does she have
other options? What if she selected it
accidentally?]
5. A list of questions is displayed, each marked
to indicate whether it is completed. [Where
does this information come from? Can it work
offline?]
6. JS selects a question. [Can already answered
questions be edited?]
7. JS chooses to submit a new answer. She has
the option of typing in the browser or attaching
a file. [What kinds of files are supported? What
kinds of question formats?]
CS 5150
13
A Typical Interaction (3/4)
8. JS chooses to edit another answer. [Can she
edit the existing answer, or just replace it?]
9. JS is done and chooses to submit the exam.
[Does the system check that all questions are
answered? What happens to her solutions?
Are notifications sent?]
10.JS logs off. [Do any caches need to be
cleared?]
11.JS wants to change an answer, but the
system blocks her because she already
submitted. [Can she still see her solutions?]
CS 5150
14
A Typical Interaction (4/4)
12.In a parallel universe, JS does not submit the
exam, but logs out to finish it later. [Is this
permitted? If not, what it she is disconnected
accidentally?]
13.Later JS logs back in and completes the
exam. [Is there anything different about
logging in the second time?]
14.Later JS logs in to check her grade. [Is she
notified when grading is done?]
15.JS requests a regrade. [What are the policies?
Does the system enforce the automatically?]
CS 5150
15
Models
•
A model is an abstraction/simplification of
reality
•
•
•
CS 5150
We build models of complex systems so we
can talk about them, even if we don’t
understand the details
We build models to sharpen our
understanding of real systems
Models can be informal or formal
16
Principles of Modeling
•
•
•
•
CS 5150
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 mostly independent models.
17
Useful Texts on Modeling
•
•
•
CS 5150
Grady Booch, James Rumbaugh, Ivar
Jacobson, The Unified Modeling Language.
Addison-Wesley 1999.
Grady Booch, et al., Object-Oriented Analysis
and Design with Applications, third edition.
Benjamin/Cummings 2007.
Rob Pooley, Perdita Stevens, Using UML
Software Engineering with Objects and
Components, second edition. Addison-Wesley
2005.
18
The Unified Modeling Language
(UML)
•
•
•
•
UML is a common language for modeling
software
UML is used to connect requirements to actual
implementations
UML is a way to specify and document high
level design decisions
UML is process and programming language
independent
•
CS 5150
UML is tilted towards object-oriented
design/programming
19
Rational Rose
•
Rational Rose is a company that makes UMLrelated tools
•
•
CS 5150
Acquired by IBM
Available on Computer Science department
computers (?)
20
UML: Diagrams and Specifications
•
•
•
CS 5150
In UML, a model is a diagram and a
specification (text)
The diagram is typically a graph of elements
and their relationships
Each diagram is supported by documentation
that elaborates on the entities and their
relationships
21
Scenarios Become Use Cases in
UML
•
•
•
•
CS 5150
Scenarios are useful in discussing a proposed
system with a client, but requirements need to
be made more precise before a system is fully
understood.
This is the purpose of requirements modeling.
A use case provides such a model.
There is a good discussion of use cases in
Wikipedia. The approach used in this course is
less complex than the Wikipedia article.
22
Actors and Use Cases
•
An actor is a user of a
system in a particular
role
•
•
CS 5150
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
23
Use Cases and Actors
•
•
•
•
CS 5150
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
In naming actors, choose names that describe
the use case, not generic names, such as "user"
or "client"
24
Use Cases for Exam System
CS 5150
25
Outline of TakeExam Use Case (1/2)
•
•
•
Name of Use Case: TakeExam
Actor(s): ExamTaker
Flow of events:
1. ExamTaker connects to the Exam server.
2. Exam server checks whether student is already
authenticated and runs authentication process if
necessary.
3. ExamTaker selects a exam from a list of options.
4. ExamTaker 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 5150
26
Outline of TakeExam Use Case (2/2)
•
Flow of events (continued):
5. ExamTaker either submits completed exam or saves
current state.
6. When a completed exam is submitted, Exam server
checks that all questions have been attempted and
either sends acknowledgement to ExamTaker, or
saves current state and notifies ExamTaker of
incomplete submission.
7. ExamTaker logs out.
•
Entry conditions:
1. ExamTaker must have Cornell NetID.
2. Computing requirements: Supported browser
CS 5150
27
Use Cases for the Exam System
(continued)
CS 5150
28
Relationships Between Use Cases:
<<includes>>
CS 5150
29
Relationships Between Use Cases:
<<extends>>
•
•
CS 5150
<<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.
30
•
•
•
•
•
•
CS 5150
Strength of Scenarios and Use Cases:
Exceptions
Scenarios are very useful for analyzing special/unusual
requirements
Examples
Undoing. In a financial system, a transaction is credited
to the wrong account. How is it reversed?
Errors. A mail order company has several copies of its
inventory database. What happens if they become
inconsistent?
Malfeasance. In a voting system, a voter has houses in
two cities. What happens if he attempts to vote in both of
them?
Murphy's Law: "If anything can go wrong, it will". Create a
scenario for everything that can go wrong and how the
system is expected to handle it.
31
Scenarios and Use Cases in the Development
Process
•
Scenarios are a tool for requirements analysis
•
•
•
They can be used as test cases for acceptance
testing
Use cases are a tool for modeling requirements
•
•
•
CS 5150
They are useful to validate use cases and in
checking the design of a system
They are intuitive -- easy to discuss with clients
Use cases are often hard to translate into class
models
A set of use cases can provide a framework for
the requirements specification.
32