CS 160: Software EngineeringSeptember 8 Class Meeting
Department of Computer ScienceSan Jose State University
Fall 2014Instructor: Ron Mak
www.cs.sjsu.edu/~mak
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
2
Functional Requirements
What the system shall be able to do or allow users to do.
“The phone shall use GPS to determine the wearer’s location.”
“Users shall be able to choose either Option A or Option B.”
Describe the interactions between the system and its environment independent of its implementation._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
3
Nonfunctional Requirements
Usability, reliability, performance, supportability, etc.
“The system must respond to the user within 15 seconds.”
“The system shall run on Windows and Linux servers.” “The new GUI must resemble the existing GUI.”
Constraints that the system must meet._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
4
Requirements Must Have …
Completeness Are all system features described by requirements?
Consistency No two requirements can contradict each other.
Clarity Each requirement must be unambiguous.
Correctness No errors in the requirements. Can each application function be traced
to a requirement?
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
5
Requirements Must Have, cont’d
Realism Can the system be implemented?
Verifiability Can the system be tested?
Traceability Can each requirement be traced
to an application function?_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
6
Requirements are Strong Statements
Use strong declarative statements with “shall” and “must”.
“The phone shall use GPS to determine the wearer’s location.”
“The system must respond to the user within 15 seconds.”_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
7
How to Get Requirements
Interview future users of your application.
Observe how the users currently work.
Stated requirements The user tells you want he or she wants.
Implied requirements What do you think the user wants?
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
8
How to Get Requirements, cont’d
Users don’t always know what they want. They will know more when you show them
a prototype. They will change their minds.
It’s an iterative process!_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
9
How to Get Requirements, cont’d
If the developers force the clients or users to come up with the requirements too soon, they may make something up!
Such requirements will most likely be wrong or incomplete._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
10
Use Cases
A use case describes a single task that your application must allow an actor to accomplish or a single goal that an actor must achieve.
Actors are external agents that interact or communicate with the system. actors = role abstractions An actor can be a person or another system.
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
11
Use Cases, cont’d
A use case includes: A complete sequence of actions or events from the
point of view of an actor.
A primary sequence plus alternate sequences (“exception paths”).
A sequence is triggered by an actor.
Focus on what the system must do, not how to do it.
A use case treats the system as a “black box”.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
12
Example: Bank ATM System
Log incustomer
Display balance
Shut downATM
Start upATM
Log outcustomer
Withdrawcash
Operator
Customer
Bank
system boundary
actor
interaction
system
UML use case diagram
use cases
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
13
Example Use Case Description
Name: Withdraw Cash
Goal: Customer withdraws cash from ATM.
Summary: A customer who has logged in can withdraw up to $500 cash in $20 bills.
Actors: The customer and the bank_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
14
Example Use Case Description, cont’d
Preconditions: The ATM has been started up.
See use case “Start up ATM”. The customer has inserted a valid bank card. The customer has entered a correct PIN.
Trigger: The customer selects the “Withdraw Cash” option._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
15
Example Use Case Description, cont’d
Primary sequence:
1. The system prompts the customer for the amount.
2. The customer chooses from a list of amounts or enters a amount.
3. The customer submits the amount.
4. The system dispenses the amount in $20 bills.
5. The bank deducts the amount from the customer’s balance.
6. The system displays the customer’s balance See use case “Display balance”.
At most about 10 steps.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
16
Example Use Case Description, cont’d
Alternate sequences:
3.1 The customer entered an amount that is not a multiple of $20. 3.1.1 The system displays a message to the customer . 3.1.2. The system prompts the customer for a new amount.
3.2 The customer’s bank balance is insufficient. 3.2.1 etc.
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
17
Example Use Case Description, cont’d
Postconditions:
The customer receives the desired amount of cash. The amount is deducted from the customer’s account. The customer sees the new account balance.
OR: The customer receives no cash. The customer’s account is unchanged.
What must be true after the use case is done.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
18
Example Use Case Description, cont’d
Nonfunctional requirements: The system responds to each customer input
within 15 seconds. The system displays messages in either English,
Spanish, or Vietnamese.
Glossary customer = a person who wants to withdraw cash
from the ATM. bank = a system that maintains customer accounts
and balances. etc.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
19
Use Case Description Guidelines
Use case names should be verb-object.
Each name should describe an achievable goal or doable task (e.g., “Withdraw Cash”).
Keep use cases short, simple, and informal.
Clients and users need to understand them. No GUI or implementation details.
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
20
The Functional Specification
Primary contents of aFunctional Specification
Product name
Clear problem statement What is the
problem?
Objectives What is your
application supposed to accomplish?
Functional requirements Nonfunctional requirements
Use cases
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
21
Assignment #1: Functional Specification
Each project team creates the first draft of theFunctional Specification for its web application. Product name Problem statement Objectives 6 Functional requirements 4 Nonfunctional requirements Use case diagram with 6 use cases Use case descriptions of 3 of your use cases
Later assignments will add a conceptual design and screen mockups.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
22
Assignment #1, cont’d
Each team turns in one Functional Specification. Microsoft Word document or PDF
Email as an attachment to [email protected]
Subject: CS 160-n Assignment #1 Team namewhere: n is your section number, 3 or 4and Team name is your team name.
Example: CS 160-3 Assignment #1 Super Coders_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
23
Assignment #1, cont’d
Due Monday, September 15 at 11:59 PM.
Use case description form:http://www.cs.sjsu.edu/~mak/CS160/assignments/1/UseCaseForm.docx
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
24
Conceptual Design
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
25
Conceptual Design, cont’d
A high-level description of your application design.
A written report and an oral presentation. A “product pitch”.
Conceptual design formal design document
Created by the software developers. Understandable by the product’s users, clients,
and stakeholders._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
26
Conceptual Design Contents
Problem statement and objectives.
What is the purpose of this application? What will it do?
Overview of your solution
A list of major features A description of your application’s major modules
and how they will interact with each other High-level diagrams No implementation details
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
27
Conceptual Design Contents, cont’d
Prototype of a key use case
A sequence of screen shots Live demo with mocked-up web pages
(can be static pages)_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
28
Example Conceptual Design Presentation
Real-time Fault Analysisfor
Manned Space Vehicle Systems
(Based on a real NASA applicationand an actual presentation.)
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
29
Problem Statement
During emergency situations, a real-time fault analysis system must rapidly suggest correct remedies for the onboard astronauts to implement.
Space vehicle fault analysis is a daunting task, especially in extremely remote environments.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
30
Project Objectives
Design and develop a real-time fault analysis system for manned space vehicles that overcomes the following challenges:
Diverse and disparate data sources Incomplete or imprecise vehicle sensor data Insufficient working knowledge of the vehicle system Real time diagnosis and rapid response Limited system resources Loss of communication with ground control
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
31
Product Features
A web application that stores and remembers past faults and their remedies in a repository. Each fault is defined by a
snapshot of sensor readings.
Collect and integrate data from various sources. Sensor readings Parts lists and maintenance manuals
_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
32
Product Features, cont’d
When a fault occurs, search for it in the repository. If there is a fault match, display its remedy. If there are no exact matches, then display the
remedies of the closest matches. Compute and display the confidence level of each
displayed remedy based on the closeness of match.
Enter the latest fault and its solution into the repository. The repository “gains experience”
and becomes more useful.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
33
Major Modules
Datasources
Databases Sensors Files
Data integration server
Virtualdata views
Faults archive server
Faultsmatchingengine
Faults database
Server system
Webserver
Applicationserver
Webobjects
Applicationobjects
Matchingrules base
Users
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
34
Use Case Overview
Name: Fix Coolant Leak
Goal: Provide remedies to a coolant leak.
Summary: An astronaut must be provided remedies to a detected coolant leak in the space vehicle.
Actors: The astronaut and the space vehicle_
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
35
Use Case Overview
Preconditions
The astronaut is in the space vehicle. The space vehicle is in space. The system sensors are actively monitoring the
vehicle.
Primary trigger
The vehicle sensors detect a drop in the warp engine coolant level._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
36
Example Use Case Description (cont’d)
Primary sequence
1. The sensor monitor display flags a coolant leak.
2. Realtime fault analysis display possible diagnoses. See use case “Match fault” See use case “Compute confidence level”
3. The astronaut clicks on each diagnosis to display the associated remedy._
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
37
Example Use Case Description (cont’d)
Primary postconditions The astronaut chooses the most likely diagnosis. The astronaut implements the corresponding remedy.
Alternate sequences etc.
Nonfunctional requirements The system sensors are constantly active. The system displays alerts in real time.
Glossary astronaut = a person flying in the space vehicle. space vehicle = etc.
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
38
Use Case Demo
http://www.cs.sjsu.edu/~mak/CS160/lectures/prototype-100204/
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
39
Actual Screen Shot
NASA lingo
ISSInternational Space Station
PUIProgram Unique Identifier (i.e., part number)
PRACAProblem Report and Corrective Action
Computer Science Dept.Fall 2014: September 8
CS 160: Software Engineering© R. Mak
40
Link to Design Video
https://www.youtube.com/watch?v=BKorP55Aqvg
Top Related