Component requirement analysis description Template

Software Requirement Specification template revision history
Version description preparation approval date
1.1 write SEPG for the first time

 
Contents
1. Introduction 1
1.1. Background 1
1.2. References 1
1.3. assumptions and constraints 1
1.4. User features 1
2. Function Requirement 1
2.1. system range 1
2.2. System Architecture (System with L2 architecture can be tailored to this section) 1
2.3. Overall system process 2
2.4. Demand Analysis 2
2.4.1. xxxxxxx (function requirement name) 2
2.4.1.1. Function Description 2
2.4.1.2. Business modeling 2
2.4.1.3. use case description 3
2.4.1.4. User Interface 5
2.4.2. xxxxxxx (function requirement name) 5
3. Non-functional requirements 5
3.1. Performance Requirement 5
3.1.1. Precision 5
3.1.2. Time Feature requirements 6
3.1.3. Requirements for output of lost persons 6
3.2. Data management capability requirements 6
3.3. security and confidentiality requirements 6
3.4. Flexibility requirements 6
3.5. Other Special requirements 6
4. runtime environment provision 6
4.1. device 6
4.2. Support Software 7
4.3. Interface 7
4.4. Control 7
5. Demand Tracking 7
6. Approval Form 7



1. Introduction
1.1. Background
Note:
A. Name of the software system to be developed;
B. the submitter, developer, user, and computing center or computer network that implements the software;
C. Basic relationships between the software system and other systems or institutions.
1.2. References
List the materials referenced and referenced in this Manual, such:
A. approved plans and tasks or contracts and approvals from higher authorities for this project;
B. Other published documents of the project;
C. Documents and materials referenced everywhere in this document, including the software development standards to be used. Lists the titles, document numbers, publication dates, and publishing units of these documents, indicating the source of these documents.
1.3. [Optional] assumptions and constraints
List the assumptions and constraints for the software development work, such as funding restrictions, development periods, equipment conditions, user information preparation and exchange issues.
1.4. User features [Optional]
Describe the features of end users of the software, fully describe the educational level and technical expertise of operators and maintenance personnel, and the expected frequency of use of the software. These are important constraints of software design.
2. Functional Requirements
2.1. System Scope
Clearly and briefly describe users' high-level system and product objectives, such as system development intent, application goals, scope of application, and other related background materials.
If the defined product is an integral part of a larger system, the relationship between the product and other components of the system should be described, to this end, you can use a block diagram to describe the composition of the system and the contact and interface between the product and other parts.
2.2. System Architecture (System with L2 architecture can be tailored to this section) [Optional]
Describe the overall architecture of the system by combining images with texts.
The overall architecture of the system should be provided as follows:

The overall system architecture is described as follows:

2.3. Overall system process
The overall process of the system is illustrated by combining images with texts.
Figure 1 shows the overall flowchart of the planning contract management system.

Figure 1
2.4. Demand Analysis
The purpose of requirement analysis is to acquire or describe every functional requirement in the system requirement and determine what the system can do through analysis? Who will use this system?
· Create a use case model: Discover roles and use cases, and determine the relationships between roles, use cases, and the relationships between roles and use cases.
· Description case: Specification Description of how the role interacts with the system.
2.4.1. xxxxxxx (function requirement name)
2.4.1.1. Function Description
Function No:
Functional requirements: Describe functional requirements from the perspective of user business.
2.4.1.2. Business Modeling
From a visual perspective -- use case diagram -- describe functional requirements
Figure 2 shows the use case diagram for contract editing of the integrated plan management system.

Figure 2
2.4.1.3. use case description
Describes the type of interaction between a role and the system in each use case in text.
1. xxxxxx (Use Case name)
Description Object Description
Unique Identifier of the use case
Brief description of the use case
List of participants related to the use case, and characteristics of the participants
Frequency the frequency of participants accessing this case
The status is generally divided into: in progress, waiting for review, passed review, or not passed Review
A list of prerequisites. If conditions are included in the List, these conditions must be met before accessing the use case.
A list of conditions for the backend condition. If conditions are included, these conditions are met after the use case is completed successfully.
Extended use case the extended use case (if any)
Included use cases the use cases contained in this use case (if any)
The main logical path followed by the participants in the basic operation process in the use case, that is, the work mode of the use case when all work is normal.
Optional path of the operation procedure when the working method is changed, an exception occurs, or an error occurs
Modified by: Date: reason:
If the problem exists, it is the problem related to the development of this case or the list of operation projects.

The following section describes the use cases added to the contract editing function in the integrated plan management system:
Description Object Description
Identifier ipms0101
Add a contract record
Participant contract Editor-familiar with contract management business
Frequency
Status passed Review
Preconditions 1. The participant has the contract-added permissions 2. The participant has selected the corresponding plan record 3. The total current plan investment is greater than or equal to sum (the contract price has been signed under the plan)
Post condition 1. More contract discipline in the database 2. Original contract scan cases can be executed 3. executable contract payment add case 4. executable contract modification and contract deletion Cases
No extended use cases
None of the included Use Cases
For the basic operation procedure, see the contract addition procedure in Figure 3.
Optional operation procedure when an exception is found when the user confirms the increase in the contract, the system prompts that the contract is invalid.
Modified by: Date: reason:
Question 1. Specific contract code conventions 2. Specific designs of contract types, sources of funds, and entrusted party dictionary tables


Figure 3 Contract addition activity process
2. XXXXX (Use Case name)
......
2.4.1.4. User Interface
The overview description function corresponds to the user interface style. Projects that use the prototype life cycle can also copy the prototype interface.
2.4.2. xxxxxxx (function requirement name)
......
3. Non-functional requirements
3.1. Performance Requirements
3.1.1. accuracy [Optional]
The requirements on the input and output data accuracy of the software may include the precision during transmission.
3.1.2. Time Feature requirements
The requirements for the Time Characteristics of the software, such as the response time, update processing time, data conversion, and interface update transfer time.
3.1.3. Input/Output requirements
Describe the input and output data types, and describe the media, format, value range, and accuracy one by one. The data output of the software and the control output that must be indicated are explained and used as an example, including the hard copy report (normal result output, status output, and abnormal output) and the description of the graphic or display report.
3.2. Data management capability requirements [Optional]
Describe the number of volumes and records to be managed, the size and size of tables and volumes, and estimate the storage requirements of data and its components based on foreseeable growth.
3.3. security and confidentiality requirements
Users require the system's fault handling capabilities, handling methods, system recovery after the fault, and data recovery to prevent the system from illegal intrusion, modification, and loss of confidential data.
3.4. Flexibility requirements [Optional]
Describes the flexibility required for the software, that is, the ability of the software to adapt to these changes when the demand changes, such:
A. Changes in operation methods;
B. Changes in the runtime environment;
C. Changes in interfaces with other software;
D. Changes in accuracy and validity period;
E. Planned changes or improvements.
Specific designs for the purpose of providing such flexibility should be noted.
3.5. Other Special requirements [Optional]
For example, users' organization requirements for ease of use and special requirements for maintainability, complementarity, accessibility, reliability, exception handling, and operational environment conversion.
4. Runtime Environment Regulations
4.1. Device
List the hard devices required to run the software. Describes the new devices and their special functions, including:
A. Processor Model and memory capacity;
B. External storage capacity, online or offline, media and its storage format, device model and quantity;
C. Model and quantity of input and output devices, online or offline;
D. Model and quantity of data communication equipment;
E. function keys and other dedicated hardware
4.2. Support Software
List supported software, including network and hardware device platforms, operating system platforms, database system platforms, and compiled (or compiled) Programs and test support software.
4.3. Interface [Optional]
Describes the interfaces and data communication protocols between the software and other software.
4.4. Control [Optional]
Describes how to control the running of the software and the control signals, and describes the sources of these control signals.
5. Requirement tracking
The main purpose of requirement tracking is to ensure that all requirements are analyzed and describe the coverage of the analyzed requirements to the promised requirements in the form of a commitment requirement-analysis requirement table (prs_srs table. For the prs_srs table format, see software requirement management process specification (SUPL-MANU-SRS-001 ).


6. Approval Form
I have read the above Software Requirement Specification, I will strictly abide by the terms in the specification, and ensure full support for the implementation of this specification.


Execution Supervisor:
Date

Technical Director:
Date

Project leader:
Date

User representatives:
Date

Developer representatives:
Date

Group members:
Date

Group members:
Date