MIS
Demand specification manual writing guide
Document properties:
Document Number Document Version V1.0 Confidential Level Population Review Approved
Modify record:
Date modification chapter Modification Type * Modify Description Modify Version 03.8.10ALLA Create Zhang Wei 1.0
* Modify type is divided into A - Added M - Modified D - DELETED
1 Overview
guide
purpose:
Introducing the development background of the system.
content:
l Software name and version
l system goal
l Customers and users
l product concept
l document agreement
l reference
Methods and points:
l 1.1 plug-in software name and version
l 1.2 Fill in the software development target, requires a quantified indicator to explain the problem. Can refer to "User Demand Report"
l 1.3 Customer and user. Typically, the organization or individual of the purchase software is a software customer; the specific user of the software is a software user.
l 1.4 The product concept, including the expectations of the product; the meaning of the product; the value of the product; the product is theoretical.
l 1.5 Fill in document conventions, including document numbers, naming standards, function item description, priority description, reference requirements description.
l 1.6 filling in the reference. Includes software, documentation, and books, including reference.
1.1 Software Name and Version
1.2 goal
1.3 customers and users
1.4 product philosophy
1.5 Document Convention
Demand priority description
Priority level Important Description Priority 1 [A1] The priority must be implemented. There is no specially indicated demand in this article, and the priority is definitive to priority 1. Priority 2 [A2] Priority for achieving implementation, if difficult, can be varied in a way that priority 3 [A3] is achieved in a variety of ways, if it is difficult, considering the priority 4 [C4] can wait The priority 5 [C5] must be achieved when the upgrade is upgraded.
1.6 reference
2, glossary
guide
purpose:
List the concepts, terms, and abbreviations that need to be explained so that the reader can understand the documentation accurately and consistently.
content:
l Business terminology and abbreviation
l Computers that are prone to generate ambiguity belong to an abbreviation.
Methods and points:
l Focus on important, frequent, uncommon, easy to have ambiguous nouns, terms and abbreviations.
l If more terms are more, it is recommended to classify the terms.
l For nouns, interpretations of terms, the terms and abbreviations shall be used to use authority explanation and as indicated as much as possible.
l Add chart auxiliary instructions if necessary.
3. Comprehensive description
guide
purpose:
Application scenarios for comprehensive summary systems. Let users and developers have a whole understanding of the system, and the system involved.
content:
l background and range
l tissue structure
l Post definition
l job process
l document, books and reports
l functional structure
l function list
l operating environment
Methods and points:
Enable the new system:
l What changes will there be organizational structure, position and procedures?
l Document, what changes will the account and reports bring?
l What is the overall structure of the system?
l What main functions are available?
l What is the application environment of the system?
This chapter answers the above problems.
The enabled computer system is likely to bring new management ideas and ways to business, the original organizational structure, post definition, and job processes will face change. The original organizational structure may be adjusted, the original position may be revoked or merged, and the original part of the manual operation may be replaced by the computer system. With the enabled of the computer system, it is also possible to establish a new department and derive new positions. The original process will be fully combed. The enabled of a computer system, if "replacing the soup does not change the medicine", does not combat the original organization, position and procedures, then the value generated by the computer system will not be reflected, time is long, and it is likely to be from the grassroots operator. Subject to the emotions and eventually flow in the form. Of course, it is not necessarily used by computer systems, and the organization, position and process will change. It is possible that users have established organizations and processes that adapt to computer management, or the computer system is enabled, not enough to change existing organizations and processes. So, it is also right. The document, the book, and the report are the carrier of the process, and if the process changes, the document, the book, and the report often also have a corresponding change. After the computer system is enabled, with the powerful processing power of the computer system, users may query more data, and the format of the documents may also be more flexible and unified. Based on the above reasons, the changed documents, books, and reports should be described.
The system function structure describes our "big concept" for the system. This part of the content is great for designer's understanding of demand, and it is possible to verify that the analyst has correctly set the system boundary and whether the functional design is clear and reasonable.
The system function list represents a commitment to the customer from the perspective. Function list From a management perspective, you can export to the "Demand Design Implementation Test Coverage List" as the source of design, implementation, and test traceability.
Functional structure and function list, generally give the overall specifications of the system.
The system's operating environment will describe the software, hardware, and network environments of the system, and rough physical deployment, including peripherals, special interfaces, third-party controls, middleware, etc.
Here is the specific division of labor of each section of this chapter:
l 3.1 Description business background and range.
L 3.2 Section Description After using the system, the organization structure and department duties are used. If there is a "user demand report", you can omit the same content as "User Demand Report". If there is no "user demand report", this part cannot be omitted.
L 3.3 Scene Description After using the system, the user's position is defined. If there is a "user demand report", you can omit the same content as "User Demand Report". If there is no "user demand report", this part cannot be omitted.
L 3.4 Section Description After using the system, the user's business process. If there is a "user demand report", you can omit the same content as "User Demand Report". If there is no "user demand report", this part cannot be omitted.
L 3.5 Description Use this system, the documents, books, and reports used by the user. If there is a "user demand report", you can omit the same content as "User Demand Report". If there is no "user demand report", this part cannot be omitted.
L 3.6 gives a functional structure, it is recommended to describe the form of graphic auxiliary text. The problem should be integrated, and the problem should be explained to avoid falling into specific details.
L 3.7 gives a list of functions. Function is classified if necessary. It is recommended to use the number to manage. It is recommended to establish a priority.
l 3.8 Section gives the hardware, software environment, including rough physical deployment.
3.1 Background and range
3.2 Structure of the system
Organization Chart
Departmental duties list
Departmental responsibilities
3.3 Questional Definition
Post definition table
Post office responsibility
3.4 System of operating processes
3.5 Documents, books, report formats
3.6 Functional Structure 3.7 Function List
Number function item priority function brief description
3.8 Operation Environment and Physical Deployment
4, functional needs
guide
purpose:
A detailed functional requirement is given in the form of a USE CASE contract.
content:
See the sample.
Methods and points:
General requirements for functional requirements. See the table below.
Description of functional requirements. See the table below.
Interface element description agreement. See the table below.
Guide: General requirements for functional requirements
Correctly accurately describe the functions to be delivered. Users determine the correctness of the demand. It is clear that there is one of every demand and there is only one explanation. Consistent document content is consistent with the previous work product. Completely include all important needs. The demand scope is properly restricted, and the demand constraint is reasonably used. Do not specify any design or implementation details, not more constraints outside the software. You can implement each need must be implemented. It can be tracked to have a clear identifier for each requirement. Each source of demand is determined. Verify that each requirement is verified. Modifications can be convenient to change requirements in the case of structural and style constant. It is easy to understand to be understood by customers and developers. Can be readily used by similar items or products. Priority Each requirement has a clear priority.
Guide: Description of Functional Demand
Number
Guide: Interface element description agreement
Data Item Data Description Constraints Change the initial value
5, public parts
guide
purpose:
Extract the public parts that can be reused, reduce the redundancy of documentation.
content:
Print and preview.
Conditional query
Authority
......
Methods and points:
Based on the purpose of increasing multiplexing and reducing document redundancy, it is recommended that the analysts can be reused in the demand stage, and independently enrollment, which has two advantages:
1. It can be used as a basis for designing multiplex parts for designers.
2. Documentation uses the part of these shared parts directly to public parts, and does not need to be repeatedly described, thereby reducing document redundancy.
6, business modeling
guide
purpose:
Setting the business model as the clues defined in Chapter 4.
content:
Reference business modeling sample.
Methods and points:
Reference Business Modeling Guide.
7, data entity
guide
purpose:
Identify data entities and entity relationships.
content:
Entity relationship diagram
Entity description
Methods and points:
Business systems often use relational databases. Data entities are an important basis for establishing relational database data structures.
An important source of data entities is a permanent saving object identified in documents, books, reports, and business modeling.
The elements of the data entity are: entity names, attributes, and entity relationships.
Guide: Entity Association Map
Guide: Entity Description Template
Name
guide
purpose:
Describe the non-functional needs of the system
content:
l appearance
l is easy to use
l performance
l Reliability
l Quality requirements
l
Methods and points:
l 8.1 Filling the desired product appearance, including:
Display method
Display style
Appearance tendency
Appearance intent
......
l 8.2 Fill in the ease of use, including
Easy to operate
Easy to learn
Easy to understand
......
l 8.3 Filling system performance. include:
speed
effectiveness
Usability
accuracy
Throughput
Response time
Recovery Time
......
l 8.4 Filling reliability. include:
Fault frequency / severity
Recoverable
Foreseeable
accuracy
Average failure response time (MTBF)
......
l 8.5 Filling quality requirements.
Thousands of BUGs.
......
l 8.6 filling other non-functional needs.
8.1 appearance
8.2 ease of use
8.3 performance
8.4 reliable
8.5, quality requirements
8.6, other
9, other description
9.1 Development Environment
9.2 Design and implementation limitations
9.3 Demand - Corresponding to the allocation requirements
Demand - Allocation requirements correspondence (numbered by demand, from small to large increments) (numbers to allocation requirements)
10, appendix:
10.1 Waiting list
10.2 Accessories
