Professional Documents
Culture Documents
9 SRS
9 SRS
Project status based on phase 1, are you on track Roles who is point of contact
Phase 3
The Software Requirements Specification
Customer Points-of-Contention Points-ofAssumptions, Constraints, Limits Function Documentation technical, user, and training manuals Training Maintenance / Enhancements Requirements Changes Status and Reviews
Phase 3
Write PARTS OF an SRS
Object Oriented? Structured? Database Oriented (Informational Flow)? to 2 or 3 levels of supervision low level utilities
Major Modules
The Approach
Software Development Methodology
Integration Thread what gets built and tested first Prototyping Needs Delivery Schedule
Risk Assessment
Technical Risks
Schedule Risks
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.
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.
Cant Go Back
Once an SRS is approved, changes become very expensive:
A specification change, leading to design changes, changes, leading to coding changes, leading to schedule/budget changes, leading to testing changes and finally delivery changes
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
Module Level Details Structure Charts / Object Charts Integration Thread Major Module Interfaces
module-tomodule-to-module hardware to software drivers to control (up levels of supervision)