1 / 16

Team status

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

aulii
Download Presentation

Team status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    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 customer’s System Spec. After educated analysis Preliminary design A technical, software “approach” Results in permission to detail-design and code

    6. From the customer’s 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. Can’t 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)

More Related