Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 16

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

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
  

Drawings Integration Thread (also a Drawing) Cross Reference

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 detailcode

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

Settles these issues:


Software Architecture
  

Object Oriented? Structured? Database Oriented (Informational Flow)? to 2 or 3 levels of supervision low level utilities

Major Modules
 

The Approach
Software Development Methodology
 

Waterfall Staged / Evolutionary

Integration Thread what gets built and tested first Prototyping Needs Delivery Schedule

Risk Assessment
Technical Risks
   

hardware software interfaces build vs. buy

Schedule Risks
  

budget calendar personnel level of expertise required

Major Module Descriptions


Supervisory / Executive Classes, Major Objects, and Libraries Build vs. Buy Interfaces
  

Module to Module SW to HW Control to Data Drivers

Low Level Utilities




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

Catch specification mistakes in the specification phase. How?


 

In the System Spec and SRS Use reviews

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

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

After the SRS


Critical Design
    

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)

You might also like