HJ 622-2011Technical specification for environmental protection applications development management (English PDF)

3.2 Development process

A set of related activities performed for a given purpose during software development.

3.3 Non-functional requirement

Requirements other than functional requirements in user requirements, such as reliability, efficiency, ease of use, etc.

3.4 Software product software product

A set of computer programs, procedures, and possibly related documents and data.

5.1 Entry criteria

The Software Development Plan (implemented in accordance with GB/T 8567-2006) has passed the review. The requirements developer has been identified.

5.2 Requirements Development and Management Process

The requirements development and management process should include pre-investigation preparation, requirements research, requirements analysis, writing user requirements specifications, User needs review, user needs confirmation, software requirements analysis, writing software requirements specification, software requirements review, Important activities such as demand change control, the main work flow is shown in Figure 1.

requesting research

demand analysis

User needs review

User demand confirmation User Requirements "User Needs Survey Form" User Requirements Manual Software requirement definition Software Requirements Review "Software Requirements Specification" Contract technical annex Whether the review passed Whether the review passed End of demand analysis Solution or proposal Preparation before research Start Demand change

Figure 1 Flow chart of requirements development and management process

5.3 Main steps

5.3.1 Preparation before investigation

The developer shall determine the time and demand for the investigation and obtain relevant stakeholders, and complete the user according to the selected research method.

Prepare for the Demand Survey (see Appendix A).

The main contents of the User Needs Survey Form should include. the name of the respondent, the time, location, and background of the user.

Information, demand information records, reliability and support information, and the use of existing environmental protection application software.

5.3.2 Demand research

The developer should adjust according to the interview outline and research plan through prototype method, conference, interview, questionnaire survey, etc.

Check and fill out the User Needs Survey Form as the original user requirement. Users should cooperate with the completion of the needs survey.

This phase of the survey can include the following.

a) the organizational structure of the environmental management department and the responsibilities of each functional department;

b) information construction environment, including operating system platform, database system, hardware network, constraints on the system, Dependence of the construction of this system;

c) Existing environmental information system, including software name, purpose, development unit, development language, and saved phase Relevant technical documentation, online time, usage, scope of use, department of use, department responsible, person in charge, Operating environment, existing data, secondary development interface, maintenance, etc.

d) construction of similar software projects;

e) the software positioning and expansion requirements;

f) business scope, workflow, data involved and business issues that need to be resolved through the software, may involve construction Project approval management, environmental administrative punishment management, environmental petition management, environmental monitoring management, pollution source monitoring Management, ecological protection management, nuclear safety and radiation management, environmental emergency management, environmental protection e-government, etc.;

g) the input and processing of each business and the roles and outputs involved in the environmental protection business;

h) the definition of the environmental data center, the data items involved, and the business issues that need to be addressed through the data center;

i) the current status and needs of space technology applications, as well as spatial data requirements;

j) software information security status, requirements, level protection or hierarchical protection requirements;

k) The need for environmental protection website construction.

5.3.3 Demand Analysis

According to the demand survey results, the developer should analyze the user requirements and write the User Requirements Specification (see Appendix B), User Needs Survey Form is attached to the User Requirements Manual.

5.3.4 Writing User Requirements Specification

The main contents of the User Requirements Manual should include. description of the business status (organization structure and functions, job definition, industry) Service process, forms and reports, problems, etc.), software function requirements (can be divided into several modules for explanation), software non Functional requirements (user interface, requirements, performance requirements, and other requirements).

If the prototype method is applied for demand research, it should be fully reflected in the corresponding content of the User Requirements Manual.

Type-confirmed user interface requirements, functional requirements, and interaction requirements with the system.

At this stage you should also pay attention to.

a) the relationship with existing environmental protection application software;

b) how future business data is integrated into the environmental data center and how it is processed;

c) the relevant provisions of the State and the Ministry of Environmental Protection on relevant business processes, such as radioactive source management and pollution source monitoring;

d) security mechanisms, including system identity authentication, database security, network security requirements, etc.;

e) use of the population, including the level of computer knowledge, the definition of the role of use in the business, etc.;

f) Data exchange interface between the environmental protection department and other relevant administrative departments.

5.3.5 User Needs Review

The developer shall review the User Requirements Specification in accordance with the requirements of Chapter 13 of this standard.

5.3.6 User Needs Confirmation

User requirements should be validated by the user. After the developer submits the request for confirmation of the application, the user says "user demand" the contents of the book shall be confirmed in a timely manner without objection, and the construction period shall be confirmed in the total project duration (excluding the service and maintenance period).

Within 10% range. The confirmation methods include. signature verification of the requirements document, signature verification of the needs review meeting minutes, confirmation of the official letter, etc.

The way the two sides can agree.

5.3.7 Software Requirements Analysis

The developer shall conduct a demand analysis according to the "User Requirements Manual" to form a mapping of user requirements to software requirements.

Into the "Software Requirements Specification."

5.3.8 Writing Software Requirements Specification

The main contents of the Software Requirements Specification (implemented in accordance with GB/T 8567-2006) should include. an overview of requirements, Requirements specifications (system overall functional requirements), detailed functional requirements (can be divided into several parts), non-functional requirements.

5.3.9 Software Requirements Review

The developer shall review the Software Requirements Specification in accordance with the requirements of Chapter 13 of this standard. Software needs the specification should be approved by the reviewer.

5.3.10 Demand Change Control

Changes in demand should be analyzed, confirmed, and subject to change control.

The demand change control process is shown in Figure 2.

Change analysis

Change approval

Implement changes

Request for Change of Requirements Change implementation review Whether the approval passed Whether the review passed End Submit a change request Start Request for Change of Requirements Request for Change of Requirements

Figure 2 Environmental protection application software requirements change control flow chart

Implementation requirements changes should meet the following requirements.

a) Submit the change request. The change proposer (user, developer, etc.) should submit the change request and write Application for Change of Requirements (see Appendix C). The main content of the Request for Change of Requirements should include.

Reasons, content, impact analysis on other tasks, impact analysis on the project, signature of the applicant, change Approval of signature, etc.;

b) Change analysis. The developer should analyze the content of the demand change request, and the analysis content should include. the scope of influence, Content, technical solutions, project impact, risk, cost, workload, etc. Developers and users should analyze the content Agree;

c) Change approval. The change of requirements shall be validated by the joint signature of the user and the developer;

d) Implementation changes. Changes can only be implemented after the requirements change approval has been approved. The developer should change the change according to the change impact analysis all relevant content within the scope of influence will be changed accordingly, and if necessary, the requirements development should be re-established.

recognize;

e) Change implementation review. After the implementation of the change is completed, the developer and the user should organize the review team to review the changes.

Review or test to ensure that the changes are correct and the versions of the revised work results correspond to each other;

f) Change of the construction period. the time required to submit the change application to the completion of the change approval should be in the total project duration (excluding service and Maintenance period) within 5% range.

5.4 Output

"User Needs Survey Form", "User Requirements Manual", "Software Requirements Specification", "Demand Change Request" Please book.

6.1 Entrance criteria

Software Requirements Specification.

6.2 Environmental Protection Application Software Overview Design Process

The outline design process should include. outline design preparation, identify constraints that affect software design, determine design strategies, Important activities such as outline design, writing summary design documents, and summary design review. The main workflow is shown in Figure 3.

Summary Design Specification Software Requirements Specification Identify impact software design Constraint factor Determining design strategy Write a summary design document Summary design review Whether the review passed Outline design End Outline design preparation Design start Outline design

Figure 3 Environmental protection application software summary design flow chart

6.3 Main steps

6.3.1 Outline design preparation

The developer's design preparation work should include.

a) Read the requirements document to clarify the design tasks;

b) assign software design tasks, including software architecture, data structures, logic flows, etc.;

c) Prepare relevant design tools and materials.

6.3.2 Identify constraints that affect software design

The developer should extract the requirements constraints from the requirements document, which may include. standard or specification constraints, software and hardware environments (packages) Including the operating environment and development environment) constraints, interface/protocol constraints, user interface constraints, software quality constraints, implicit constraints, Security constraints, etc.

6.3.3 Determining the design strategy

The developer shall determine the design strategy based on the requirements and development strategies of the software product, including but not limited to the following strategies.

a) Expand the strategy to meet the expansion needs of the environmental protection management business;

b) reuse strategy to extend the life cycle of environmental protection application software;

c) Compromise strategy to reduce the cost of environmental protection application software development and improve development efficiency.

6.3.4 Outline design

The main content of the developer's summary design should include.

a) Software architecture design. the function of each subsystem and the relationship between subsystems should be determined;

b) Module partitioning. The subsystem should be decomposed into modules and the function of each module and the relationship between the modules should be determined.

system;

c) Classification and planning of environmental information. in accordance with GB/T 16705-1996, GB/T 16706-1996, HJ/T 417-2007, Implementation of relevant requirements such as HJ/T 352-2007, CH/T 1005-2000, CH/T 1007-2001;

d) preliminary design of the database. it should be performed in accordance with the functional requirements and in accordance with HJ/T 419;

e) Software and hardware environment. should meet the user's existing environmental conditions, contact with external business needs and expansion needs;

f) Safety design. It should be implemented in accordance with the requirements of GB 17859-1999 and GB/T 20282-2006.

6.3.5 Writing a summary design document

The main contents of the Outline Design Specification (see Appendix D) should include. a general overview of the software and an approximation of the design.

Beam factor, design strategy, software overall structure, module function, system interface, environmental database design planning, operation requirements Software and hardware environment, etc.

6.3.6 Summary Design Review

The developer shall review the Summary Design Specification in accordance with the requirements of Chapter 13 of this standard.

6.4 Output

Summary Design Specification.

7.1 Entry criteria

Summary Design Specification.

7.2 Environmental Protection Application Software Detailed Design Process

The detailed design of environmental protection application software should include detailed design preparation, database design, module design, interface design, Important activities such as interface design, writing detailed design documents, detailed design review, etc. The main workflow is shown in Figure 4.

Figure 4 Detailed design flow chart of environmental protection application software

7.3 Main steps

7.3.1 Detailed design preparation

Preparations should include.

a) Identify environmental databases, software functional modules, and interface design tasks based on requirements documents and summary design documents;

b) prepare relevant design tools and materials;

c) determine the environmental database and interface design rules of the software;

d) Others may be performed in accordance with HJ/T 419.

7.3.2 Database Design

Developers should pay attention to standardization and scalability when designing databases. Data should be based on unified data standards.

Library design ensures data connection and sharing with other application systems. Database design should be performed in accordance with HJ/T 419.

The coding design of environmental information shall comply with GB/T 16705-1996, GB/T 16706-1996, HJ/T 212, HJ/T Standard implementations such as 417-2007, HJ/T 352-2007, CH/T 1005-2000, and CH/T 1007-2001. Safety design should be followed GB 17859-1999 and GB/T 20282-2006 are implemented.

7.3.3 Module design

The module design should be iterative as follows.

a) main function and attribute design. the main functions and attributes of each module;

b) Data structure and algorithm design. the data structure and algorithm of each module, which should meet the environmental protection department and local environmental protection Relevant algorithm requirements as specified in the standards issued by the organization;

c) Relationship design between classes. generalization, dependencies, associations, aggregations, and combinations between design completion classes;

d) Data access and display design. the format of data storage and display to ensure the specification and effectiveness of environmental information.

The environmental monitoring method standards and relevant format requirements for data reporting should be met, including the detection limit, the maximum number of significant digits, the number of digits after the decimal point, etc.

7.3.4 Interface Design

The user interface design should be iterative as follows.

a) create a prototype interface for environmental protection application software;

b) Users and relevant developers should be organized to evaluate the prototype interface of environmental protection application software, gather...