1. team status
invite a TA, or both
provide a status report:
 Project status – based on phase 1, are you on
track
 Roles – who is point of contact

2. Phase 3
The Software Requirements Specification

3. Customer Points-of-Contention
Assumptions, Constraints, Limits
Function
Documentation – technical, user, and
training manuals
Training
Maintenance / Enhancements
Requirements Changes
Status and Reviews

4. Phase 3
Write PARTS OF an SRS

Drawings
 Integration Thread (also a Drawing)
 Cross Reference

5. The Software Requirements
Specification
After review of the customer’s System
Spec.
After educated analysis
Preliminary design
A technical, software “approach”
Results in permission to detail-design and
code

6. From the customer’s 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

7. Settles these issues:
Software Architecture

Object Oriented?
 Structured?
 Database Oriented (Informational Flow)?
Major Modules
 to 2 or 3 levels of supervision
 low level utilities

8. The “Approach”
Software Development Methodology

Waterfall
 Staged / Evolutionary
Integration Thread – what gets built and
tested first
Prototyping Needs
Delivery Schedule

9. Risk Assessment
Technical Risks
 hardware
 software
 interfaces

build vs. buy
Schedule Risks

budget
 calendar
 personnel – level of expertise required

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

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

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

13. Can’t 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

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

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

17. 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)