The needs analysis from writing to reading to discuss
1. put pen to paper / demand understanding
1.1 Background
We (started writing when demand for user / read the document), the first step is to understand the background of this demand arise. Typically, the analyst will be set forth in the business section of the user pain points to help developers fully understand the significance of this project we have done, the degree of understanding of this link, will directly affect the success or failure of the project results even.
1.2 Objectives and boundaries
Then that is designed to "target", the goal of the project is usually based on units of measurement, or target a certain stage of a project, the fast iterative agile team is a milestone.
The ultimate goal of our discussion, is "to reach a consensus." And clear objectives, clear boundaries, was the first to reach a consensus we, therefore, in order to solve the business user pain points, we need to do this project right, but to what extent, to what kind of effect, it is according to the result of many factors (time, manpower, opportunity costs, etc.) to measure out. For example, a user only wants to fill out the form to the database, and provides simple functionality for simple queries, then we can not be unlimited divergence, full-text search queries made, or other intricate designs, it is not desirable. But if the user needs to have analysts predict that 80% of needs (based on user habits, data volume and other factors) will have the possibility of full-text search, then the developers realized early in the design scheme, you can spend a small amount of time for the full text retrieving the interface design aside, when the user really need this feature, do the implementation of this interface. On the contrary, if we do not predict user may demand, the development has not set aside the interface design according to forecasts, the cost of late changes are often huge.
We learn database design paradigm, the principles and purposes of programming design patterns, nothing more than this.
Therefore, "the goal and boundaries" This issue clearly written or ask, is the basis for understanding and discussion of demand, but when demand for the user to change the basis for the project cost considerations.
2. Project Dependencies
Micro current service is so popular is because of its "micro." "Micro" means fast, fast development, fast on the line, fix fast. In today's volatile environment, user requirements, means that we can quickly start a project in order to minimize the cost to small trial and error. This is also reflected in defensive programming ideas, its core it is a measure of the opportunity cost. Also do a project, it takes 3 Zhou made a rough version to users and continued iteration 3 months and cost 3 to give the user after months of use, which deliver more meaningful value for the user is obvious. Moreover, waiting for you 3 to make the project months, the market and demand has long been changed.
But micro, bringing the cost of micro and services is the hidden development costs increased operation and maintenance costs. No DevOps , no micro-services (this is a chicken-and-egg problem, do not discuss this with me). With more and more small service, complex dependencies and relationships between projects, the development team has become a nightmare.
Therefore, the role of each team member, shall have the platform to project a clear understanding, at least there should be a cheat sheet, which projects which function, which outputs the data. I look at the current write requirements documents, business processes is where to start, the data from which to project the persistence of data which projects you want to subscribe, and so these are the issues we should focus on.
The current team technology platform is still in the initial stage, our standard library and many other infrastructure is still under construction, in the process of developing business projects, the ability of the public service part of settling down, it is the common responsibility of all team members roles . Note that I said that all the characters, not just the developer of this role.
In a word overview of: stroke along the dependencies between projects, sorting out which projects and which interface data are more dependent, which services we sedimentation / interfaces for utility services / data.
3. Functional Decomposition
Functional decomposition is to support the idea of "decoupling." Releasing the modules, functional coupling between the function calls between the modules through the interface or service, the code reuse rate can be improved.
Level level functional decomposition is relatively simple, such as sending voice and face recognition, which may be two completely different functions in groups outside programmers. However, if from the programming point of view to decomposition, it requires a degree of abstract thinking from the direction perpendicular to decomposition up.
Voice recognition and sending the same example, with some experience in the developer, which will be broken down into "basic communication layer" and "data processing layer." The method of communication could be the basis of a WebSocket , it may be Stream or the Http , and because of their diversity, must be made to provide support abstract interface specific implementation. Data processing layer will face data and voice data as input data for persistence, in the eyes of programmers, they are just different forms of data, not two completely different data. So, at this level, the programmers will do two projects is a basic service, to provide communications services and the other is business services, providing service interface and data persistence. The break out of this basic service, will provide technical support for the follow-up similar business requirements, thereby reducing development costs at the level of the platform, to improve development efficiency.
To sum up, send voice and face recognition this case, in the eyes of programmers, analysts and users as well as demand, the UI in the eyes of designers, are two completely different design ideas and decomposition. When we speak of functional decomposition, we have to realize that "feature" is the word, different people thinking there is something different.
Therefore, the role of each member of the team, you need to own the envisaged functional decomposition say it, we need to tell you why I was so decomposed, so what good decomposition, such as how to break down customer service and value.
4. User groups divided
There is no clear distinction between user groups, made out of project-oriented user groups blur function, we get user feedback is often the sentence: does not work well.
We often see some systems with the configuration of the system administrator role is responsible for the average user role is responsible for data entry, and the role of leadership of the report can not just look at the data entry operation.
In fact, we write / read the requirements document in the process, I also need to figure out write / user groups to read the function-oriented to address the pain points of the business which user groups. You give A group show users / Operation B group the user's business pain points, apparently A group of users simply do not care about the authenticity of the timeliness and accuracy of data. Such and such, final result is that poor user feedback, the results of the entire team of labor in vain.
5. quadrant classification
Quadrant classification method is very popular in various industries and jobs of work skills. In the project implementation plan, available from:
v main functions necessary requirements
v-chip peripheral functions necessary requirements
v peripheral functions, auxiliary needs
v The main function of the auxiliary demand
Four aspects of the project, modules, classified, what good is it doing this?
The first thought is that users maximize the value and reduce the implementation risk, while as the basis for our iteration. More powerful, simple Quadrant, but also help us to achieve against all kinds of risks.
Think about it, seeing the project to be postponed, and developers have long core functions well, at this stage are doing a periphery of the auxiliary function, we can not be on the line this time?
Project development depend, development risk, service / module / function dependencies can be expressed in this quadrant diagram. It can be said that the better the picture, do you project more successful.
6. summary
In summary, we write / read the requirements document when it is need to have an efficient method, can not say that I feel very uncomfortable at this point intuitively, I'll have to write again pondering the discussion, but first outline set out , categorized draw focus (user groups, classified quadrant), focused on solving the core issues.
Similarly, we together to discuss business, design or implementation of the time, also need to be prepared ahead of time, what my question is classified into which quadrant, which addressed business pain points which user groups, how long it takes the discussion is worth it?
These are discussed before we put pen to paper or need to be prepared, so-called before making any decisions.