Requirement Description of Enterprise Management Software

Demand is the most critical input of the entire software project. According to statistics, 37% of unsuccessful projects are caused by demand. Compared with traditional hardware manufacturers, software requirements are vague, uncertain, changeable, and subjective. In hardware manufacturers, product requirements are clear, tangible, objective, descriptive, and measurable, and software requirements do not. As a document for interaction between customers, developers, and developers, Requirement documents "solidify" system requirements and serve as the carrier of requirements. Based on years of development experience in enterprise management information system, the author summarizes the methods and experiences described in the following requirements for your reference.

1. Five elements that constitute the enterprise management information system

The description of enterprise requirements can be described in two aspects: one is the description of the customer's current system, and the other is the vision of the future of the system. In general, the enterprise information system consists of five basic elements: the organizational structure, process, data, business rules and functions (performance) of the enterprise ). From the user's point of view, the main focus is on the process. Other elements are integrated through the process, and the requirement analysis personnel should also communicate with the user from this point of view; from the developer's point of view, we mainly focus on the enterprise's data, business rules and functions to facilitate system implementation. From the implementer's point of view, we mainly focus on the enterprise's organizational structure and functions, to facilitate the release and implementation of the system.

1) organization model of an enterprise
That is, the organizational structure of an enterprise, including department settings, job settings, and job responsibilities. A tree structure chart is a common method used to describe the organization model of an enterprise. It can be used to understand the leadership relationship between departments, the staffing situation within each department, and the division of duties among others, it is the basis for dividing the system scope and planning the system network. The user's organizational structure should be described in detail layer by layer in the organizational structure diagram, and the responsibilities of each department should also be briefly described. The organizational structure is the carrier of users' business processes and information. It helps analysts understand the business of the enterprise and determine the scope of the system. Retrieving a user's organizational structure is one of the basic tasks in the requirement acquisition step.

The Enterprise position or role in the user environment, like the Organization, is also the basis for analysts to understand the business of the enterprise and the basis for analysts to extract objects.

The identification of user roles is often omitted by system administrators of computer systems. The identification of roles is incomplete, leading to blind spots for future Function Identification.

(2) Enterprise Process Model
That is, the business processes of an enterprise, including the processes and relationships between processes, activities included in each process, and positions involved in each activity. An enterprise's job flow should first have a general business flow chart, describe the relationship between various businesses in the enterprise, and then describe each business in detail, combine business processes with department responsibilities. The detailed business flow chart can be in the form of a direct business flow chart. For enterprises, the description standards of business flowcharts need to be defined. The same legends are used to describe the business flowcharts for ease of management.

Advantages of business flow chart:
■ The drawing process is actually a systematic process of the job Process
■ It is intuitive to express the image, easy to communicate with users, and easy to exchange the survey results within the project team. The results of the survey need to be recognized by users, the communication documents should be easy to understand and cannot use professional terms.
■ Documents that can be used as training implementers and technical service personnel

Disadvantages of business flow chart:
■ The actual requirements of senior management personnel are unclear.
This is because users have never been in touch with computers. What is the management of computers? What can a computer do manually? There is no clear concept of what can be done manually, and so on. Therefore, users cannot reflect these problems. on the other hand, it indicates that the analysts have no experience and are not able to mine the original materials. They cannot extract the materials provided by the users to meet the real needs of the users and cannot find problems in the current management.
■ The overall relationship between various businesses is not expressed.
Direct Business flow charts can be used to clearly express the processing process of each business of an enterprise, but the links between different businesses are not displayed. A business flow chart is clear, however, they cannot be integrated. They do not have the overall concept. As a requirement analysis document, they are not completely expressed in this aspect.
■ Painting is cumbersome without using tools.

The diagram can clearly describe the process, but it must be accompanied by some text instructions, such as the business frequency, accident handling, and business frequency during peak hours, content that cannot be described in the flowchart must be described in detail.

(3) Enterprise Data Model
That is, what are the information carriers of enterprises? A detailed description of these information carriers, including the descriptions of various documents, books, and reports of the enterprise. In the demand report, the description of the document should be formatted, And the content to be described includes:
What is the purpose of a document?
Document Format: The document format must be clearly drawn and there are actual data samples to illustrate the problem in a specific and intuitive manner;
The specific description of the data items in the document: length, type, calculation and generation method, and constraints;
The data items of a document are filled by different types of roles, including those that can be filled by a computer.
Which data is required and not required in the document.
Document traffic: the average number of records generated per day and the peak quantity;
Document Classification: You can classify documents from multiple perspectives, for example, by business type (procurement, sales, and production ), classification by generation method (manual input type/automatic generation type), classification by the frequency of format changes (easy to change/stable ), categories by representation (list type/card type) and so on.
Relationship between documents: Reference relationship, etc.
You can also refer to the preceding entries to describe the required reports and books in detail.

(4) Business Rule Model of an enterprise
That is, what are the business rules of an enterprise? Where are these rules used? Business Rules can be divided into two categories from the scope of impact: one is partial rules, such as negative inventory, and the other is overall rules, such as managing all materials to batches. Business Rules are generally hidden in functional models or process models and do not need to be described separately. However, some complicated business rules need to be extracted and described separately, for example, business logic of various document accounting of an enterprise, 5) functional model of an enterprise
Functional requirements are the most important requirements of users. You can describe user functional requirements either in text or in language or in graphics, you only need to provide a complete, accurate, and easy-to-understand description of your needs. For systems with complex functional requirements (for example, more than 10 functional items), you can first describe an overview and directly describe a simple system in detail. The functional requirements of users should be classified and the classification method should be easy for users to understand. For example, the requirements of each department should be described according to the user's department settings, which is also convenient for users to be reviewed. Examples of classification methods are as follows:
By Department: for example, procurement, sales, planning, production workshop, finance, statistics, and general manager;
Categories by function: such as document input, document review, document query, accounting, book query, statistical report, and system maintenance.
Different methods can be used to classify functional requirements at different levels.
Each function should be assigned a function number to correspond to the chapter in the Function Specification. The description of each function should specify the user's input, processing method, system output, and other requirements for this function. The functional requirements should also indicate the positions for using this function. Special functions required by the system administrator can be specified here. Non-Special requirements can be described in detail in the requirement analysis specification. For example, user permissions can be classified and operation logs are required.

Functional requirements and performance requirements are inseparable. General performance requirements are meaningless and must be specific to a specific functional requirement, which is easily overlooked by analysts when analyzing the system.

These five basic elements can be described as a quintuple of organization, process, function, data, and business collections. for users, they are used to looking at the system from the perspective of organization and maintenance, that is, the positions in a department, the activities (functions) of the processes involved by each position, and the data on a function, what logic is processed for the data? developers are used to looking at the system from the function dimension, that is, what data is operated by a function and what logic is processed for the data, which process does this function belong to and where it can be used? Designers may be accustomed to looking at the system from the data dimension: that is, what data is in the system and what processing can be done on the data, these processes use the OO idea to operate data objects.

The above five basic elements are actually the process of system modeling. To ensure the operability of the model, in addition to the above five basic elements, the following content must be described:
(1) changes brought about by the new system to the Application Model
This includes changes to the enterprise's organizational structure, job flow, document and book reports, and business rules.
(2) interface model of the new system
Use development tools to quickly draw out the user's operation interface, so that users can be aware of it. If time permits, you can connect the interface prototype with the database tables and fields to make a system prototype, that is, the quick prototyping method.

2. Four types of readers reading Requirement documents

The final purpose of the requirement report is to be read by people. Therefore, we must consider the readers of the requirement report. There are four roles that may read the requirements documents of the enterprise management system:
Business Executives of customers and users;

User's middle-level management personnel and specific personnel;

User it supervisors and developers, including designers, coding staff, and peer experts;

Project management personnel: including project managers, Quality Assurance personnel, testers, requirement administrators, configuration administrators, and planners;

Different readers have different reading requirements for documents, and their attention is different. I have seen many request review failures (I will write another description if I make a good demand Review). In summary, I think it is very relevant to the Requirement Description that does not differentiate the reader group. For the above four categories, we will analyze the characteristics of each category of readers:

(1) Business Executives of customers and users
The enterprises they care about are the target requirements of the system, the overall functional framework of the system, the management problems solved by the system, and the specific requirements, therefore, the documents read to them should be described in general and should be highly abstract. Since their work is very busy, it is difficult to read these materials for a long time. Therefore, to be brief and clear, do not use two pages to describe the problem on one page, in addition, it is generally necessary to provide demand reports to the senior management, which must be accompanied by language instructions. Therefore, the use of powerpiont films has become a common method. The demands and discussions should generally be kept under control for less than one hour. The problem that demand personnel often make is that they pay too much attention to the detailed requirements of enterprises and ignore the targeted requirements of the system, therefore, in terms of the steps for obtaining requirements, the preparation of demand reports often fails to grasp the problems most concerned by the enterprise's top management and the fundamental problems, it is of course difficult to pass the review when reporting to the enterprise's senior management.

(2) User's middle-level management personnel and specific personnel
The enterprise's middle-level management personnel focus on the local needs of the enterprise. They require a general understanding of their local systems and a good connection with other subsystems, the business process is smooth, covering all the business processes you need, and you can control the process through the system. Specific operators are more concerned about whether their activities can be processed in the system, and whether the software can be easily operated. The focus is more specific and the requirements are more intuitive. Therefore, readers of this type can describe their needs through more detailed documents. Of course, they should describe the requirements in the way they are used to, rather than from the developer's perspective. I have seen many hundreds of pages of Requirement documents for users to read and review. The results can be either left blank or cannot be understood. Why? First, developers can further describe sub-systems, sub-modules, and sub-functions in the document, which does not meet users' thinking habits, they want to consider issues from the perspective of business processes and activities, rather than functions. Second, there are too many documents that users do not have time to calm down and digest and absorb, after all, the demand is not a novel, so it can attract readers.

(3) user it supervisors and developers, including designers, coding personnel, and peer experts
Most analysts may be best at writing this type of documents. This type of documents is often used by all readers. We have mentioned the problem above, we will not go into details here.

It should be noted that the traditional method is to describe a requirement based on functions. In fact, it is also a good way to describe a requirement based on data, in the quintuple we mentioned above, from the data perspective, the analysis system can easily achieve switching to OOA and Ood.

(4) Project management personnel: including project managers, Quality Assurance personnel, testers, requirement administrators, configuration administrators, and Planners
This is also a common problem for analysts. In fact, managers are most concerned with the requirement list.

On this basis, the project manager and Quality Assurance personnel can enter the project planning process accordingly, and testers can enter the test planning process accordingly. The requirement administrator and configuration administrator can identify the configuration items to develop relevant activity plans. Without this table, it is difficult for administrators to efficiently carry out their management activities, and the most basic requirements cannot be discussed. In the above table, the priority of the requirement is a very important column. It is very important to make a balance decision for the project manager on project management. In fact, the priority of the requirement may be more important than the requirement itself.

3. Requirement Description

As we mentioned above, the requirement document is a document for interaction between people and a document for interaction between different types of people. Therefore, the readability of the requirement document is an important aspect, to improve the readability of documents, you can refer to the following practices:
Use links appropriately in the document description to enhance the readability of the document;

Use the exhaustive method to identify missing demands;
Use appropriate line breaks to improve readability;
Highlight important content in a variety of ways, such as italics, italics, underscores, and colors;
Define standard terms to reduce ambiguity and document pages;
In the description of functional requirements, similar and unified functions can be described separately, referenced elsewhere, or defined as a term to simplify the document and reduce duplication. For example;
2 Input Function
2. Print
2. Conditional Query
2. Sorting

Knot

Even if you have done this in accordance with the above method, do not expect to write a document that can reflect all the features required, no matter how you refine, analyze, comment, or optimize your needs, it is impossible to achieve perfection, but you can be "acceptable ", write a requirement recognized by the customer, user, developer, and management personnel, instead of a perfect requirement.