GB/T 9385-1988 Guidelines for the preparation of computer software requirements specifications
Some standard content:
1 Introduction
National Standard of the People's Republic of China
Guide to the Preparation of Computer Software Requirements Specifications
Guide to computer software requirements specifications GB 9385-88
1.1 Purpose and Function
This guide provides a standardized method for software requirements practice. This guide does not advocate the classification of software requirements specifications (hereinafter referred to as SRS) into levels, and avoids defining it as a smaller set of requirements. This guide is applicable to:
Software customers (Customers): to accurately describe what kind of products they want to obtain. Software developers (Suppliers), to accurately understand what kind of products customers need. For any unit and (or) individual who wants to achieve the following goals: a. To propose a standardized SRS outline for development:
Define the specific format and content required by oneself; b.
Generate additional local terms of use, such as SRS quality inspection list or SRS author manual, etc. SRS will accomplish the following goals:
a. Create a basis for establishing a common agreement between the customer and the developer in terms of the software product's completion goals. Make a comprehensive description of the software functions to be implemented to help customers determine whether the specified software meets their requirements, or how to modify the software to meet their requirements.
b. Improve development efficiency. The process of compiling SRS will enable customers to carefully consider all requirements before the design begins, thereby reducing the rework activities of redesign, recoding and retesting afterwards. Careful review of various requirements in SRS can also find some omissions, misunderstandings and inconsistencies in the early stages of development so that they can be corrected in time. c. Provide a basis for cost pricing and preparation of planning schedules. The description of the software product being developed provided by SRS is the basis for cost accounting of computer software products, and can provide a basis for the price and payment of each party. The clear description of the software in SRS helps to estimate the necessary resources and is used as the basis for compiling schedules! d. Provide a benchmark for confirmation and verification. Any organization will prepare their confirmation and verification plans more effectively. As part of the development contract, the SRS can also provide a benchmark that can be measured and followed (however, the opposite is unwritten, that is, any contract related to software cannot be used as an SRS. Because such a document rarely includes a detailed description of requirements and is usually incomplete) 1e. It is easy to migrate. With an SRS, it is easy to migrate the software product to adapt to new users or new models. It is also easy for customers to migrate their software to other departments, and it is also easy for developers to move the software to new customers. f. As a basis for continuous improvement. Since the SRS discusses the software product, rather than the design of the product, the SRS is the basis for the continued improvement of the software product. Although the SRS may also need to change, the original SRS is still a reliable basis for the improvement of the software product.
1.2 Scope
This guide is applicable to the preparation of software requirements specifications. It describes the necessary content and quality of an SRS and provides an SRS outline in Chapter 6.
Approved by the Ministry of Electronics Industry of the People's Republic of China on April 26, 1988, and implemented on December 1, 1988
2 Referenced Standards
GB 566 Computer Software Development Specification
GB9885-88
GB8567 Guidelines for the Preparation of Computer Software Product Development Documents GB/T11457 Software Engineering Terminology
3 Definitions
The terms listed in GB/T11457 and the following definitions apply to this guideline. Contract
It is a legally binding document signed by the customer and the developer. It includes the technical, organizational, cost and schedule requirements of the product.
Customer
Refers to individuals or units who provide funds for product development and usually (but not necessarily) put forward various requirements. The customer and developer in the document may also be members of the same organization. Language is a communication tool with syntax and semantics, including a set of expressions, conventions and rules for transmitting information. Parlitioning is to divide a whole into several parts. Supplier is an individual or group that produces a software product for a customer. In this guide, customers and developers may be members of the same organization. User is an individual or group that runs a system or interacts directly with it. Users and customers are usually not the same people. Background information for writing SRS 4.1 Basic requirements for SRS SRS is a description of a software product, program or a set of programs that are to complete certain functions and performances. There are two basic requirements for the description of SRS: a. It must describe certain functions and performances; b. It must describe these functions and performances in a certain way. 4.2 SRS Environment
It must be recognized that SRS plays a role in the relevant stages specified in the entire software development specification (see GB8566). Because of this, the drafter of SRS must pay special attention not to exceed the scope of this role. This means that the following requirements must be met: a. SRS must correctly define all software requirements, b. Except for special restrictions on the design, SRS generally does not describe any design, verification or project management details. 4.a Characteristics of SRS
4.3.1 Unambiguity
An SRS is unambiguous if and only if it has only one interpretation for each requirement. &. Each feature of the final product is required to be described by a certain term, b. If a term has multiple meanings when used in a particular text, then each meaning of the term is explained and its applicable occasion is indicated.
Requirements are usually written in natural language, and SRS drafters using natural language must pay special attention to eliminating the ambiguity of their requirements. However, a formal requirements description language is used. 4.3.2 Completeness
CB8385-88
An SRS is complete if it meets the following requirements8. Include all meaningful requirements, whether related to function, performance, design constraints, or requirements related to attributes or external interfaces,
b. Define the response to all possible input data, and make provisions for the response to legal and illegal input valuesc. Meet the SRS requirements. If individual chapters are not applicable, the chapter number should be retained in the SRS:d. Fill in all illustrations, tables, graphic symbols and references in the SRS, and define all terms and units of measurement. 4.3.2.1 Provisions on the use of the word "to be determined"Any SRS that uses "to be determined" is incomplete. . If the word "pending" is used, the following procedures shall be followed: (1) describe the conditions that gave rise to the word "pending" so that the problem can be solved; (2) describe what must happen to remove the word "pending". b. Any SRS project document that contains the word "pending" should (1) identify the version number associated with this specific document or state its specific release number; (2) refuse to commit to any SRS section that still has the word "pending". 4.8.3 Verifiability
An SRS is verifiable if and only if every requirement described in the SRS is verifiable. A requirement is verifiable if and only if a finite process with a reasonable cost-effectiveness can be used by a human or machine to check whether the software product meets the requirement.
4.8.4 Consistency
An SRS is consistent if and only if the descriptions of the individual requirements in the SRS are not contradictory. 1.3.5 Modifiability
If the structure and style of an SRS are easy to implement, complete, and consistent when the requirements need to be changed, then the SRS is modifiable. Modifiability requires that the SRS meet the following conditions: it has an orderly and easy-to-use content organization, a table of contents, an index, and a clear cross-reference table, and no redundancy. That is, the same requirement cannot appear multiple times in the SRS. (1) Redundancy itself is not an error, but it is prone to errors. Redundancy can increase the readability of the SRS, but it is easy to cause problems when a redundant document is updated. For example: suppose a clear requirement is listed in detail in two places. Later, it is discovered that this requirement needs to be changed. If only one place is modified, the SRS will become inconsistent. (2) Regardless of whether redundancy is required, the SRS must contain a detailed cross-reference table so that the SRS has modifiability. 4.a.6 Traceability
The SRS is traceable if the source of each requirement is clear and each requirement can be easily referenced when further documentation is generated and changed. Two types of tracing are recommended: Backward tracing (tracing back to a previous stage of development). Trace back to each requirement in the previous document or the previous document.
D. Forward tracing (i.e., tracing back to all documents derived from the SRS). Trace back to each requirement in the SRS with a unique name and signature number.
When a requirement in the SRS is derived from an assignment or designation of another requirement, both forward and backward tracing should be provided. For example,
(1) allocate the response time of a database operation to the total user response time requirement; (2) identify the report format required with a certain function and user interface; (3) support a legal or administrative software product (e.g., calculating taxes). In this case, indicate the specific legal or administrative documents supported by the software. GB 9385-88
When the software product enters the operation and maintenance phase, the traceability of the SRS becomes particularly important. When the coding and design documents are modified, it is important to find out all the requirements affected by these modifications. 4.3.7 Usability in the operation and maintenance phase The SRS must meet the needs of the operation and maintenance phase, including the final replacement of the software. Maintenance is often performed by people who have no connection with the original development. Local changes (corrections) can be achieved with the help of good code comments. For larger changes, design and requirement documents are essential, which implies two functions: (1) As pointed out in 4.3.5, the SRS must be modifiable; (2) The SRS must include a record that records the specific provisions of each component of the application. For example: their urgency (e.g. failure may endanger the whole or cause great financial and social losses); they are only related to temporary needs (e.g. support a display that can be immediately restored to its original state); their origin (e.g. a function is copied from a complete copy of an existing software product). b. It is required to clearly state the origin and purpose of the function in the SRS, because if the origin of the function and the purpose of introducing the function are not clear, it is usually impossible to complete the maintenance of the software well. 4.4 SRS Compiler
The software development process starts with the agreement between the developer and the customer on what kind of software to develop. This agreement should be in the form of SRS and should be jointly drafted by both parties. This is because: the customer usually knows little about the software design and development process and cannot write a usable SRS, b. The developer usually knows little about the customer's problems and intentions, so it is impossible to write a satisfactory system requirement. 4.5 Improvement of SRS
During the development of software products, it is impossible to describe some details in detail at the beginning of the project. During the development process, problems such as defects, shortcomings and errors in the SRS may be discovered, so the SRS may need to be improved. In the improvement of SRS, the following points should be noted: 4.5.1 Although it can be foreseen that revised versions are inevitable after development, the requirements must still be described as completely and clearly as possible. 4.5.2-When changes in the project are initially identified, a formal change procedure should be introduced to identify, control, track and report project changes. Approved changes in requirements are compiled into the SRS in the following way: a. Provide correct and complete review records after various changes; b. Allow review of the current and replaced parts of the SRS. 4.6 Tools for compiling SRS
The most obvious way to compile SRS is to describe it in natural language. Although natural language is rich and colorful, it is not easy to be precise, so it is better to use a formal method.
4.6.1 Formal Description Method
Whether to use formal methods in SRS depends on the following factors: a. program size and complexity, b. whether the customer contract requires the use of formal methods, c. whether SRS is a contract tool or an internal document, d. whether the SRS document becomes the basis of the design document, and e. computer equipment that supports this method. 4.6.2 Production Tools
There are many production tools in software product production. For example, a computer word processor is a very useful production aid. An SRS usually has several authors. It may go through more than ten versions and reorganize the content many times. Therefore, production tools are necessary. 4.6.3 Expression tools
There are many words in SRS:, especially many nouns and verbs, which are specifically related to the entities and many activities of the system. Therefore, the expression of SRS requires some T counties, such as:
GB 9385-88
It can verify that entities become activities, and the same name is used everywhere in the SRS. b. It can identify the description position of a particular entity or action in the specification. In addition, several formal methods can be used to allow automatic processing of SRS content, as long as certain restrictions are made. Use some tables or diagrams to show requirements. Automatically check the requirements of SRS using a detailed hierarchical system, where each layer is complete in itself, but can also be expanded to a component of the next layer, or the upper layer. Automatically check that SRS has some or all of the characteristics described in Section 4.3. 5 Software requirements
Each software requirement in SRS is a statement that requires certain basic functions and performances of the software product to be developed. 5.1 Methods for expressing software requirements
Software requirements can be expressed in several ways:. b. Use representative examples; e. Use a standardized model.
5.1.1 Input and Output Description
It is very effective to describe the required characteristics of a software product using a sequence of inputs and outputs. 5.1.1.1 Approach
Depending on the nature of the software being described, there are at least three different approaches: group. Some software products (such as reporting systems) require that the output be described. In general, systems that focus on outputs operate primarily on data files. User input is usually used to provide control information and activate the processing of data files. b. Some software products need to focus on input and output characteristics. Systems that focus on inputs and outputs operate primarily on current inputs and are required to generate outputs that match the inputs (similar to data conversion routines or a mathematical function package). c. Some systems (such as process control systems) require that their states be remembered. They can respond based on the current input and the previous input. In other words, it behaves like a finite state machine. In this case, we need to focus on both the input/output pairs and the order of these input/output pairs.
5.1.1.2 Difficulties
Most software products may receive an infinite sequence as input. Therefore, in order to fully describe the characteristics of the product through the input-output sequence, the SRS is required to include an infinitely long input and required output sequence. However, it is impossible to fully describe all the required characteristics of the software in this way.
5.1.2 Typical Examples
One option is to use typical examples to illustrate the required characteristics. For example, suppose a system responds with "1" when receiving "". Obviously, it is impossible to list all input and output sequences. However, using typical sequences can clearly understand the characteristics of the system. The following is a typical example of a set of four dialogues that describe the characteristics of the system. 0101
010101010101
010101
These dialogues only provide the relationship between the required inputs and outputs, but cannot fully describe the characteristics of the system. 5.1.a Models
Another way to express requirements is to use models, which is an accurate and effective way to express complex requirements. At least three general models can be proposed for use: mathematical, functional, and timing. It should be noted that the application scenarios of various models are different, refer to 5.1.3.5. 5.1.3.1 Mathematical model
GB9385-86
Mathematical model is a model that uses mathematical relationships to describe the characteristics of software. Mathematical models are particularly useful for certain special application fields. For example, navigation, linear programming, econometrics, signal processing and meteorological analysis. The typical example discussed in 5.1.2 can be described as follows using mathematical models: (01) *c
Here, "," indicates that the string in brackets can be repeated one or more times. 5.1.8.2 Functional model
A functional model is a model that provides a mapping from input to output. Like a finite state machine or Pe1i network, these functional models can help identify and define various characteristics of the software, or can represent the operations to be performed by the system. For the example described above using a mathematical model. It can be described by a functional model in the form of a finite state machine as shown in Figure 1. The arrow entering the figure indicates the start state. The double-line box indicates the receiving state. The meaning of the symbol ×/ on each line is: x represents the input accepted, and y represents the output generated.
5.1.8.8 Timing Models
A timing model is a model that adds time constraints. This type of model is particularly useful for expressing the formality and detail of software features, especially for real-time systems or systems that take human factors into account. A timing model can add the following constraints to the model in Figure 1: a. Activation factor 0 will occur within 30% of entering state 1; b. Response 1 will occur within 29 of entering state S2. 5.1.3.4 Other Models
In addition to the models mentioned above, there are some particularly useful models for some special applications. For example, compiler specifications can use attribute grammars, and payroll systems can use tables. It should be noted that the use of formal requirements languages for SRSs usually implies the use of special models.
5.1. 3, 5 Warnings
Whichever type of model is used, it must be strictly defined in the SRS or in a document referenced by the SRS. This definition should specify: the required range of parameters in the model, the limits of use, the accuracy of the results, the load capacity! The required execution time: f, the response to default or failure. Care must be taken to keep the model definition within the definition of the requirements. Whenever an SRS uses a model: it means that the model provides a very effective and accurate way to describe the requirements; it does not mean that the implementation of the software product must be based on this model. b. A model is effective for interpreting the requirements written in the document, but it may not be the most appropriate for the actual software implementation. 5.2 Annotation of Software Requirements Not all requirements for a software product are equally important. Some requirements may be essential, such as for life-critical applications. Others may be less important. Each requirement in the SRS must be annotated to distinguish its level of importance. Annotating requirements in this way can: a. help customers give careful consideration to each requirement, often clarifying hidden assumptions in the requirements, b. help developers make correct design decisions and make appropriate decisions for different parts of the software product. 5.2.1 Stability
One way to annotate requirements is to use a stability scale. When a requirement is described and does not change during the expected lifetime of the software, it can be considered stable, otherwise it can be considered volatile. 5.2.2 Levels of Necessity
Another way to annotate requirements is to classify requirements into must-guarantee, desired, and optional levels. Must-guarantee means that the software must comply with these requirements, otherwise the software cannot be accepted. b. Desired means that these requirements will improve the functionality of the software product, but it is acceptable if they are not included. c. Optional means that developers have the opportunity to provide something beyond the goals specified in the SRS. 5.2.3 Notes
Before annotating requirements, you must thoroughly understand the substantive meaning of such annotations. 5.3 Common pitfalls in expressing requirements Basic points of SRS: It must describe the results obtained by the software, not the means to obtain these results. The basic issues that the person writing the requirements must describe are: 1. Functionality - what the designed software is to do, 2. Performance - refers to the speed of the software function during execution, usability, response time, recovery time of various software functions, throughput, accuracy, frequency, etc., 3. Design constraints imposed on the implementation - the required standards in terms of performance, implementation language, database integrity, resource limitations, operating environment, etc. 4. 5. Attributes - considerations of portability, correctness, maintainability and security, etc. 6. External interfaces - relationships with people, hardware, other software and other hardware. The person writing the requirements should avoid writing the design or project requirements into the SRS, and should make a clear distinction between stating the requirements design constraints and planning the design.
5.3.1 Design Embedded in the SRS
Embedding the design description in the SRS overly constrains the software design and artificially places potentially dangerous requirements in the SRSGE 9885-88
5.8.1.1 The SRS must describe what functions are performed on what data, for whom, where, and with what results. The SRS should focus on the service objectives to be achieved. The following design items are usually not specified: Divide the software into modules
b. Assign functions to each module
c. Describe the information flow or control flow between modules and select data structures.
5.3.1.2 It is never practical to completely isolate the design from the SRS. Careful considerations of security and confidentiality may add requirements that directly reflect design constraints. For example:
Keep some functions in a number of discrete modules; allow limited communication between certain areas of the program, b.
c. Calculate the checksum of the critical value.
5.3,1. It should be considered that if a high-level design is selected for the software, it may require a lot of resources (may account for more than 10% to 20% of the total product development cost). There are two options: b. Ignore the warnings of this guide and describe the design in the SRS. This means that the wearer will describe a potentially inappropriate design as a requirement (because, if a good design is not spent enough time), or spend too much time on the requirements stage (because the entire design analysis must be completed before the SRS is completed). b. Use the advice in Section 5.1.3 of this guide to describe the requirements with a model design. This model design is only used to assist in describing the requirements, but not to make it an actual design.
5.3.2 Embed some project requirements in the SRS. The SRS should describe a software product, not the process of producing the software product. Project requirements express the understanding between the client and the developer on the compliance issues in software production (and therefore should not be included in the SRS). For example:
cost,
delivery schedule,
report processing:
software development method,
quality assurance:
confirmation and verification standards!
acceptance process.
Project requirements are described in a separate document. Only requirements for the software product itself are provided in the SRS. SRS Outline
This chapter can serve as an outline for an SRS if it discusses each basic part of the SRS. Table 1 gives the outline of the outline, and Tables 2 to 5 give the specific requirements content of Chapter 3 in the outline. Each developer and client should write their own SRS according to the actual situation described and the relevant provisions of this guide.
1.1 Purpose
1.2 Explanations
1,3 Definitions, abbreviations, acronyms
1.4 References
2 Project Overview
2.1 Product Description
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Basis
. Specific Requirements
GB 98858B
Table 1 SRS Outline
(See the organizational form of specific requirements in Section 6.3.2 of this guide) Appendix
6.1 Foreword (Chapter 1 of SRS)
This section provides an overview of the entire SRS,
6,1.1 Purpose (Section 1.1 of SRS)
This section includes the following content!
Describe the purpose of the actual SRS
Describe the intended readers of the SRS.
6.1.2 Scope (1.2)
Use a name to identify the software product being produced. For example: ××× database system, report generation program, etc., a.
Describe what the software product will do, and if necessary, what the software product will not do, b.
Describe the application of the software being described. It should: (1》Describe all relevant interests, objectives, and ultimate goals as accurately as possible. (2) If a higher-level description exists, it should be consistent with similar statements in the higher-level description (for example, the system requirements specification).
6.1.3 Definitions, abbreviations, and abbreviations (Clause 1.3 of SRS) This clause must provide definitions of all required terms, abbreviations, and abbreviations to facilitate proper interpretation of the SRS. This information can be provided in the appendix to the SRS. Other documents can also be referenced. 6.1.4 References (SRS 1.4 of this clause) This clause should include:
A complete list of documents referenced in various places in the SRS, such as approved plans and tasks, approval documents from higher authorities, contracts, etc., and
List other references, such as other published documents and major documents related to this project. Each document. The document should have b.
Title, index number or file number, release or publication date and publishing unit, and detailed description of the source from which the referenced document can be obtained. This information can be provided by citing an appendix or other documents. c
6.2 Project Overview (Chapter 2 of SRS)
GB 9386--88
This chapter describes the general factors that affect the product and its requirements. This chapter does not explain specific requirements, but only makes the requirements easier to understand. 6.2.1 Product Description (Article 2.1 of SRS)
This article describes a product in terms of other related products or projects. . If this product is independent and all its contents are self-contained, it should be stated here; b. If the product defined by the SRS is a component of a larger system or project, then this article should include the following content:
(1) Summarize the functions of each component of this larger system or project and explain its interface: (2) Point out the main external interface of the software product. Here, a detailed description of the interface is not required, and the detailed description is placed in other chapters of the SRS#
(3) Describe the computer hardware and external devices used. This is just a general description. In the description of this article, a block diagram is used to express a 6.2.2 Product Functionality (Section 2.2 of the SRS)
This section provides a summary of the software functionality to be accomplished. For example, for an accounting program, the SRS could describe customer account maintenance, customer financial statements, and invoice generation without describing the details of the large set of functions required. Sometimes, if a higher-level specification exists, the functional summary can be taken directly from it. This higher-level specification assigns specific functions to the software product. For clarity, please note 8: One way to compile a functional summary is to make a functional table so that the customer or someone reading the document for the first time can understand it. b. It is also helpful to use a block diagram to show the different functions and their relationships. However, it should be remembered that such a diagram is not required for product design, but is only an effective explanatory tool. This clause is not intended to state specific requirements, but to provide a rationale for certain requirements that are later described in the Specific Requirements section of the SRS.
6.2.3 User Characteristics (Clause 2.3 of the SRS)
This clause describes the general characteristics of the end users of the product that affect the specific requirements. Many people are associated with the system during the operation and maintenance phases of the software life cycle. Among these people are users, operators, maintainers, and system staff. Certain characteristics of these people, such as education level, experience, skills, and expertise, are important constraints imposed on the system's operating environment.
If most users of the system are occasional users, then the system is required to include hints on how to perform basic functions, rather than assuming that the user has learned these details from past meetings or from reading the user guide. The content of this clause should not be used to state specific requirements or impose specific design constraints. This clause should provide a rationale for the description of certain specific requirements or design constraints in the Specific Requirements section of the SRS. 6.2.4 General Constraints (Clause 2.4 of the SRS)
This clause provides a general description of other items that limit the developer's choices when designing the system. These items will limit the options available to developers when designing the system. These include,
management policy,
b. hardware limitations,
e. interfaces with other applications,
d. parallel operation,
audit function:
control function;
high-level language required,
h. communication protocol;
i. critical points of application;
"security and confidentiality considerations.
GB 93B5—88
This clause does not state specific requirements or specific design constraints: it provides a rationale for why certain specific requirements and design constraints are determined in the Specific Requirements chapter of the SRS.
6.2.5 Assumptions and Basis (Clause 2.5 of the SRS) This clause lists each factor that affects the requirements stated in the SRS. These factors are not design constraints for the software, but their changes may affect the requirements of the SRS. For example, suppose a specific operating system is used on the hardware specified by the software product. However, in fact, this operating system is not available. Therefore, the SRS needs to be changed accordingly. 6.8 Specific Requirements (Chapter 3 of the SRS) bzxZ.net
This chapter should include all the details that the software developers need to establish the design. This is the largest and most important part of the SRS. : According to the criteria specified in Chapter 4 of this guide (such as verifiability, unambiguity, etc.), describe each requirement detail in detail.
b. In the discussion of the introduction, project overview, and appendix of the SRS, provide background for cross-references to any specific requirement.
c. The method of categorizing specific requirements is as follows:
(1) functional requirements,
(2) performance requirements,
(3) design constraints,
(4) attributes;
(5) external interface requirements.
Two points to note in this chapter are:
8. Organize in a logical and readable way, b. Describe each requirement in detail so that the goal to be achieved by the requirement can be objectively verified using the specified method. B.3.1 Contents of specific requirements
6.8.1.1 Functional requirements
This clause describes how the input of the software product is transformed into output. That is, the basic actions that the software must complete. For each type of function or sometimes for each function, it is necessary to describe its input, processing and output requirements in detail. This usually consists of four parts:
This part describes the goals to be achieved by the function, the methods and technologies used, and should also clearly explain the origin and background of the functional intent. b.Input This section should include: (1) Detailed description of all input data for the function, such as: input source, number, unit of measure, time setting, valid input range (including precision and tolerance), (2) Requirements for operator control details. These include the name, description of operator activities, console or operator location. For example: when printing checks, the operator is required to make format adjustments; (3) References to the interface description or interface control document. The above defines the input data, intermediate parameters, and all operations to obtain the expected output results. It includes the following descriptions (1) Input data validity check, (2) The sequence of operations, including the time setting of events: (3) Response to abnormal conditions, such as overflow, communication failure, error handling, etc. (4) Parameters affected by the operation: (5) Requirements for degraded operation; GB9385-88 (6) Any method used to transform system input into corresponding output (equations, mathematical algorithms, logical operations, etc.). (7) Validity check of output data.
d. Output.
This section should include:
(1) Detailed description of all output data of the function, such as: output destination, quantity, unit of measurement, time relationship, valid output range (including precision and tolerance), handling of illegal values, error message: (2) References to relevant interface descriptions or interface control documents. In addition, for systems that focus on input and output behavior, the SRS should specify all meaningful input and output pairs and their sequences. This sequence is required when a system is required to remember its state so that it can respond based on the current input and previous states. In other words, this situation is like a finite state machine. 6.8.1.2 Performance requirements
Overall, this clause should specify the static or dynamic numerical requirements of the software or the interaction between people and software. . Static numerical requirements may include,
(1) Number of terminals supported;
(2) Number of users supported for concurrent operations;
(3) Number of files and records processed;
(4) Size of tables and files.
b. Dynamic numerical requirements may include: Number of transactions and tasks to be processed, and the total amount of data to be processed in a certain period of time under normal and peak operating conditions. All of these requirements must be stated in measurable terms. For example, 95% of transactions must be processed in less than 1 second, otherwise the operator will not wait for the completion of the transaction. 6.3.1.3 Design constraints
Design constraints are affected by other standards, hardware limitations, etc. 6.3.1.3.1 Other standard constraints
This item will specify requirements derived from existing standards or regulations. For example:
b. Data naming:
Financial processing;
d. Audit trail, etc.
6.3.1.8.2 Hardware Constraints
This item includes the requirements for the software to run under various hardware constraints. For example, it should include: characteristics of the hardware configuration (number of interfaces, instruction set, etc.) B
b. The capacity of internal and auxiliary storage. 6.8.1.4 Performance
There are several attributes in the requirements for software, several of which are mentioned below (note: these should never be understood as a complete list).
6.8.1.4.1 Availability
Some factors, such as checkpoints, recovery and restart, can be specified to ensure that the entire system has a certain level of availability. 6.8.1.4.2 Security
This refers to the elements that protect the software to prevent various illegal access, use, modification, destruction or disclosure. Specific requirements in this area must include:
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.