160 likes | 292 Views
Phase 3. The Software Requirements Specification. Customer Points-of-Contention. Assumptions, Constraints, LimitsFunctionDocumentation technical, user, and training manualsTrainingMaintenance / EnhancementsRequirements ChangesStatus and Reviews. Phase 3. Write PARTS OF an SRSDrawingsIntegr
E N D
1. 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
2. Phase 3 The Software Requirements Specification
3. Customer Points-of-Contention Assumptions, Constraints, Limits
Function
Documentation technical, user, and training manuals
Training
Maintenance / Enhancements
Requirements Changes
Status and Reviews
4. Phase 3 Write PARTS OF an SRS
Drawings
Integration Thread (also a Drawing)
Cross Reference
5. 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 code
6. 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
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 / Evolutionary
Integration Thread what gets built and tested first
Prototyping Needs
Delivery Schedule
9. Risk Assessment Technical Risks
hardware
software
interfaces
build vs. buy
Schedule Risks
budget
calendar
personnel level of expertise required
10. Major Module Descriptions Supervisory / Executive
Classes, Major Objects, and Libraries
Build vs. Buy
Interfaces
Module to Module
SW to HW
Control to Data
Low Level Utilities
Drivers
11. 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.
12. 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.
13. Cant Go Back Once an SRS is approved, changes become 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 changes
Catch specification mistakes in the specification phase. How?
In the System Spec and SRS
Use reviews
14. 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
15. 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
16. After the SRS Critical 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)