Your SlideShare is downloading. ×
10 srs
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

10 srs

140
views

Published on


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

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. Phase 3The Software Requirements Specification
  • 3. Customer Points-of-ContentionAssumptions, Constraints, LimitsFunctionDocumentation – technical, user, andtraining manualsTrainingMaintenance / EnhancementsRequirements ChangesStatus and Reviews
  • 4. Phase 3Write PARTS OF an SRS Drawings Integration Thread (also a Drawing) Cross Reference
  • 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. 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. 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. The “Approach”Software Development Methodology Waterfall Staged / EvolutionaryIntegration Thread – what gets built andtested firstPrototyping NeedsDelivery Schedule
  • 9. Risk AssessmentTechnical Risks hardware software interfaces build vs. buySchedule Risks budget calendar personnel – level of expertise required
  • 10. Major Module DescriptionsSupervisory / ExecutiveClasses, Major Objects, and LibrariesBuild vs. BuyInterfaces Module to Module SW to HW Control to DataLow Level Utilities Drivers
  • 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. Execution VehicleA large undertaking if not specified in theSystem Spec.SHOULD be decided with the customerbefore the SRS – force it into the SystemSpec.
  • 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. 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. 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. 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)