Demand analysis and demand management: Managing the needs of a good product

Article Description: The change of demand is the main reason for this result, another factor that cannot be neglected is that the requirement is not stated clearly, and the developer is unable to complete the established development work in the face of vague requirement documents.

Recently a series of things began to teach me, if you can not do the job of demand management, product personnel are struggling to cope with the changing needs, resulting in the normal development of product design and management work. The result is that the requirements document that is delivered to the developer is constantly changing, and the developer is not sure what to do with the project, and the progress is slowing down. Finally to the stipulated good delivery time, because cannot get the output which needs, the department starts shifting, complains.

Thinking for a long while, the change of demand is the main reason for this result, another factor that can not be neglected is that demand is not articulated clearly, developers face the vague requirements of the document, more unable to complete the established development work.

How to articulate a clear need? We need to do two things as well as possible: 1. Fully establish the user case;2 of the product. Strive for clear, complete, consistent, and testable four points in the requirements document. Then the impact on the product, the development of the work can be minimized, your project will be able to complete within the time required.

How to build a product's user case Diagram

The user case diagram is also called a use cases diagram, based on object-oriented ideas and user perspectives. The following figure is a very simple use case diagram that resembles the user role of creating a product, and you need to be able to describe how the user is doing the product step-by-step from the perspective of use.

Use cases this is a bit of a black box concept that tells the story to describe the requirements clearly, but the flaw lies in not being able to describe how to implement it, and it rarely involves internal information. Once we encounter an inability to understand the product implementation mechanism or the internal process architecture, we must use other methods to understand the requirements, this process can be understood to open the black box. So by constantly observing the black box, open the black box, analysis of the black box, and then open the black box process, we can do the whole product demand has more accurate grasp.

A use case diagram is such a way to help us understand the requirements, of course, if we expect programmers to see the use case diagram to make the program, that is quite a nonsense ...

Because the use-case diagram itself is only used to explain the user's needs, it is difficult to accurately give the product's function, architecture, strict description and definition. Therefore, we also need another deliverable to clearly express the product's function, process and architecture, such as product requirements documentation.

Several basic elements of the product requirement document:

The corresponding products are different, the requirements of the standard is not the same, but there are some common elements, still can be used for reference:

Clear : Many people who write requirements documents do not learn formal languages, so many of the requirements documents we see are written in natural language. The biggest drawback to the demand analysis is its two-semantic nature. Therefore, we need to make some restrictions on the presentation of the document, for example, as much as possible only with the basic expression of the subject-predicate object, avoid modifying the sentence, avoid the easily misleading expression.

For example, we are a Social Security card system, you can describe the requirements: Each bus IC card can only belong to a user, social security card number and number of cards. Social Security cards can be used in hospitals and can be used to pay for medical expenses.

Integrity : Neither in the demand to say there are some needs are not confirmed, and do not develop near completion of the proposed to some of the requirements are missing. The incomplete demand is the most direct factor leading to the development rework, and is also a heinous behavior.

Requirements of the integrity of the product staff have a good product management skills, but also need to have a clear understanding of the structure of products, many times the product personnel are facing the head or the provisional decision to put forward the demand, it is difficult to first time to refine the complete demand, how to do? Ask! Ask yourself, ask your client, ask for development. Any delivery to development is doomed to be irresponsible until you are able to identify the full requirements or the minimum core requirements.

consistent : Simple requirements can be divided into business requirements, user needs and development needs of three aspects. The need for user needs to be consistent with business needs, development needs to be consistent with the needs of users, this is not nonsense, but three of the requirements of the inheritance relationship. Otherwise, the hard work of developing things is likely to deviate from the original achievement goal. In the implementation of the image, this consistency must also be refined. Often user needs change throughout the process, creating what is called "demand Change", which should not exceed the previously established scope, at least not beyond the initial business objectives.

testable: Many people think that the project, the product test should be from the completion of the code output test product start up or say that the development of the code should start to perform the test of responsibility, so understand that there is a reason. But in fact, as with completeness, the process of testing should begin when the requirements start to be analyzed.

As input and reference for the test, the requirement analysis should be testable. For example, we say "design a website, can let user first time understand ticket market". Is this requirement testable? Of course not! Does the ticket mean the train ticket, the bus ticket or both? Know what the ticket quotes include? These are not explained in the requirements, but also means that it is not testable, not testable.

Therefore, including the previous requirements, our aim is to ensure the testability of the requirements. When and only if all requirements can be tested, it is possible to ensure that the product from requirements analysis to design development to final delivery is really around the business objectives and user needs. Products can be more close to success.

How to solve the "changes in demand" brought about by the problem, for this "world problem" I can only say see recruit, after all, this is a project development in the external cause of the anti, many times not product managers or project managers can be around. In the object-oriented development model, what managers can do is to avoid as much as possible the planned delays that may result from changes, and for product managers, not only to control progress, but also to grasp the impact of changes on core functions, because you are the helm, you are the "Chief designer".

However, there is a sentence: ignoring the requirements of the process or changes in requirements resulting in project rework is the biggest factor in project failure, a large number of project failures are often doomed in the demand phase. As a product manager, you might as well take a look at your work and find out what's wrong with it.

Examples of two typical requirements changes:

1. Demand personnel verbally put their ideas and developers to communicate, then dropped a word: these places have not been discussed clearly, do not go to the tube, you first do it, and then after a period of time and put forward a new demand, completely regardless of the different needs of the development work impact.

2. Tell the developers to do a XX product, but now they are very busy, want developers to follow other similar products to do one out.

Both of these situations cause the project to be unsuccessful, especially when some laymen pretend to be insiders ...