Phase 3Write PARTS OF an SRS Drawings Integration Thread (also a Drawing) Cross Reference
The Software Requirements SpecificationAfter review of the customer’s SystemSpec.After educated analysisPreliminary designA technical, software “approach”Results in permission to detail-design andcode
From the customer’s perspectiveHow smart people are going to solve theproblem that was stated in the SystemSpec.A “contract”, more or lessIs it doable? Technically On time Under budget
Settles these issues:Software Architecture Object Oriented? Structured? Database Oriented (Informational Flow)?Major Modules to 2 or 3 levels of supervision low level utilities
The “Approach”Software Development Methodology Waterfall Staged / EvolutionaryIntegration Thread – what gets built andtested firstPrototyping NeedsDelivery Schedule
Risk AssessmentTechnical Risks hardware software interfaces build vs. buySchedule Risks budget calendar personnel – level of expertise required
Major Module DescriptionsSupervisory / ExecutiveClasses, Major Objects, and LibrariesBuild vs. BuyInterfaces Module to Module SW to HW Control to DataLow Level Utilities Drivers
Development VehicleDevelopment OS (may have beenspecified in System Spec)Language (may have been specified inSystem Spec)Editors, Syntax Checkers, LibrariesThe Configuration Management andVersion Control SystemsSpecified for budgetary more thantechnical reasons.
Execution VehicleA large undertaking if not specified in theSystem Spec.SHOULD be decided with the customerbefore the SRS – force it into the SystemSpec.
Can’t Go BackOnce an SRS is approved, changesbecome 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 changesCatch specification mistakes in thespecification phase. How? In the System Spec and SRS Use reviews
The Cross ReferenceTypically the last section of the SRSList items from the System Spec.Tell which section of the SRS providescoverage.Identify the items that contain risk.Identify the items that will be designedwith flexibility.Identify the items that define the “CriticalPath”
Documentation RequirementsMight be specified in the System Spec. asa customer requirementMight be a function of your developmentapproach as defined here in the SRS Top Level Design Document Detailed Design Documents per module Test Procedure User and Technical Manuals
After the SRSCritical 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)