Requirements specification template

Hello everyone , I meet you again , I'm your friend, Quan Jun . Requirements specification template The requirements specification describes the functions and performance that a software system must provide and the constraints it needs to consider , It is not only the basis of system testing and user documentation , It's also the planning of all subseries 、 The foundation of design and coding . It should describe the expected external behavior and user visual behavior of the system as completely as possible . In addition to design and implementation limitations , The software requirements specification should not include design 、 structure 、 Details of testing or engineering management . 　　1) Use the software requirements specification template : Use the requirements specification template to define a standard template for writing software requirements documents in your organization . This template provides a unified structure for recording functional requirements and various other important information related to requirements . Be careful , The purpose is not to create a new template , Instead, it adopts an existing template that can meet the needs of the project and adapt to the characteristics of the project . Many organizations have adopted IEEE standard 830-1998(IEEE 1998) Describe the requirements specification template . Believe that templates are very useful , But sometimes appropriate changes should be made according to the characteristics of the project .

1 2 3 4 5 6 A introduction Purpose Documentation conventions Expected readers and reading suggestions The range of products reference B A comprehensive description The prospect of the product Product features User classes and characteristics Running environment Design and implementation limitations Assumptions and dependent appendices C External interface requirements appendix User interface appendix Hardware interface software interface communication interface D System features Description and priority incentive / Response sequence functional requirement E Other non functional requirements Performance requirements Security requirements Security needs Software quality attributes Business rules User documentation F Other requirements G The attachment glossary The analysis model List of issues to be identified

　　 surface 2 Requirement specification template

　　a. introduction

　　 The introduction presents an overview of the software requirements specification , This helps readers understand how documents are written and how they are read and interpreted .

　　a . 1 Purpose

　　 Define the product , The software requirements of this product are described in detail in this document , Include revision or release number . If the software requirements specification is only related to a part of the whole system , Then define only the part or subsystem described in the document .

　　a.2 Documentation conventions

　　 Describe the standards or typesetting conventions used when writing documents , Including text style 、 Prompt area or important symbol .

　　a.3 Expected readers and reading suggestions

　　 It lists the different readers of the software requirements specification , For example, developers 、 project manager 、 Marketer 、 user 、 Testers or document Writers . Describes the content of the rest of the document and its organizational structure . Put forward suggestions that are most suitable for each type of reader to read the document .

　　a.4 The range of products

　　 Provides a brief description of the specified software and its purpose , Including interests and objectives . Link software to enterprise goals or business strategies . You can refer to the project view and scope document instead of copying its contents here .

　　a.5 reference

　　 It lists the reference materials or other resources when writing the software requirements specification . This may include user interface style guidance 、 contract 、 standard 、 System requirements specification 、 Use instance documents , Or software requirements specification of related products .

b. A comprehensive description

　　 This section provides an overview of the product being defined and the environment in which it runs 、 Users of the product and known limitations 、 Assumptions and dependencies .

　　b.1 The prospect of the product

　　 Describes the background and origin of the product defined in the software requirements specification . Indicates whether the product is the next member of the product family , Is it the next generation product improved by mature products 、 Whether it is a substitute for existing applications , Or whether it's a new type of 、 Self contained products .

　　b.2 Product features

　　 The main functions of the product are summarized . The details will be in d Description in , So here we just need to summarize . Well organize the functions of the product , Make it easy for every reader to understand .

　　b.3 User classes and characteristics

　　 Identify the different user classes that you think may use the product and describe their relevant features . Some requirements may only be related to specific user classes .

　　b.4 Running environment

　　 Describes the running environment of the software , Including hardware platform 、 Operating system and version , There are other software components or applications that coexist with them .

　　b.5 Design and implementation limitations

　　 Identify issues that affect developers' free choice , And explain why these problems become a limitation .

　　b.6 Assumptions and dependencies

　　 List the hypothetical factors that affect the requirement statement in the specification of software requirements ( Against known factors ). This may include the business components you intend to use or issues related to the development or operating environment . You may think that the product will conform to a special user interface design Convention , But the other S R S Readers may not think so . If these assumptions are incorrect 、 Inconsistent or changed , It will affect the project .

　　 Besides , Determine the dependence of the project on external factors . for example , If you plan to integrate components developed by other projects into the system , Then you have to rely on that project to provide the correct operating components on time . If these dependencies have been recorded in other documents ( For example, project plan ) It's in , Then you can refer to other documents here .

　　c. External interface requirements

　　 Use this section to determine the requirements that can ensure the correct connection between the new product and external components . The association diagram represents the external connection of high-level abstraction . Detailed descriptions of interface data and control components need 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 .

　　c.1 The user interface

　　 Software components that state the required user interface . Describe the logical characteristics of each user interface . And for the details of the user interface , For example, the layout of a specific dialog , It should be written into a separate user interface specification , It cannot be written into the software requirements specification .

　　c.2 Hardware interface

　　 Describe the characteristics of each interface between software and hardware in the system . This description may include supported hardware types 、 The nature of data and control information exchanged between software and hardware and the communication protocol used .

　　c.3 software interface

　　 Describe the product and other external components ( Identified by name and version ) The connection of , Include database 、 operating system 、 Tools 、 Libraries and integrated business components . Define 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 .

　　c.4 communication interface

　　 Describe the requirements related to the communication functions used by the product , Including email 、We b browser 、 Network communication standards or protocols and spreadsheets, etc . Defines the relevant message format . Specify communication security or encryption issues 、 Data transmission rate and synchronous communication mechanism .

　　d. System features

　　d.1 Description and priority

　　 A brief description of the characteristics of the system is put forward, and it is pointed out that the priority of the characteristics is high 、 in , Still low . Or you can include comments on specific priority areas , For example, interests 、 Loss 、 Costs and risks , Its relative priority can be from 1( low ) To 9 ( high ).

　　d.2 incentive / Response sequence

　　 List the input incentives ( User actions 、 Signals or other triggers from external devices ) And the system response sequence that defines this characteristic behavior . These sequences will correspond to the conversation elements associated with the use instance .

　　d.3 functional requirement

　　 List in detail the detailed functional requirements related to this feature . These are the software functions that must be submitted to the user , Users can use the provided features to perform services or use the specified user instances to perform tasks . Describe how the product responds to predictable error conditions or illegal inputs or actions . As described at the beginning of this chapter , You must uniquely identify each requirement .

　　e. Other non functional requirements

　　 This section lists all non functional requirements , Such as the ease of use of the product , How fast is the execution , How reliable , When something unusual happens , How does the system deal with , Rather than external interface requirements and limitations .

　　e.1 Performance requirements

　　 The performance requirements of different application fields are described , And explain their principles to help developers make reasonable design choices . Determine the number of users cooperating with each other or the supported operations 、 Response time and time relationship with real-time system . You can also define capacity requirements here , For example, the need for storage and disk space, or the maximum number of rows of a table stored in a database . Identify performance requirements in as much detail as possible . It may be necessary to state the performance requirements for each functional requirement or feature separately , Put them together instead of all statements .

　　e.2 Security requirements

　　 State in detail the possible losses during the use of the product 、 Requirements related to destruction or hazard . Define the security protection or action that must be taken , And those potentially dangerous actions to prevent . Specify the safety standards that the product must comply with 、 A policy or rule .

　　e.3 Security needs

　　 Detailed statement and system security 、 Integrity or needs related to personal issues , These problems will affect the use of the product and the protection of the data created or used by the product . Define user identification or authorization requirements . Specify the security or confidentiality policies that the product must meet .

　　e.4 Software quality attributes

　　 State in detail other product quality characteristics that are critical to customers or developers . These characteristics must be certain 、 Quantitative and, where possible, verifiable . At a minimum, 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 .

　　e.5 Business rules

　　 List all operating rules related to the product , For example, who can do what in a specific environment . These are not functional requirements in themselves , But they can imply that certain functional requirements enforce these rules .

　　e.6 User documentation

　　 List the user documentation sections that will be released with the software , for example , User's Manual 、 Online help and tutorials . Specify the delivery format or standard of all known user documents .

f. Other requirements

　　 Define requirements that do not appear in other parts of the software requirements specification , For example, international needs or legal needs . You can also add related operations 、 Management and maintenance to improve product installation 、 To configure 、 Startup and shutdown 、 Repair and fault tolerance , And login and monitoring operations .

　　 appendix A ： glossary

　　 Define all necessary terms , So that readers can correctly explain the software requirements specification , Including prefixes and abbreviations . You may want to create a vocabulary across multiple projects for the entire company , And only include the terms in the software requirements specification specific to a single project .

　　 appendix B ： The analysis model

　　 This optional section includes or relates to the location of the relevant analytical model , For example, data flow chart 、 Class diagram 、 State transition diagram or entity - The diagram .

　　 appendix C ： List of issues to be identified

　　 Edit a list of issues to be identified in the software requirements specification , Each of these items is numbered , To facilitate follow-up investigation .

　　2) Indicate the source of the demand ： Indicate the source of requirements in order to make all project risk takers understand why these functional requirements are provided in the requirements specification , Be able to trace the source of each requirement , This may be an example of use or other customer requirements , It may also be a higher-level system requirement 、 Business specifications 、 Government regulations 、 Standards or other external sources .

　　3) Label each requirement ： In order to meet the quality standards of traceability and modifiability of software requirements specification , Each software requirement must be uniquely identified . Make a convention for marking each requirement to provide an independent and identifiable label or mark for each requirement in the requirement specification . This practice should be sound , Allow to increase 、 Delete and modify . Labeled requirements enable requirements to be tracked , Record requirements changes and establish metrics for requirements status and change activities . The requirement identification method has serial number ; Hierarchical coding ; Use ” To be determined ”(to be determined, TBD ) Symbols etc. .

　　4) Record business specifications ： It refers to the operating principles of the product , For example, who can take what action under what circumstances . Write these into a separate part of the requirements specification , Or an independent business specification document . Some business specifications will lead to corresponding functional requirements ; Of course, these requirements should also be traceable to the corresponding business specifications .

　　5) Create a requirement tracking capability matrix ： Establish a matrix to link each requirement with the implementation 、 Test the connection between its design and the code part . Such a requirement tracking capability matrix also links functional requirements with high-level requirements and other related requirements . Build this matrix during development , Don't wait until the end to build .

　　 Here we will also introduce the design stage in the requirements specification , Graphic model used – The data dictionary 、 Data flow diagram 、 Data flow diagram 、 State transition diagram 、 Dialog diagram and class diagram .

　　 The data dictionary ： One defines the meaning of all data elements and structures used in an application 、 type 、 data size 、 Format 、 Unit of measure 、 The shared warehouse of precision and allowable value range . The maintenance of the data dictionary is independent of the software requirements specification , And at any stage of product development and maintenance , Each risk taker can access the data dictionary . It defines the original data elements 、 The complex data elements that make up the structure 、 Duplicate data items 、 Enumeration value of a data item and optional data items .

　　 Data flow diagram ： It is the basic tool of structural system analysis . A data flow diagram determines the transformation process of the system 、 The collection of data or substances manipulated by the system ( Storage ), And the process 、 Storage 、 Data flow or material flow between the external world . The data flow model applies the hierarchical decomposition method to system analysis , This method is suitable for transaction processing systems and other function intensive applications .

　　 Data flow diagram ： Describe the data relationship of the system . Analyzing entity connection diagram is helpful to understand and interact with business or system data composition , And suggest that the product will need to include a database . contrary , When you build the entity connection diagram in the system design stage , It is usually necessary to define the physical structure of the system database .

　　 State transition diagram ： Real time systems and process control applications can exist in a limited state at any given time . When the defined criteria are met , The state will change , For example, under certain conditions , Receive a specific input excitation . Such a system is an example of a finite state machine . Most software systems require some state modeling or analysis , Just like most systems involve the conversion process 、 Data entities and business objects .

　　 Dialogue diagram ： In many applications , The user interface can be seen as a finite state machine . In any case, there is only one dialogue element ( For example, a menu , work area , Line prompt or dialog ) Available for user input . In the active input field , The user takes actions according to him , You can navigate to a limited number of other dialog elements . therefore , Many user interfaces can be modeled using one of the state transition diagrams called dialog diagrams . The dialog diagram depicts the dialog elements in the system and the navigation connections between them , But it doesn't reveal the specific screen design .

　　 Class diagram ： Object oriented software development is superior to structured analysis and design , And it is used in the design of many projects , Thus, object-oriented analysis is produced 、 Design and programming domain . Class diagram is a graphical description of the classes determined by object-oriented analysis and the relationship between them

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/127181.html Link to the original text ：https://javaforall.cn