Главная страница Случайная страница
КАТЕГОРИИ:
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Begin with an SRS Template
|
|
The first and biggest step to writing an SRS is to select an existing template that you can fine tune for your organizational needs (if you don't have one already). There's not a " standard specification template" for all projects in all industries because the individual requirements that populate an SRS are unique not only from company to company, but also from project to project within any one company. The key is to select an existing template or specification to begin with, and then adapt it to meet your needs.
In recommending using existing templates, I'm not advocating simply copying a template from available resources and using them as your own; instead, I'm suggesting that you use available templates as guides for developing your own. It would be almost impossible to find a specification or specification template that meets your particular project requirements exactly. But using other templates as guides is how it's recommended in the literature on specification development. Look at what someone else has done, and modify it to fit your project requirements. (See the sidebar called " Resources for Model Templates" at the end of this article for resources that provide sample templates and related information.)
Table 1 shows what a basic SRS outline might look like. This example is an adaptation and extension of the IEEE Standard 830-1998:
Table 1 A sample of a basic SRS outline
| 1. Introduction 1.1 Purpose 1.2 Document conventions 1.3 Intended audience 1.4 Additional information 1.5 Contact information/SRS team members 1.6 References 2. Overall Description 2.1 Product perspective 2.2 Product functions 2.3 User classes and characteristics 2.4 Operating environment 2.5 User environment 2.6 Design/implementation constraints 2.7 Assumptions and dependencies 3. External Interface Requirements 3.1 User interfaces 3.2 Hardware interfaces 3.3 Software interfaces 3.4 Communication protocols and interfaces 4. System Features 4.1 System feature A 4.1.1 Description and priority 4.1.2 Action/result 4.1.3 Functional requirements 4.2 System feature B 5. Other Nonfunctional Requirements 5.1 Performance requirements 5.2 Safety requirements 5.3 Security requirements 5.4 Software quality attributes 5.5 Project documentation 5.6 User documentation 6. Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined |
Table 2 shows a more detailed SRS outline, showing the structure of an SRS template as found on Ken Rigby's informative Web site at https://neon.airtime.co.uk/users/wysywig/srs_mt.htm. Reprinted with permission.
Table 2 A sample of a more detailed SRS outline
| 1. Scope | 1.1 Identification.
Identify the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
1.2 System overview.
State the purpose of the system or subsystem to which this document applies.
1.3 Document overview.
Summarize the purpose and contents of this document.
This document comprises six sections:
|
| 2. Referenced Documents | 2.1 Project documents. Identify the project management system documents here. 2.2 Other documents. 2.3 Precedence. 2.4 Source of documents. |
| 3. Requirements | This section shall be divided into paragraphs to specify the Computer Software Configuration Item (CSCI) requirements, that is, those characteristics of the CSCI that are conditions for its acceptance. CSCI requirements are software requirements generated to satisfy the system requirements allocated to this CSCI. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. 3.1 Required states and modes. 3.2 CSCI capability requirements. 3.3 CSCI external interface requirements. 3.4 CSCI internal interface requirements. 3.5 CSCI internal data requirements. 3.6 Adaptation requirements. 3.7 Safety requirements. 3.8 Security and privacy requirements. 3.9 CSCI environment requirements. 3.10 Computer resource requirements. 3.11 Software quality factors. 3.12 Design and implementation constraints. 3.13 Personnel requirements. 3.14 Training-related requirements. 3.15 Logistics-related requirements. 3.16 Other requirements. 3.17 Packaging requirements. 3.18 Precedence and criticality requirements. |
| 4. Qualification Provisions | To be determined. |
| 5. Requirements Traceability | To be determined. |
| 6. Notes | This section contains information of a general or explanatory nature that may be helpful, but is not mandatory. 6.1 Intended use. This Software Requirements specification shall... 6.2 Definitions used in this document. Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the " Documentation standard." 6.3 Abbreviations used in this document. Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the " Documentation Standard." 6.4 Changes from previous issue. Will be " not applicable" for the initial issue. Revisions shall identify the method used to identify changes from the previous issue. |