Introduction Provides an overview of software requirements specifications to help readers understand how the document is written and how to read and explain it.
Purpose of writing Define the product, and specify the software requirements of the product in this document, including the revision or release version number. If the software requirement specification is only related to a part of the entire system, then only the part or subsystem described in the document is defined.
Document Conventions Describes the standard or typographic conventions used when writing documents, including body style, prompt area, or important symbols. For example, indicate whether the priority of high-level requirements can be inherited by all its detailed requirements, or whether each requirement statement has its own priority.
Background Describe the name of the software system to be developed; the task proposer, developer, user, and computing center or computer network implementing the software.
Expected readers and reading suggestions List the different readers targeted by the software requirements specification. For example, developers, project managers, marketers, users, testers, or document writers. Describe the content and organizational structure of the rest of the document, and make suggestions that are most suitable for each type of reader to read the document.
Definitions List the definitions of specific terms used in this document, and the original phrases of the first letter of the foreign language.
Product Scope Provide a short description of the specified software and its projects, including benefits and goals. Link software to corporate goals or business strategies. You can refer to the project view and scope documents instead of copying their contents here.
References List the materials or other resources that are referenced when writing software requirements specifications. May include user interface style guidelines, contracts, standards, system requirements specifications, use case documents, or software requirements specifications for related products. Detailed information should be given here, including title name, author, version number, date, Publishers or sources of information to facilitate readers to consult these documents. For example, the project's approved plan or contract or approval of higher authorities; other published documents belonging to the project; documents and materials cited throughout this document, including the software development standards to be used. List the title, document number, publication date, and publishing unit of these documents, and indicate the source from which these documents can be obtained.
Objectives Describe the intention of software development, application objectives, scope of action, and other background materials about software development that should be explained to the reader. Explain the relationship between developing software and other software. If this software product is a stand-alone software, and all content is included, then this is stated. If the defined product is a component of a larger system, the relationship between this product and the other components of the system should be described. For this purpose, a block diagram can be used to illustrate the composition of the system and this product Contact and interface with other parts.
Features of the user List the features of the end user of the software, fully explain the educational level and technical expertise of the operator and maintenance personnel, and the expected usage quota of the software. These are important constraints of software design work.
Assumptions and constraints List the assumptions and constraints of the software development work, such as funding restrictions, development period, etc.
Comprehensive description Provides an overview of the product being defined and the environment in which it operates, the users who use the product, and known limitations, assumptions, and dependencies.
Product Prospects Describe the background and origin of the products defined in the software requirements specification. Indicate whether the product is the next member of the product family, whether it is a next-generation product improved by a mature product, whether it is a replacement for existing applications, or whether it is a new, self-contained product. If the software requirements specification defines an integral part of a large system, then it is necessary to explain how this part of the software is related to the entire system, and to define the interface between the two.
Product features Overview of the main features of the product. The details will be described in subsequent chapters, so here only need to be summarized. For example, it is given as a list. The function of the product is well organized to make it easy for every reader to understand. Graphically represent the main requirement groups and their connections, such as the top-level diagram or class diagram of the data flow diagram.
User classes and characteristics Identify different user classes that may use the product and describe their related characteristics. Some requirements may only be relevant to specific user classes. Distinguish important user categories of the product from those of lesser importance.
Operating environment Describes the operating environment of the software, including the hardware platform, operating system, and version, as well as other software components or applications that coexist with it.
Design and implementation limitations Identify issues that affect developers ’free choice and explain why these issues become a limitation. Possible restrictions include the following: specific technologies, tools, programming languages, and databases that must be used or avoided. Required development specifications or standards (for example, if a customer ’s company is responsible for software maintenance, you must define the design symbolic representation and coding standards used by the subcontractor. Enterprise policies, government regulations, or industry standards. Hardware restrictions, such as timing requirements Or memory limitation. Data conversion format standard.
Assumptions and dependencies List the hypothetical factors (as opposed to known factors) that affect the requirements statement in the software requirements specification. May include intended commercial components or questions about development or operating environment. It may be thought that the product will comply with a special user interface design convention, but another SRS reader may not think so. If these assumptions are incorrect, inconsistent, or changed, the project will be affected. In addition, determine the project's dependence on external factors. For example, if you plan to integrate other project development into the system, you must rely on that project to provide the correct operating components on time. If these dependencies have been documented in other documents (such as project plans), then you can refer to other documents here.
External interface requirements Determine the requirements that can ensure the correct connection of new products with external components. The association diagram represents the high-level abstract external interface. A detailed description of the interface data and control components needs to be written into the data dictionary. If different parts of the product have different external interfaces, then the detailed requirements of these external interfaces should be incorporated into the examples in this part.
User Interface State the software components of the user interface required. Describe the logical characteristics of each user interface. Some features that may be included such as the graphical user interface (GUI) standard or product line style to be adopted; screen layout or solution limitations; buttons, functions or navigation links that will appear on each screen (eg a help button ); Shortcut keys; error message display standards. For user interface details, such as the layout of specific dialog boxes, should be written in a separate user interface specification, not in the software requirements specification.
Hardware interface Describes the characteristics of each interface of software and hardware in the system. This description may include the type of hardware supported, the nature of the data and control information exchanged between the hardware and software, and the communication protocol used.
Software interface describes the connection of the product with other external components (identified by name and version), including databases, operating systems, tools, libraries, and integrated business components. Clarify and describe the purpose of exchanging data or messages between software components. Describe the required services and the nature of internal component communication. Identify the data that will be shared between components. If a special method must be used to implement the data sharing mechanism, such as a global data area in a multitasking operating system, it must be defined as an implementation limitation.
Communication interface Describes the requirements related to the communication functions used by the product, including e-mail, Web browser, network communication standards or protocols, spreadsheets, etc. Define the relevant message format. Specify communication security or encryption issues, data transmission rates, and synchronous communication mechanisms.
System characteristics In the template, functional requirements are organized according to system characteristics, which are the main services provided by the product. This content can be organized by using instances, operating modes, user classes, object classes, functional levels, or a combination of these elements (IEEE1998). All in all, you must choose an organization that makes it easy for readers to understand the intended product. In addition, only use short sentences to describe the name of the feature, such as "4.1 spell check and spell dictionary management".
Description and Priority Provide a brief description of the characteristics of the system and indicate whether the priority of the feature is high, medium, or low. Or it can also include evaluations of specific priority components, such as benefits, losses, costs, or risks, and their relative priority levels can also range from 1 (low) to 9 (high).
Stimulus / Response Sequence Lists input stimuli (user actions, signals from external devices, or other triggers) and system response sequences that define this characteristic behavior. These sequences will correspond to the dialogue elements associated with the use case.
Functional requirements List the detailed functional requirements related to this feature. It is a software function that must be submitted to users so that users can use the provided features to perform services or use specified use cases to perform tasks. Describe how the product responds to predictable error conditions or illegal input or actions. Each requirement must be uniquely identified.
Non-functional requirements List all non-functional requirements, not external interface requirements and restrictions.
Performance requirements Explain the application performance requirements of different application areas and explain their principles to help developers make reasonable design choices. Determine the number of cooperating users or supported operations, response time, and time relationship with the real-time system. You can define capacity requirements here, such as memory and disk space requirements or the maximum number of rows stored in a table in the database. Determine performance requirements in as much detail as possible. It may be necessary to state the performance requirements for each functional requirement or feature separately, rather than grouping them all together. For example, "On a 450 MhzPentium II computer running Microsoft Windows 2000, when the system has at least 50% free resources, 95% of the catalog database queries must be completed within two seconds."
Requirements for safety facilities Describe in detail the requirements related to loss, damage or hazards that may occur during the use of the product. Define the safety protection or actions that must be taken, and the potentially dangerous actions that should be prevented. Identify the safety standards, policies or rules that the product must follow. An example of a safety facility requirement is as follows: "If the pressure of the fuel tank exceeds 95% of the specified maximum pressure, the operation must be terminated within 1 second."
Security requirements Describe in detail the requirements related to system security, integrity, or private issues that will affect the use of the product and the protection of data created or used by the product. Define user identity confirmation or authorization requirements. Identify the security or confidentiality policies that the product must meet, and use "integrity" quality attributes to illustrate these needs. An example of the security requirements of a software system is as follows: "Each user must change his initial login password after logging in for the first time. The initial login password cannot be reused."
Software quality attributes Describe in detail other product quality characteristics that are critical to customers or developers. These characteristics must be determined, quantified, and verifiable when possible. At least the relative emphasis of different attributes should be indicated. For example, ease of use is better than ease of learning, or portability is better than effectiveness.
Business rules List all the operation rules of the product, such as who can perform what kind of operation in a specific environment. These are not themselves functional requirements, but they can imply that certain functional requirements enforce these rules. An example of a business rule is as follows: "Only users with an administrator password can perform a refund operation of ¥ 100.00 or more."
User documentation List the parts of the user documentation that will be released with the software. For example, user manuals, online help and tutorials. Clarify all known user document delivery formats or standards.
Other requirements Define requirements that do not appear in other parts of the software requirements specification, such as internationalization requirements or legal requirements. You can also add operations, management, and maintenance to improve product installation, configuration, startup and shutdown, repair and fault tolerance, and login and monitoring operations. Add a new part related to this system to the template. If there is no need to increase other requirements, omit this part.
Appendix A: Glossary Define all necessary terms so that readers can correctly interpret software requirements specifications, including prefixes and abbreviations. A vocabulary can be created for the entire company that spans multiple projects, and includes only the terms in the software requirements specifications specific to a single project.
Appendix B: Analysis Model This optional section includes the location of related analysis models, such as data flow diagrams, class diagrams, state transition diagrams, or entity relationship diagrams, as well as the location description of these diagrams.
Appendix C: List of issues to be determined Edit a list of issues to be determined in the software requirements specification, each of which is numbered for tracking and investigation.
