team statusinvite a TA, or bothprovide a status report:   Project status – based on phase 1, are you on    track   Roles...
Phase 3The Software Requirements Specification
Customer Points-of-ContentionAssumptions, Constraints, LimitsFunctionDocumentation – technical, user, andtraining manualsT...
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 analysisPreliminar...
From the customer’s perspectiveHow smart people are going to solve theproblem that was stated in the SystemSpec.A “contrac...
Settles these issues:Software Architecture    Object Oriented?   Structured?   Database Oriented (Informational Flow)?M...
The “Approach”Software Development Methodology    Waterfall   Staged / EvolutionaryIntegration Thread – what gets built ...
Risk AssessmentTechnical Risks   hardware   software   interfaces    build vs. buySchedule Risks    budget   calenda...
Major Module DescriptionsSupervisory / ExecutiveClasses, Major Objects, and LibrariesBuild vs. BuyInterfaces    Module to...
Development VehicleDevelopment OS (may have beenspecified in System Spec)Language (may have been specified inSystem Spec)E...
Execution VehicleA large undertaking if not specified in theSystem Spec.SHOULD be decided with the customerbefore the SRS ...
Can’t Go BackOnce an SRS is approved, changesbecome very expensive:    A specification change, leading to design    chang...
The Cross ReferenceTypically the last section of the SRSList items from the System Spec.Tell which section of the SRS prov...
Documentation RequirementsMight be specified in the System Spec. asa customer requirementMight be a function of your devel...
After the SRSCritical Design   Module Level Details   Structure Charts / Object Charts    Integration Thread   Major M...
10 srs
Upcoming SlideShare
Loading in...5
×

10 srs

161

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
161
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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)
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×