Software development of various document templates

http://blog.163.com/amanda_liyan/blog/static/5456169120093304520393/

Feasibility Analysis Report

1 Introduction
1.1 Purpose: To clarify the purpose of preparing the feasibility study report and to propose the reader object.
1.2 Project background: should include
　　 The name of the proposed development software
　　 The project's task-seekers, developers, users, and units that implement the software
　　 The relationship between the project and other software or other systems.
1.3 Definition: Lists the definitions of the specialized terms used in the document and the original text of the abbreviations.
1.4 References: Lists the author, title, number, publication date, publication unit or source of the information, which may include
　　 Approval of the project's approved plan of assignment, contract or superior authority
　　 Published information related to the project
　　 The data referenced in the document, the software standards or specifications used
2 Prerequisites for Feasibility studies
2.1 Requirements: List and describe the basic requirements for the proposed development of the software, such as
　　 function
　　 Performance
　　 Input/output
　　 Basic data flow and process flow
　　 Security and confidentiality requirements
　　 Other software-related systems
　　 Finish date
2.2 Objectives: may include
　　 Savings in human and equipment costs
　　 Improvement of processing speed
　　 Control accuracy or productivity improvement
　　 Improvements in Management information services
　　 Improvement of decision System
　　 Improvement of staff productivity
2.3 Items, assumptions and limitations: may include
　　 Recommended to develop the shortest life span of software operation
　　 The time limit for the comparison of obvious options
　　 Sources of funding and restrictions on use
　　 Legal and policy constraints
　　 Conditions and limitations for hardware, software, operating environment, and development environment
　　 Available information and resources
　　 Recommend the latest time to develop software to be put into use
2.4 Feasibility Study Methods
2.5 key factors in determining feasibility
3 analysis of the existing systems
3.1 Process flow and data flow
3.2 Workloads
3.3 Expense: Expenses such as manpower, equipment, space, supporting services, materials, etc.
3.4 Personnel: List the professional technical categories and quantities of personnel required
3.5 devices
3.6 Limitations: Explain existing system problems and why new systems need to be developed
4 Recommended Technical Feasibility analysis
4.1 Brief description of the system
4.2 Advantages of comparison with existing systems
4.3 Process flow and data flow
4.4 Possible implications of using the proposed system
　　 Impact on the device
　　 Impact on Existing software
　　 Impact on users
　　 Impact on the operation of the system
　　 Impact on the development environment
　　 Impact on expenditure of funds
4.5 Technical Feasibility evaluation: including
　　 Whether the functional purpose is achieved under the restriction condition
　　 Using the existing technology, the functional purpose is to achieve
　　 Requirements for the number and quality of developers, and indicate whether they meet
　　 Whether the development can be completed within the stipulated period
5 Proposed system economic feasibility analysis
5.1 Expenditure
5.2 Benefits
5.3 Benefits/investment ratio
5.4 Payback Period
5.5 Sensitivity analysis: Refers to a number of key factors, such as:
　　 System life Cycle length
　　 The amount of system work load
　　 Processing speed Requirements
　　 Analysis of the impact of equipment and software configuration changes on expenditures and benefits
6 feasibility analysis of social factors
6.1 Legal factors: such as
　　 Contractual liability
　　 Infringement of patent rights
　　Copyright Infringement
6.2 Use of the user feasibility: such as
　　Administration of user units
　　Working Schedule
　　Personnel quality and so on can meet the requirements
7 Other options available
Clarify other options individually and highlight the reasons for not being recommended.
8 Concluding observations
　　can start to organize development
　　Need to wait for a few conditions to be developed
　　Some modifications to the development goals are required
　　cannot be or does not need to be
　　other

Software Requirement Specification

1 Introduction
1.1 Purpose: To clarify the purpose of writing the requirements statement, indicating the reader object.
1.2 Project background: should include
　　 The entrusted unit, Happy Unit and competent department of the project;
　　 The relationship between the software system and other systems.
1.3 Definition: A wish to list the definitions and abbreviations of the specialized terms used in the document.
1.4 References: may include
　　 Approval of the project's approved plan of assignment, contract or superior authority
　　 Materials, specifications, etc. referenced in the document
　　 List the author, title, number, publication date, publication unit, or source of the information
2 Overview of tasks
2.1 Goals
2.2 Operating Environment
2.3 Items and Limitations
3 Data Description
3.1 Stance Data 
3.2  Dynamic Data: Includes input data and output data.  
3.3  Database Description: Gives the name and type of the database used.  
3.4  data dictionary  
3.5  data collection  
4  Functional Requirements  
4.1 function partition  
4.2 function Description  
5  performance requirements  
5.1  data accuracy  
5.2  Time characteristics: such as response time, update processing time, data conversion and transmission time, running time, and so on.  
5.3  adaptability: the ability to adapt to changes in the way they operate, the operating environment, interfaces with other software, and development plans.  
6  Operational Requirements  
6.1  user interface: such as screen format, report format, menu format, input and output time, etc.  
6.2  Hardware interface  
6.3  software interface  
6.4  fault handling  
7  Other requirements  
such as usability, security, maintainability, portability, etc.

Project Development Summary Report

1 Introduction
1.1 Purpose: To clarify the purpose of the preparation of the summary report and to indicate the reader object.
1.2 Project background: Explain the source of the project, the entrusted Unit, the Development Unit and the competent department.
1.3 Definition: Lists the definitions of the specialized terms used in the report and the original meaning of the abbreviations.
1.4 References: Lists the author, title, number, date of publication, publication unit or source of the information, which may include: Project task book, Contract or approval, project development plan, requirement specification, summary design specification, detailed design specification, user operation manual, test plan, test analysis report Other materials cited in this report, development standards adopted or development specifications.
2 Development Results
2.1 Products: May include the name of the program that lists the parts, the number of source program lines (including comment lines) or the number of program bytes and program totals, storage format, product document name, etc.
2.2 Main functions and performance
2.3 Hours used: Timing each person's different levels.
2.4 When used: according to the computer model to be timed separately.
2.5 Progress: Give a comparison between the schedule and the actual progress.
2.6 Fees
3 Reviews
3.1 Productivity evaluation: such as the average number of source lines per person produced per month, document word count, etc.
3.2 Technical Program Evaluation
3.3 Product Quality evaluation
4 experience and lessons learned

Test Analysis Report

1 Introduction
1.1 Purpose: To clarify the purpose of writing the test analysis report and to indicate the reader object. 
1.2  Project background: Describes the source of the project, the delegation unit and the competent department.  
1.3 definition: Lists the definitions and acronyms of the specialized terms used in the test analysis report.  
1.4 References: Lists the author, title, number, date of publication, publication unit or source of the information, which may include: Project plan, contract or approval; project development plan; Requirement specification; summary Design Manual Detailed design instructions, user operating manuals, test plans, other materials referenced in the test analysis report, software engineering standards or engineering specifications used.  
2  test Plan hospitality  
2.1  organization and personnel: give the name of the test organization, the person in charge, and the list of participating testers.  
2.2  test results: Each test item is given in order: The measured result data, the deviation from the expected result data, the fact that the test indicates, and the problem identified by the test.  
3  Software Requirements Test conclusion  
the conclusion of each requirement test in order. Includes: Proven software capabilities, limitations (i.e., the circumstances and reasons for which the requirements have not been adequately tested.  
4  evaluates  
4.1  software capability: tested to demonstrate software capabilities.  
4.2  defects and limitations: Describes the software flaws and deficiencies exposed by the test, and the impact that may have on the software operation.  
4.3  Recommendations: Proposed to compensate for these shortcomings.  
4.4  Test Conclusion: The explanation can pass.

Project Summary Design Manual

1 Introduction
1.1 Writing Purpose: To clarify the purpose of writing a summary design specification, indicating the reader object.
1.2 Project background: should include
　　 Entrusted units, development units and competent departments of the project
　　 The relationship between the software system and other systems.
1.3 Definition: The willingness to list the definitions and abbreviations of the terminology used in this document.
1.4 References:
　　 List the author, title, number, publication date, publication unit, or source of the information
　　 Approval of project tasks, contracts or higher authorities, project development plan, requirements Specification, test plan (first draft), User manual
　　 The materials referenced in the document, the standards or specifications adopted.
2 Overview of tasks
2.1 Goals
2.2 Requirements Overview
2.3 Items and Limitations
3 Overall Design
3.2 Overall structure and module exterior design
3.3 Function Assignment: Indicates the relationship between function and program structure.
4 Interface Design
4.1 External interface: Includes user interface, software interface and hardware interface.
4.2 Internal interface: the interface between the modules.
5 Data structure Design
6 Logical Structure Design
The unified cover page format for all documents is shown in the following pages.
7 Physical Structure Design
8 The relationship between data structure and program
9 Running the design
9.1 Combination of running modules
9.2 Operation Control
9.3 Run Time
10 Error Handling Design
10.1 Error Output Information
10.2 Error Handling countermeasures: such as setting up backup, performance degradation, recovery and restart.
11 Secure and confidential design
12 Maintenance Design
Description for the convenience of maintenance work facilities, such as maintenance modules.

detailed Software Design manual

1 Introduction
1.1 Purpose: To clarify the purpose of writing a detailed design specification, indicating the reader object.
1.2 Project background: should include the source of the project and the competent departments.
1.3 Definition: The willingness to list the definitions and abbreviations of the terminology used in this document.
1.4 References:
　　 List the author, title, number, publication date, publication unit, or source of the information
　　 Approval of project tasks, contracts or higher authorities, project development plan, requirement specification, summary design specification, test plan (first draft), User manual
　　 The document refers to the data, software development standards or specifications.
2 overall design
2.1 Requirements Overview
2.2 Software structure: Give the structure diagram of software system.
3 Program Description
3.1 The following instructions are given on a per-module basis:
　　function
　　Performance
　　Enter Project
　　Output Project
3.2 algorithm: The algorithm chosen by the module.
3.3 Program Logic: Detailed description of the module implementation of the algorithm, can be used: standard flow chart;PDL language;n-s diagram; decision table and other descriptive algorithms.
3.4 Interface
　　Storage Allocation
　　Restriction conditions
3.5 Test points: Give the test module of the main test requirements.

Software development of various document templates