Customer PointsofContention

1
Customer Points-of-Contention

• Schedule Budget
• Function
• Documentation technical, user, and training
  manuals
• Training
• Maintenance / Enhancements
• Requirements Changes
• Status and Reviews

2
Phase II

• Write PARTS OF an SRS
• Drawings
• Integration Thread
• Cross Reference

3
The Software Requirements Specification

• After review of the customers System Spec.
• After educated analysis
• Preliminary design
• A technical, software approach
• Results in permission to detail-design and code

4
From the customers perspective

• How smart people are going to solve the problem
  that was stated in the System Spec.
• A contract, more or less
• Is it doable?
• Technically
• On time
• Under budget

5
Settles these issues

• Software Architecture
• Object Oriented?
• Structured?
• Database Oriented (Informational Flow)?
• Major Modules
• to 2 or 3 levels of supervision
• low level utilities

6
Modularization

• Break up the proposed architecture
• If the interfaces are solid, they can be done in
  parallel
• If the interfaces are solid, they will isolate
  changes and errors
• If the interfaces are solid, they can be
  integrated easily

7
What is a module?
Storage
Outputs
Processing
Inputs
8
Block Diagram - shows module relationships
9
Structure Chart - shows levels of supervision
10
Data Flow Diagram - shows movement, conversion,
and storage of data
11
Cloud Chart - (pre UML) object relationships
12
The Approach

• Software Development Methodology
• Waterfall
• Staged / Evolutionary
• Integration Thread what gets built and tested
  first
• Prototyping Needs
• Delivery Schedule

13
Risk Assessment

• Technical Risks
• hardware
• software
• interfaces
• Schedule Risks
• budget
• calendar
• personnel level of expertise required

14
Major Module Descriptions

• Supervisory / Executive
• Classes, Major Objects, and Libraries
• Build vs. Buy
• Interfaces
• Module to Module
• SW to HW
• Control to Data
• Low Level Utilities
• Drivers

15
Development Vehicle

• Development OS (may have been specified in System
  Spec)
• Language (may have been specified in System Spec)
• Editors, Syntax Checkers, Libraries
• The Configuration Management and Version Control
  Systems
• Specified for budgetary more than technical
  reasons.

16
Execution Vehicle

• A large undertaking if not specified in the
  System Spec.
• SHOULD be decided with the customer before the
  SRS force it into the System Spec.

17
Cant Go Back

• Once an SRS is approved, changes become very
  expensive
• A specification change, leading to design
  changes, leading to coding changes, leading to
  schedule/budget changes, leading to testing
  changes and finally delivery changes
• Catch specification mistakes in the specification
  phase. How?
• In the System Spec and SRS
• Use reviews

18
The Cross Reference

• Typically the last section of the SRS
• List items from the System Spec.
• Tell which section of the SRS provides coverage.
• Identify the items that contain risk.
• Identify the items that will be designed with
  flexibility.
• Identify the items that define the Critical Path

19
Documentation Requirements

• Might be specified in the System Spec. as a
  customer requirement
• Might be a function of your development approach
  as defined here in the SRS
• Top Level Design Document
• Detailed Design Documents per module
• Test Procedure
• User and Technical Manuals

20
After the SRS

• Critical Design
• Module Level Details
• Structure Charts / Object Charts
• Integration Thread
• Major Module
• Interfaces
• module-to-module
• hardware to software
• drivers to control (up levels of supervision)