A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
The Software engineering project is to rebuild the Office business Process management platform, need to inherit the original 370 processes on the basis, but also need to provide rapid process development capabilities, and requirements to reflect the normative process management, as well as the execution of the process, efficiency, effectiveness, and ultimately for enterprise management innovation to provide process reengineering capacity.
In the early stages of the project and in the requirements analysis phase, the developer is committed to "cost reduction" to complete the project at minimal cost, and its predictable software products are upgraded through a system platform and a second improved Office business process management platform. According to customer acceptance requirements, "can only play 60 points, is not allowed to accept."
In the software development, the demand work is committed to solving the problem of "good product selling", and the design work is devoted to solving the problem of "reducing cost". They cannot be substituted for each other. If demand and design are not divided, profits will shrink. Mapping the design directly from the requirements leads to the decomposition of the function to get duplicate code. If you look for demand from the design, you get a lot of fake "demand".
Take an example of a system "human body" that has existed since ancient times. The external function of the human body is to walk, will run, will jump, will lift weights, will throw, can swim .... However, when designing the internal structure of human body, we can not directly map to the design from the demand, get "walking subsystem", "Running subsystem", "jumping subsystem" .... The "subsystem" of human body is "respiratory subsystem", "digestive subsystem", "blood circulation subsystem", "Nerve subsystem", "Endocrine subsystem" ...
First, review our common software requirements development process.
1. Definition of requirements Analysis
In software engineering, demand analysis refers to all the work that is required to describe the purpose, scope, definition, and functionality of a new system when building a new or changing an existing information system. Demand analysis is a key process in software engineering. In this process, the system analyst and software engineer determine the needs of the customer. Only after these needs have been identified can they be able to analyze and seek solutions to the new system. The task of the requirements analysis phase is to determine the functionality of the software system.
2. Overview of the demand development process
To guide the project team to objectively and accurately identify and document the needs of customers and related stakeholders, and to complete the analysis and documentation of the software requirements based on the identified user requirements.
(2) Role Responsibilities:
Account Manager: Assists the project manager in the communication and demand acquisition with the customer.
Project Manager: Responsible for the whole process of the management of demand identification. Communicate with customers in time, understand customer needs, review customer requirements, and coordinate the assessment of demand identification.
Project member (requirement developer): Assist the project manager to complete the collection of customer requirements, collect the requirements, through analysis, collation and production of documents, assist the project manager to review the collected customer's initial needs.
Customer representative: As complete and accurate as possible to the requirements of the system's objectives, functions, performance, technology, interface, security level and other needs. and confirm the result of the requirement review.
User representative: Provide business requirements for customer representatives and project members, and confirm requirements results.
All materials related to customer's needs.
Original Requirements Index Table;
user requirement Specification;
Requirements Acquisition Analysis table;
requirements use case documentation;
Software Requirement Specification
(5) Development process
3. Key development Activities
(1) "Confirm user needs" activities, not only to form a user requirements Specification (format, only requirements to describe the requirements clearly), but also must have a customer representative signature confirmation, preferably with the user representative to confirm the signature.
(2) "Review requirements Document" Activities, can not be omitted, the need for system analysis, designers to fully understand, analyze the requirements, confirm that the requirements analysis described clearly, and do not go beyond the scope.
(3) "Create and publish a requirement baseline" activity, which solidifies the requirements and requires the creation of a demand tracking matrix.
Next, we will focus on demand analysis.
Demand analysis uses the UML modeling tool EA to conduct business modeling and development of demand use cases and object models through EA. This segment focuses on the business modeling practice process and what does the Office business process platform do?
1. Business Modeling
It is not appropriate to articulate 370 business processes on a business modeling use case diagram, and the functions of these processes are basically consistent. Process business is usually the case, the staff fill out the Business application form (fill out the form), and prepare the relevant information (add the attachment), the Business application form and information packaging (save), sent out to the process of the next step of the approver processing.
Now that you are managing 370 processes and are constantly changing processes, start with process modeling, go to the process line application, execute process instances, and monitor and analyze processes to perform performance management of the process. In this way, the process reengineering is the eternal theme, which is also to answer the office process platform to do what. As for the rapid development process, monitoring and analysis process, as well as performance, efficiency and other management objectives are the surface needs. Business modeling is to provide the support of effective process reengineering through information management model, so as to achieve the ultimate goal of management innovation.
Through the above analysis, business modeling does not need to draw specific process use cases, do not need to draw specific report use cases .... 3 is the Office Business process Platform System core business model use cases, and the tariff approval process, the middle-level leadership leave process ..., just the process model "Note: The regulatory process (definition) information in Figure 3" is different.
The business model application simple scenario is as follows:
(1) Through the rapid development process (modeling process) use cases, the development of the tariff approval process model, and publish the process;
(2) Application, approval process use case, is the execution process example;
2. System Platform Modeling
This system platform use case, should not be placed here, but, because of the particularity of this project, one of the construction goals is to build office capacity platform, so there is a system platform modeling, can also be seen as a system use case. The concept is a little vague, let's put it here first.
Why are requirements often "easy to change"? One of the root causes is their antecedents, the first time is to shoot the head, did not put the system as a part in the organization, the system of course and the other parts of the organization are incompatible with the system on the run-in after the discovery of problems, nature to change. "Drastic changes in demand" is only an illusion, many changes in demand are false changes, the real demand has not changed, but the developers at the beginning to capture the demand is false. If business modeling skills are used correctly, most fake demand changes will be eliminated from the invisible.
A business use case is a use case for an organization, not a system within an organization. The use case of an organization does not change because of the existence or disappearance of a human flesh system or computer system.
In summary, the software project needs development process, business modeling is a very important activity, directly related to the success or failure of the project. In essence, this project is a user-oriented BPM, such as solving the problem of cross-organization of people, and providing statistical support requirements for process business data.
References and excerpts from:
"Software Method" Umlchina Pangayu 2012.11
Easy-to-expand core model of Office process Management (1th edition) Sho Yongwei 2015.1
Using MONGODB Database to manage document forms and information in Office system--General process application approval list design ideas (two, cont.) Sho Yongwei 2015.1
Business modeling use case diagram of software project requirement development process Practice
Start building with 50+ products and up to 12 months usage for Elastic Compute Service