Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

10 srs


Published on

  • Be the first to comment

  • Be the first to like this

10 srs

  1. 1. team statusinvite a TA, or bothprovide a status report: Project status – based on phase 1, are you on track Roles – who is point of contact
  2. 2. Phase 3The Software Requirements Specification
  3. 3. Customer Points-of-ContentionAssumptions, Constraints, LimitsFunctionDocumentation – technical, user, andtraining manualsTrainingMaintenance / EnhancementsRequirements ChangesStatus and Reviews
  4. 4. Phase 3Write PARTS OF an SRS Drawings Integration Thread (also a Drawing) Cross Reference
  5. 5. The Software Requirements SpecificationAfter review of the customer’s SystemSpec.After educated analysisPreliminary designA technical, software “approach”Results in permission to detail-design andcode
  6. 6. 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
  7. 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. 8. The “Approach”Software Development Methodology Waterfall Staged / EvolutionaryIntegration Thread – what gets built andtested firstPrototyping NeedsDelivery Schedule
  9. 9. Risk AssessmentTechnical Risks hardware software interfaces build vs. buySchedule Risks budget calendar personnel – level of expertise required
  10. 10. Major Module DescriptionsSupervisory / ExecutiveClasses, Major Objects, and LibrariesBuild vs. BuyInterfaces Module to Module SW to HW Control to DataLow Level Utilities Drivers
  11. 11. 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.
  12. 12. Execution VehicleA large undertaking if not specified in theSystem Spec.SHOULD be decided with the customerbefore the SRS – force it into the SystemSpec.
  13. 13. 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
  14. 14. 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”
  15. 15. 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
  16. 16. 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)