1. Introduction

1.1. Background

Description:

a. The name of the software system to be developed;

b. The task proposer, developer, user of this project and the computing center or computer network that implements the software;

C. The basic interrelationship between the software system and other systems or other organizations.

1.2. Reference materials

List the materials cited and referenced in this manual, such as:

a. The approved mission statement or contract of this project, and the approval document from the superior authority;

b. Other published documents belonging to this project;

c. The documents and materials cited throughout this document include the software development standards to be used. List the title, document number, publication date and publishing unit of these documents and information, and indicate the source from which these documents and information can be obtained.

1.3. Assumptions and constraints [optional]

List the assumptions and constraints for the development of this software, such as funding constraints, development deadlines, equipment conditions, user data preparation and Communication issues, etc.

1.4. User characteristics [optional]

List the characteristics of the end users of this software, fully describe the education level and technical expertise of operators and maintenance personnel, and the software expected frequency of use. These are important constraints for software design work.

2. Functional requirements

2.1. System scope

Clearly and briefly describe the user’s high-level goal requirements for the system and product, such as the intention of system development, Application goals, scope, and other relevant background material.

If the defined product is a component of a larger system, the relationship between the product and other components of the system should be explained. For this purpose, a block diagram can be used to illustrate the The composition of the system and the connection and interface between this product and other parts.

2.2. System architecture (this section can be cut for systems with two-tier architecture) [Optional]

Describe the overall architecture of the system using a combination of diagrams and text.

The following should provide the overall system architecture diagram:

The following describes the overall system architecture:

2.3. Overall system process

With The overall process of the system is explained through a combination of diagrams and text.

Figure 1 is the overall flow chart of the planning contract management system.

Figure 1

2.4. Requirements analysis

The purpose of requirements analysis is to obtain or describe each functional requirement in the system requirements, and determine through analysis that the system can do what? Who will use this system?

· Establish a use case model: discover roles and use cases, and determine the relationship between roles, the relationship between use cases, and the relationship between roles and use cases

· Describe use cases : A specification of how the character interacts with the system.

2.4.1. Describe functional requirements from the perspective of user business.

2.4.1.2. Business modeling

From a visual perspective - use case diagram - describing functional requirements

Figure 2 is the contract editing of the comprehensive planning management system Use case diagram of business functional requirements.

Figure 2

2.4.1.3. Use case description

Describe in text the specifications of the interaction between the role and the system in each use case.

1. XXXXXX (use case name)

Describe the object description content

Identifier The unique identifier of the use case

Describe the use case Summary Description

Actors List of actors associated with this use case, and actor characteristics

Frequency How often actors access this use case

Status Normal Divided into: in progress, waiting for review, passed review or failed review

Preconditions A list of conditions, if it contains conditions, these conditions must be met before accessing the use case

Postconditions A list of conditions that, if included, will be satisfied after the use case completes successfully

Extended use case The use case that this use case extends (if it exists)

The main logical path followed by the basic operation process participants in the use case, that is, the work of the use case when all work is carried out normally Method

The path that the optional operation process follows when working methods are changed, exceptions occur, or errors occur

Modification history modified by: Modified date: Modified reason:

p>

Issue, if any, a list of issues or action items related to the development of this use case

The following is the contract addition use case description in the contract editing functional requirements in the integrated planning management system:

Describe object description content

Identifier IPMS0101

Instructions for adding a contract record

Participant contract editor--familiar with contract management Business

Frequency

Status passed review

Prerequisites 1. The participant has the permissions increased by the contract 2. The participant has selected the corresponding plan record 3 . Current planned total investment ≥ SUM (signed contract price under the plan)

Post-conditions 1. Add a contract discipline to the database 2. Use case for scanning original executable contract 3. Use case for adding payment to executable contract 4. Executable contract modification and contract deletion use cases

None of the extended use cases

None of the included use cases

For the basic operation process, please refer to the contract in Figure 3 Add process

Optional operation process When the user finds an exception when confirming the addition of the contract, the system prompts that the contract addition is invalid

Modification history Modifier: Modification date: Modification reason: < /p>

Question 1. Specific agreement on contract coding 2. Specific design of contract type, source of funds, and contract trustee dictionary table

Figure 3 Contract addition activity process

2. Projects can also provide prototype interface copies.

2.4.2. XXXXXXX (functional requirement name)

……

3. Non-functional requirements

3.1. Performance requirements< /p>

3.1.1. Accuracy [optional]

Describe the accuracy requirements for the input and output data of the software, which may include accuracy during the transmission process.

3.1.2. Time characteristic requirements

Explain the time characteristic requirements for the software, such as: response time; update processing time; data conversion and interface update transmission time, etc. Require.

3.1.3. Input and output requirements

Explain each input and output data type, and describe its media, format, numerical range, precision, etc. item by item. Explain and give examples of the software's data output and control outputs that must be labeled, including descriptions of hard copy reports (normal result output, status output, and abnormal output) and graphical or display reports.

3.2. Data management capability requirements [optional]

Describe the number of files and records that need to be managed, the size of tables and files, and the size of the files to be managed based on foreseeable growth. Estimates are made of storage requirements for the data and its components.

3.3. Security and Confidentiality Requirements

Users have requirements for the system’s fault handling capabilities, processing methods, system recovery and data recovery after failures, and the system’s requirements to prevent confidential data from being accessed Requirements for illegal intrusion, modification and loss.

3.4. Flexibility requirements [optional]

Describe the requirements for the flexibility of the software, that is, when certain changes in requirements occur, the software's ability to adapt to these changes , such as:

a. Changes in operating methods;

b. Changes in operating environment;

c. Changes in interfaces with other software;

d. Changes in accuracy and validity period;

e. Planned changes or improvements.

Specially designed sections to provide this flexibility should be identified.

3.5. Other special requirements [optional]

For example, user units’ requirements for ease of use, maintainability, supplementability, legibility, reliability, and exception handling requirements, special requirements for the convertibility of operating environments, etc.

4. Operating environment requirements

4.1. Equipment

List the hardware equipment required to run the software. Describe the new equipment and its specialized functions, including:

a. Processor model and memory capacity;

b. External storage capacity, online or offline, media and its storage format, model and quantity of equipment;

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 special hardware

4.2. Supporting software

List supporting software, including network and hardware device platforms, operating system platforms, database system platforms, and compilation (or assembly) programs and test support software, etc.

4.3. Interface [optional]

Describe the interface, data communication protocol, etc. between the software and other software.

4.4. Control [optional]

Describe the methods and control signals for controlling the operation of the software, and explain the sources of these control signals.

5. Requirement tracking

The main purpose of demand tracking is to ensure that all requirements are analyzed, and the analyzed requirements are described in the form of committed requirements-analyzed requirements correspondence table (PRS_SRS table) Coverage of committed needs. For the format of the PRS_SRS table, please refer to the Software Requirements Management Process Specification (SUPL-MANU-SRS-001).