Systems Requirements Analysis CS 3302 Lecture 3

1
Systems / Requirements AnalysisCS 3302Lecture 3

• David Smith
• dmsmith_at_cc.gatech.edu

2
Course Overview
Week 2 Concept
Weeks 3-4 Requirements
Weeks 5-6 Design
Weeks 7-8 Code
Process Management Analysis Planning
Scheduling Tracking Risk Management SW Design
Week 9 Test
Week 10 Slack Time
OO Concepts OO Design
Measurement Testing Design for Real-Time
Requirements Review
Software Quality Software Re-Use
Design Review
Modeling Summary
Demo
3
Systems Analysis
Systems Analysis is the most creative and
difficult part of the business of making a product
Systems Analysis
Software Requirements Analysis
Software Design
4
What is a System?

• A system is
• A set or arrangement of elements that are
  organized to accomplish some method, procedure,
  or control by processing information. Pressman
• Examples
• MARTA
• Banking
• the nervous system

5
System Engineering

• Define a system to solve a specific problem
• Begin with customer-defined goals and constraints
• function
• performance
• interfaces
• design constraints
• information structure
• Set bounds and limits
• Define the success criteria

6
System Allocation

• Parcel out functionality to system elements

Elevator
control
move
people
Motion System
Cage
Control System
go
stop
safe access
inside control
protect
operate
outside control
Motor
Brakes
Doors
Box
Panel
Call Buttons
Processor
7
Criteria for Allocation

• Cost and schedule considerations
• Profit / Loss considerations
• Technology
• Facilities for manufacturing
• Personnel issues
• Environment
• Legal issues
• Subcontracting

8
Requirements Analysis
Requirements Analysis bridges the gap between
Systems Analysis and Software Design
Systems Analysis
Software Requirements Analysis
Software Design
9
Characteristics of Requirements

• Correctness-
• Consistency
• Completeness
• Realism
• Necessity
• Verifiability
• Traceability

10
Structured Analysis

• 1960 - 1970 Graphical notation (Yourdon)
• 1979 - DeMarco
• Flow models
• Data dictionary
• Processing narratives
• 1980s - Page-Jones, Gand and Sarson
• Focus on Information Systems
• Mid - 1980s Ward and Mellor, Hatley and Pirbhai
• Control systems
• Real-Time extensions
• Today - attempts to standardize
• CASE tool support

11
Specification Principles

• Separate functionality from implementation
• Choose a process-oriented specification language
• Specification must address the external
  environment
• Specification must be operational
• Specification must be tolerant of incompleteness
• Localized and loosely coupled

12
Interface Requirements Evolution
13
Interface Requirement - 2
14
Interface Requirement - 3
15
Project Deliverables
Project Plan
1
Week 2 Concept
Weeks 3-4 Requirements
2
3
Weeks 5-6 Design
Weeks 7-8 Code
1
Week 9 Test
2
Requirements Specification
Design Description
Code
Test Report
Personal Activity Reports
16
Requirements Specification

• 1 Introduction
• 1.1 Scope and Purpose
• 1.2 Overview
• 2 Use Cases
• 3 System Behavior
• 3.1.1 Stimulus
• 3.1.2 Processing
• 3.1.3 Result
• 4 System Architecture
• 4.1 Physical
• 4.2 Logical
• 5 Software Specification
• 5.1 Data Dictionary
• 5.2 Entity Relationship Diagram
• 5.3 Data Flow Diagrams
• 5.4 State Transition Diagrams
• 6 System Verification

17
1 Introduction

• 1.1 Scope and Purpose
• ltwhat is this project for?gt
• 1.2 Overview
• 1.2.1 Objectives
• ltdescribe the overall concept identify the
  users outline expected behavior sketch
  graphics conceptsgt
• 1.2.2 Constraints
• ltwhat are the constraints time, personnel,
  traininggt

18
2 Use Cases

• ltdescribe each usergt
• 2.1 User lttypegt
• ltdescription of first usegt
• ltdescription of second usegt
• 2.2 User lttypegt
• ltdescription of first usegt
• ltdescription of second usegt

19
Use Case Examples

• Passenger
• A passenger wishing to go to another floor of the
  building presses the elevator call button. When
  an elevator is available, the doors open and the
  passenger enters the cage. The passenger presses
  one of the inside buttons to select the
  destination floor. The doors close and the
  elevator moves to the destination floor the
  doors open and the passenger leaves.
• Maintainer
• When an elevator requires maintenance, the
  maintainer disables the elevator call buttons,
  attaches his external control box and exercises
  individual elevator control commands and display
  features.

20
3 System Behavior

• Note This is best written after you have done
  section 5.3
• ltspecify the observable behavior of the total
  systemgt
• 3.1 Behavior lttitlegt
• 3.1.1 Stimulus
• ltwhat causes the behaviorgt
• 3.1.2 Processing
• ltwhat general processing must take placegt
• 3.1.3 Result
• ltresults you can observegt
• 3.2 Behavior lttitlegt
• 3.2.1 Stimulus
• ltwhat causes the behaviorgt
• 3.2.2 Processing
• ltwhat general processing must take placegt
• 3.2.3 Result
• ltresults you can observegt

21
4 System Architecture

• 4.1 Physical
• ltphysical description, with diagrams as
  appropriategt
• 4.2 Logical
• ltLevel 0 context diagram with discussiongt

22
Physical Description

• Parcel out functionality to system elements

Elevator
control
move
people
Motion System
Cage
Control System
go
stop
safe access
inside control
protect
operate
outside control
Motor
Brakes
Doors
Box
Panel
Call Buttons
Processor
23
Logical Description
cage_ status
Lights
motor_status
Motor
0
motor_control
Processor
outside_ request
door_status
Call Buttons
door_ control
inside_ request
Doors
Panel
24
5 Software Specification

• ltidentify top-level software capabilitiesgt
• 5.1 Data Dictionary
• lttable identifying and describing all data items
  on data flow diagramsgt
• 5.2 Entity Relationship Diagram
• ltdiagram Is_A and Has_A relationshipsgt
• 5.3 Data Flow Diagrams
• 5.4 State Transition Diagrams
• ltif the expected behavior of a particular
  function is complex, amplify by means of a STDgt

25
Extract from a Data Dictionary
26
Entity Relationship Diagram
Cage
People
Motor
Doors
Buttons
Processor
27
Data Flow - Level 1
cage_ status
motor_status
motor_control
door_status
outside_ request
inside_ request
door_ control
28
Control Flow - Level 1
clock
cage_ status
motor_status
motor_control
door_status
outside_ request
inside_ request
door_ control
29
Control Flow - Level 2
clock
motor_status
elevator_status
door_status
commands
door_ control
30
State Transition Diagram - Door Control
power off
power_on
initial
shut down
must be shut
cage_moving
closed
power_switch_off
cage_stopped
open_command
closed_status
opening
closing
open_status
close_command
open
31
6 System Verification

• lttable listing all behaviors in Section 3 and the
  techniques to be used for verifying that the
  behaviors are exhibitedgt