CS 160: Software Engineering September 8 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron 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 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? 4

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak 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? _ 5

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak 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.” _ 6

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak 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? _ 7

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak 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! _ 8

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 in customer Display balance Shut down ATM Start up ATM Log out customer Withdraw cash 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.  The system displays a message to the customer.  The system prompts the customer for a new amount. 3.2 The customer’s bank balance is insufficient.  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 a Functional 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 the Functional 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 Assignment #1, cont’d  Each team turns in one Functional Specification. Microsoft Word document or PDF  as an attachment to Subject: CS 160- n Assignment #1 Team name where: n is your section number, 3 or 4 and Team name is your team name. Example: CS Assignment #1 Super Coders _ 22

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak Assignment #1, cont’d  Due Monday, September 15 at 11:59 PM.  Use case description form:

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 Analysis for Manned Space Vehicle Systems (Based on a real NASA application and 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 Data sources DatabasesSensorsFiles Data integration server Virtual data views Faults archive server Faults matching engine Faults database Server system Web server Application server Web objects Application objects Matching rules 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

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak 39 Actual Screen Shot  NASA lingo ISS International Space Station PUI Program Unique Identifier (i.e., part number) PRACA Problem Report and Corrective Action

Computer Science Dept. Fall 2014: September 8 CS 160: Software Engineering © R. Mak Link to Design Video 