1 / 15

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998. cyt. Outline. Benefit of Good SRS. Establish the basis for agreement between the customers and the suppliers on what the software product is to do. Reduce the development effort.

helmut
Download Presentation

IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

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. IEEE Recommended Practice for Software Requirements SpecificationsIEEE Std 830-1998 cyt

  2. Outline

  3. Benefit of Good SRS • Establish the basis for agreement between the customers and the suppliers on what the software product is to do. • Reduce the development effort. • Provide a basis for estimating costs and schedules. • Provide a baseline for validation and verification. • Facilitate transfer. • Serve as a basis for enhancement.

  4. References • ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems. • IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology. • IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans. • IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning. • IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans. • IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software. • IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software. • IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards. • IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation. • IEEE Std 1012a-1998, IEEE Standard for Software Verification and Validation: Content Map to IEEE/EIA 12207.1-1997. • IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions. • IEEE Std 1028-1997, IEEE Standard for Software Reviews. • IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software Configuration Management. • IEEE P1058/D2.1, Draft Standard for Software Project Management Plans, dated 5 August 1998. • IEEE Std 1058a-1998, IEEE Standard for Software Project Management Plans: Content Map to IEEE/EIA 12207.1-1997. • IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes. • IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications.

  5. Background Information of SRS • Nature of the SRS • Environment of the SRS • Characteristics of a good SRS • Joint preparation of the SRS • SRS evolution • Prototyping • Embedding design in the SRS • Embedding project requirements in the SRS

  6. Basis Issues for SRS Writer • Functionality • What is the software supposed to do? • External interfaces • How does the software interact with people, the systemOs hardware, other hardware, and other software? • Performance • What is the speed, availability, response time, recovery time of various software functions, etc.? • Attributes • What are the portability, correctness, maintainability, security, etc. considerations? • Design constraints imposed on an implementation • Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

  7. Characteristics of a good SRS • Correct • Unambiguous • Only one interpretation • Complete • Consistent • Internal consistency: An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict. There are three types of likely conflicts • The specified characteristics of real-world objects may conflict • There may be logical or temporal conflict between two specified actions. • Two or more requirements may describe the same real-world object but use different terms for that object. • Ranked for importance and/or stability • Verifiable • An SRS is verifiable if, and only if, every requirement stated therein is verifiable. • A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. • Modifiable • An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style. • Traceable • An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. • Backward traceability • Forward traceability

  8. Degree of necessity • Essential • Conditional • Optional

  9. Joint Preparation of the SRS • The software development process should begin with supplier and customer agreement on what the completed software must do.

  10. Prototype SRS Outline

  11. Prototype SRS Outline • 1.1Purpose • Delineate the purpose of the SRS • Specify the intended audience for the SRS • 1.2Scope • Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.); • Explain what the software product(s) will, and, if necessary, will not do; • Describe the application of the software being specified, including relevant benefits, objectives, and goals; • Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist. • 1.5Overview • Describe what the rest of the SRS contains; • Explain how the SRS is organized.

  12. Prototype SRS Outline • 2Overall Description • This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements.

  13. Chapter 1 Project Scope ..............................................................................................1 • 1.1 Identification....................................................................................................1 • 1.2 Overview..........................................................................................................1 • 1.3 System Description ..........................................................................................1 • 1.4 Subsystem SAS Description ............................................................................2 • 1.5 Subsystem TAS Description ............................................................................2 • 1.6 Subsystem TES Description ............................................................................3 • 1.7 Subsystem DBS Description............................................................................3 • Chapter 2 Background Information ..........................................................................4 • 2.1 Document Scope ..............................................................................................4 • 2.2 Controlling Document .....................................................................................4 • 2.3 Method .............................................................................................................4 • Chapter 3 System.........................................................................................................5 • 3.1 System Development and Interfaces................................................................5 • 3.1.1 Context Diagram...................................................................................5 • 3.1.2 Interface Requirements .........................................................................6 • 3.1.3 Operational Concepts and Scenarios ....................................................6 • 3.2 Functional Requirements: ..............................................................................10 • 3.3 Non-Functional Requirements:......................................................................11 • 3.3.1 Performance, Safety, Reliability and Maintainability Requirements..11 • 3.3.2 Delivery, Installation, and Environmental Requirements ...................12 • 3.3.3 Design and Implementation Constraints.............................................12 • 3.3.4 Test Requirement and Acceptance Criteria.........................................13 • 3.3.5 Technical Limitations..........................................................................13 • 3.3.6 Risk Management ...............................................................................14 • Chapter 4 Subsystem SAS (SystemAdministrator Subsystem) ............................15 • 4.1 Subsystem Development and Interfaces ........................................................15 • 4.1.1 Context Diagram.................................................................................15 • 4.1.2 Interface Requirements .......................................................................15 • 4.1.3 Operational Concepts and Scenarios ..................................................16 • 4.2 Functional Requirements ...............................................................................28 • 4.2.1 Login Management Module................................................................28 • 4.2.2 Account Management Module............................................................28 • 4.2.3 Test Group Management Module .......................................................28 • 4.2.4 Test Subject Management Module......................................................28 • 4.3 Non-Functional Requirements .......................................................................29 • 4.3.1 Performance, Safety, Reliability and Maintainability Requirements..29 • ii • 4.3.2 Delivery, Installation, and Environmental Requirements ...................29 • 4.3.3 Design and Implementation Constraints.............................................30 • 4.3.4 Test Requirement and Acceptance Criteria.........................................30 • 4.3.5 Technical Limitations..........................................................................31 • 4.3.6 Risk Management ...............................................................................31 • 4.4 The Traceability Matrix of Requirements v.s. Use Cases .............................32 • 4.5 The Traceability Matrix of Requirements v.s. Requirements ........................32

  14. Chapter 5 Subsystem TAS (Test Administrator Subsystem) .................................34 • 5.1 Subsystem Development and Interfaces ........................................................34 • 5.1.1 Context Diagram.................................................................................34 • 5.1.2 Interface Requirements .......................................................................34 • 5.1.3 Operational Concepts and Scenarios ..................................................35 • 5.2 Functional Requirements ...............................................................................49 • 5.2.1 Test Bank Management Module.........................................................49 • 5.2.2 Test Management Module ..................................................................49 • 5.2.3 Test and Grade Querying Module.......................................................50 • 5.3 Non-Functional Requirements .......................................................................50 • 5.3.1 Performance, Safety, Reliability and Maintainability Requirements..50 • 5.3.2 Delivery, Installation, and Environmental Requirements ...................51 • 5.3.3 Design and Implementation Constraints.............................................52 • 5.3.4 Test Requirement and Acceptance Criteria.........................................52 • 5.3.5 Technical Limitations..........................................................................52 • 5.3.6 Risk Management ...............................................................................53 • 5.4 The Tracability Matrix of Requirements v.s. Use Cases ...............................53 • 5.5 The Traceability Matrix of Requirements v.s. Requirements ........................54 • Chapter 6 Subsystem TES (Testing and Exercising Subsystem) ...........................55 • 6.1 Subsystem Development and Interfaces ........................................................55 • 6.1.1 Context Diagram.................................................................................55 • 6.1.2 Interface Requirements .......................................................................55 • 6.1.3 Operational Concepts and Scenarios ..................................................57 • 6.2 Functional Requirements ...............................................................................64 • 6.2.1 Testing Module ...................................................................................64 • 6.2.2 Exercising Module ..............................................................................64 • 6.2.3 Grade Checkng Module ......................................................................65 • 6.2.4 Account Change Module ....................................................................65 • 6.3 Non-Functional Requirements .......................................................................65 • 6.3.1 Performance, Safety, Reliability and Maintainability Requirements..65 • 6.3.2 Delivery, Installation, and Environmental Requirements ...................66 • iii • 6.3.3 Design and Implementation Constraints.............................................67 • 6.3.4 Test Requirement and Acceptance Criteria.........................................67 • 6.3.5 Technical Limitations..........................................................................68 • 6.3.6 Risk Management ...............................................................................68 • 6.4 The Traceability Matrix of Requirements v.s. Use Cases .............................68 • 6.5 The Traceability Matrix of Requirements v.s. Requirements........................69

  15. Chapter 7 Subsystem DBS (Database Subsystem)..................................................74 • 7.1 Subsystem Development and Interfaces ........................................................74 • 7.1.1 Context Diagram.................................................................................74 • 7.1.2 Interface Requirements .......................................................................74 • 7.1.3 Operational Concepts and Scenarios ..................................................75 • 7.2 Functional Requirements ...............................................................................75 • 7.3 Non-Functional Requirements .......................................................................76 • 7.3.1 Performance, Safety, Reliability and Maintainability Requirements..76 • 7.3.2 Delivery, Installation, and Environmental Requirements ...................76 • 7.3.3 Design and Implementation Constraints.............................................77 • 7.3.4 Test Requirement and Acceptance Criteria.........................................77 • 7.3.5 Technical Limitations..........................................................................78 • 7.3.6 Risk Management ...............................................................................78 • Chapter 8 Project Execution Plan .........................................................................79 • 8.1 Online Testing and Exercising System (OTES).............................................79 • 8.1.1 Success Criteria...................................................................................79 • 8.1.2 Project Scope (Work Breakdown Structure).......................................80 • 8.1.3 Establish Estimates of Project Attributes............................................80 • 8.1.4 Project Life Cycle ...............................................................................81 • 8.1.5 Project Schedule..................................................................................82 • 8.1.6 Resources ............................................................................................89 • 8.1.7 Risk Management ...............................................................................91 • 8.1.8 Data Management Plan.......................................................................91 • Glossary ......................................................................................................................93 • References ...................................................................................................................95 • Appendix.....................................................................................................................96

More Related