1 / 29

Software Requirements Specification (SRS)

Software Requirements Specification (SRS). 0810. Software Requirements Specification (SRS). Complete description of external behavior of software system Partitions universe into two sets All systems satisfying user’s real needs All system that do not satisfy user’s real needs

hisoki
Download Presentation

Software Requirements Specification (SRS)

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. Software Requirements Specification (SRS) 0810

  2. Software Requirements Specification (SRS) • Complete description of external behavior of software system • Partitions universe into two sets • All systems satisfying user’s real needs • All system that do not satisfy user’s real needs • As analysis yields understanding, sections of SRS are written.

  3. Why write an SRS?

  4. SRS Davis, A., Software Requirements • SRS is a complete yet concise description of the entire external interface of the system with its environment including other software, communication ports, hardware, and human users. • Includes: • Behavioral • Non-behavioral

  5. Behavioral Davis, A., Software Requirements • Behavioral: define what the system does; • Inputs • Outputs • transformation of inputs to outputs

  6. Non-behavioral Davis, A., Software Requirements • Non-behavioral: define the attributes of the system as it performs its job • Efficiency • Reliability • Security • Maintainability • Portability • Standards compliance

  7. Attributes of a Well-Written SRS-1 Davis, A., Software Requirements • Correct iff every requirement stated therein accurately represents something required of the system to be built. • Unambiguous iff every requirement stated therein has only one interpretation.

  8. Attributes of a Well-Written SRS-2 Davis, A., Software Requirements • Complete if it possesses the following: • Everything that the software is suppose to do is included in the SRS; • Definitions of responses of software of all realizable classes of input data in all realizable classes of situations is included; • Think of a finite state machine: • I X S => O X S • Must have a complete mapping • All terms are defined and units of measures are provided;

  9. Attributes of a Well-Written SRS-2.1 Davis, A., Software Requirements • Complete if it possesses the following:

  10. Attributes of a Well-Written SRS-2.2 Davis, A., Software Requirements • Violation of completeness is difficult to determine: something is missing. • Prototypes may help. • Example: If party A calls party B and party B is idle, B’s phone shall ring. • (What if it makes all the phones ring …) • If party A calls party B and party B is idle, B’s phone shall ring and no other phone shall ring.

  11. Attributes of a Well-Written SRS-3 • Verifiable (SRS) iff every requirement stated therein is verifiable. • A requirement is verifiable iff there exists some finite, cost-effective process with which a person or machine can check that an actual, as-built software product meets the requirements. • Examples: • “The product shall have an easy-to-use interface.” • “The program shall not enter an infinite loop.” • Avoid words such as “usually”, “generally,” or “often”.

  12. Attributes of a Well-Written SRS-4 • Consistentiff no requirement stated therein is in conflict with other preceding documents and no subset of requirements stated therein conflict.

  13. Attributes of a Well-Written SRS-5 • Traceable if the SRS is written in a manner that facilitates the referencing of each individual requirement stated therein. • Traced iforigin of requirements is clear.

  14. SRS is a resource • Organization is critical: • Why organize it like this? • How do you find things in an SRS? • Emphasize the section 3.2 layout: • View system from different perspectives to capture requirements: functional is weakest of the bunch.

  15. Outline of SRS Document DOCUMENT CONTROL 1. INTRODUCTION 2. GENERAL DESCRIPTION 3. EXTERNAL INTERFACE REQUIREMENTS 4. BEHAVIORAL REQUIREMENTS 5. NON-BEHAVIORAL REQUIREMENTS 6. OTHER REQUIREMENTS 7. APPENDIX A: ANALYSIS MODELS 8. APPENDIX B: ISSUES LIST

  16. Introduction 1.1. PURPOSE AND SCOPE OF PRODUCT 1.2. INTENDED AUDIENCE 1.3. OVERVIEW 1.4. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS 1.4.1. Definitions 1.4.2. Acronyms and Abbreviations 1.5. REFERENCES

  17. General Description 2.1. PRODUCT PERSPECTIVE 2.2. PRODUCT FEATURES 2.3. USER CHARACTERISTICS 2.4. OPERATING ENVIRONMENT 2.5. GENERAL CONSTRAINTS 2.6. ASSUMPTIONS AND DEPENDENCIES

  18. 3. External Interface 3.1. USER INTERFACES 3.2. HARDWARE INTERFACES 3.3. SOFTWARE INTERFACES 3.4. COMMUNICATIONS INTERFACES

  19. 4. BEHAVIORAL REQUIREMENTS 4.1. SAME CLASS OF USER 4.2. RELATED REAL-WORLD OBJECTS 4.3. STIMULUS 4.4. RELATED FEATURES 4.5. FUNCTIONAL

  20. 5. NON-BEHAVIORAL REQUIREMENTS 5.1. PERFORMANCE REQUIREMENTS 5.2. SECURITY 5.3. QUALITATIVE REQUIREMENTS 5.3.1. Availability 5.3.2. Maintainability 5.3.3. Portability 5.3.4. Design and Implementation Constraints

  21. The rest … 6. OTHER REQUIREMENTS 6.1. DATABASE 6.2. OPERATIONS 6.3. SITE ADAPTATION 7. APPENDIX A: ANALYSIS MODELS 8. APPENDIX B: ISSUES LIST

  22. Groupings of requirements • Organize the SRS for understanding • Group requirements related by • Same external stimulus • Same system feature • Same system response • Same real world object • Same class of user • Same class of function

  23. Same External Stimulus • Put all the requirements related to some stimulus together. • Example: Microwave oven: Group by • All requirements related to the door open • All requirements related to the start command • All requirements related to timer inputs • . . .

  24. Same System Feature • Example: Telephone switching system • Group by • All requirements related to local calls • All requirements related to long distance calls • All requirements related to call forwarding • . . .

  25. Same System Response • Example: payroll system • All requirements related to generating pay checks • All requirements related to generating employee reports • All requirements related to generating labor costs • . . .

  26. Same Real World Object • Example: Library system • All requirements related to books • All requirements related to borrowers • All requirements related to publishers • . . .

  27. Same Class of User • Example: ATM • All requirements related to customers • All requirements related to maintenance personnel • All requirements related to repair personnel

  28. Same class of Function • (weakest, corresponds to unguided use of stepwise decomposition) • Example: accounting system: group by • All requirements related to incoming data • All requirements related to user interface • All requirements related to report generation • All requirements related to maintaining data base

  29. Best Way? • Multilevel hierarchy where each level corresponds to a different criteria • X. Detailed Requirements • X.1 Passenger • X.1.1 calling the elevator • X.1.2 Requesting a floor • X.2 maintenance Personnel • X.2.1 inspecting Shaft • . . .

More Related