CS 160: Software Engineering September 8 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak mak.

CS 160: Software EngineeringSeptember 8 Class Meeting

Department of Computer ScienceSan Jose State University

Fall 2014Instructor: Ron Mak

www.cs.sjsu.edu/~mak

http://www.cs.sjsu.edu/~mak

http://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._



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._



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?



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?_



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.”_



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?

_



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!_



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._



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.

_



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”.



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



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_



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._



15


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.



16


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.

_



17


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.



18


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.



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.

_



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



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.



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_

mailto:[email protected]



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

http://www.cs.sjsu.edu/~mak/CS160/assignments/1/UseCaseForm.docx

http://www.cs.sjsu.edu/~mak/CS160/assignments/1/UseCaseForm.docx



24

Conceptual Design



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._



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



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)_



28

Example Conceptual Design Presentation

Real-time Fault Analysisfor

Manned Space Vehicle Systems

(Based on a real NASA applicationand an actual presentation.)



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.



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

_



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

_



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.



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



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_



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._



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._



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.



38

Use Case Demo

http://www.cs.sjsu.edu/~mak/CS160/lectures/prototype-100204/

http://www.cs.sjsu.edu/~mak/lectures/prototype-100204/





39

Actual Screen Shot

NASA lingo

ISSInternational Space Station

PUIProgram Unique Identifier (i.e., part number)

PRACAProblem Report and Corrective Action



40

Link to Design Video

https://www.youtube.com/watch?v=BKorP55Aqvg



CS 160: Software Engineering September 8 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak mak.

Documents

mak requirements

software engineering

stated requirements

implied requirements

system features

ron mak

future users

contd users dont