CS 5150
Software Engineering
Lecture 9
Requirements 2
CS 5150
1
Administration
Feasibility Study
Comments have been sent to all groups. Contact me if
you have any questions.
CS 5150
2
Feasibility Studies: Scope
The purpose of a feasible study is to establish if a project is
feasible, at reasonable cost, within the planned period.
• Many of your reports had not gone into the activities in enough
detail to estimate the effort convincingly.
• Several of the reports were vague about the scope. Without a
clear definition of scope, it is not clear that the project is feasible.
• Several projects are too ambitious. How will you monitor the
progress and adjust the scope if necessary?
CS 5150
3
Feasibility Studies: Reports
Appoint a team member to read and edit the entire report.
Content
• If different authors write different sections of the report are they
consistent? E.g., do the scope, requirements, and plan agree on
what is to be done?
Style
• Is the text comprehensible? Does the report use jargon that is
not clear to the client?
• If possible, have a native English speaker do the final editing.
CS 5150
4
Functional Requirements
Functional requirements describe the functions that
the system must perform. They are identified by
analyzing the use made of the system:
• Functionality
• Data
• User interfaces
Modeling the functional requirements is the theme
of the this lecture and the next.
CS 5150
5
Non-Functional Requirements
Requirements that are not directly related to the
functions that the system must perform
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Marketing and public relations
Example: In the NSDL, the client (the National
Science Foundation) wanted a system that could
be demonstrated by the end of 2002
CS 5150
6
Example of Non-Functional Requirements
Example: Library of Congress Repository
Use technology that the client's staff are familiar with:
• Hardware and software systems (IBM/Unix)
• Database systems (Oracle)
• Programming languages (C and C++)
Recognize that the client is a federal library:
• Regulations covering government contracting,
accessibility to people with disabilities, etc.
• Importance of developing a system that will be respected
by other major libraries
CS 5150
7
Requirements Analysis v. System Design
Dilemma about technical decisions
• 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 allow assumptions about the design to influence
the requirements analysis.
2. Do not to allow the requirements analysis to prejudge the
system design.
CS 5150
8
Scenarios
Scenario
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.
Note on terminology
Some authors restrict the word "scenario" to refer to the
user's total interaction with the system.
Other authors use the word "scenario" to refer to parts of
the interaction.
In this course, the term is used with both meanings.
CS 5150
9
Developing a Scenario with a Client
Example of how to develop a scenario with a client
The requirements are being developed for a system that will
enable university students to take exams online from their
own rooms using a Web browser.
Create a scenario for how a typical student interacts with the
system.
In the next few slides, the questions in blue are typical of the
questions to ask the client while developing the scenario.
CS 5150
10
Developing a Scenario with a Client:
a Typical Student
Individual: Jane Smith, senior at Cornell, major in computer science.
[Where can she be located? Do other universities differ?]
Equipment: [What equipment is supported? What software is
required? Are there any network restrictions?]
Scenario:
1. JS authenticates. [How does she authenticate?]
2. JS starts browser and types URL of Exam system. [How does she
know the URL?]
3. Exam system displays list of options. [Is the list tailored to the
individual user? If so how?]
CS 5150
11
Developing a Scenario with a Client (continued)
4. JS selects CS 1234 Exam 1. [Does she have other options?]
5. A list of questions is displayed, each marked to indicate
whether completed or not. [Where does this information
come from?]
6. JS selects a question and specifies whether she will submit a
new answer or edit a previous answer. [Does she always
have these options?]
7. For the first question, she is submitting a new answer. She
has a choice whether to type the solution into the browser or
to attach a separate file. She decides to attach a file. [What
types of question are there: text, multiple choice, etc? What
types of file are accepted?]
CS 5150
12
Developing a Scenario with a Client (continued)
8. For the second question, she is editing a previous answer. She
chooses to delete a solution previously typed into the browser,
and to replace it with an attached file. [Can she edit a previous
answer, or must she replace it?]
9. JS has now completed the exam. She selects an option that
submits the exam to the grading system. [What happens to the
solution? What if she has not attempted every question?
Where is the exam stored? Is the grader notified?]
10. JS logs off.
11. JS now wishes to change a solution. The system does not
permit changes once the solution has been submitted. [Can she
still see her solution?]
CS 5150
13
Developing a Scenario with a Client (continued)
12. As an alternative to completing the entire exam in a single
session, JS completes several questions, then saves her work
to continue later. [Is this permitted?]
13. Later JS log in, finishes the exam, submits her answers, and
logs out. [What is the process for re-authenticating?]
14. Later JS logins in to check her grades. [When are grades
made available? How does she know?]
15. JS requests a regrade. [What are the policies? What are the
procedures?]
CS 5150
14
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
CS 5150
15
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
CS 5150
16
Models: Useful Texts
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.
CS 5150
17
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.
CS 5150
18
Rational Rose
Rational Rose is an IBM-owned system for creating
and managing UML diagrams.
It is available on Computer Science Department
computers.
CS 5150
19
Models: Diagrams and Specification in UML
In UML, a model consists of a diagram and a specification.
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 a specification is of little value.
CS 5150
20
Modeling Scenarios as Use Cases
Models
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.
CS 5150
21
Actor and Use Case Diagram
• An actor is a user of a system in a
BookBorrower
particular role.
PressureSensor
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.
RecordPressure
CS 5150
22
Use Cases and Actors
• 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".
CS 5150
23
Use Cases for Exam System
TakeExam
ExamTaker
CheckGrades
Three separate
use cases
CS 5150
Request
Regrade
24
Outline of TakeExam Use Case
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
25
Outline Specification of Use Case (continued)
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
26
Use Cases for Exam System (continued)
SetExam
Instructor
Grade
Note that actor is a role.
An individual can be a
ExamTaker on one
occasion and an Instructor
at a different time.
CS 5150
Regrade
27
Relationships Between Use Cases: <<includes>>
TakeExam
<<includes>>
Authenticate
ExamTaker
CheckGrades
<<includes>>
The Authenticate use case may
be used in other contexts
CS 5150
28
Relationships Between Use Cases: <<extends>>
<<extends>>
ExamTaker
TakeExam
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.
CS 5150
29
Scenarios for Analyzing Special Requirements
Scenarios are very useful for analyzing special requirements.
Examples
• Reversals. 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.
CS 5150
30
Scenarios and Use Cases in the Development Cycle
Scenarios are a tool for requirements analysis.
• They are useful to validate use cases and in checking the
design of a system.
• They can be used as test cases for acceptance testing
Use cases are a tool for modeling requirements
• 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.
CS 5150
31