What do we need to focus on in the demand?

What exactly does the requirement contain?

While each of us is talking about "demand," what exactly is "demand"? We need to focus on demand, but what exactly does abstract "demand" contain? I think it's worth every one of us, especially the analyst and the designer, to focus on.

From Gauss and Weinberger, "exploring demand-quality before design," we can probably get some inspiration: when it comes to demand, we need to focus on a few specific aspects, namely, function, attributes, constraints, preferences.

Features and properties everyone should be familiar with what it means. A software PRODUCT, people need it because it has some features. In order to meet the specific needs of the user in the function (such as perception, performance), we must let the product have some attributes.

As for constraints it is also well understood that the product has attributes that must be, and that is the constraint. For example, the product must support keyboard (no mouse) operation and so on. Some constraints, such as permission control, are also possible when certain functions are implemented. For example, the stability of the product (MTBF, etc.) must be achieved.

"Preference" refers to some implementations of attributes that are not required (so the product is not acceptable to users of these properties), but if implemented, some conditions that can improve user satisfaction. For example, "quest for demand-quality before design" has given an amazing example: in some products, development time is a constraint, in some products, development time is a preference.

are you exploring the needs right?

See here, you may ask: "So much, the author of this article wants to explain a thing." In fact, I would like to ask a question, that is: in your needs work, whether you are really completely in these aspects of the correct definition . Do you know the right way to explore your needs?

aspects We may overlook when modeling a use case

Many projects may now be modeled using use cases, but the use cases are good, but the emphasis on functionality is easy to overlook other aspects of the requirements. The simple use case diagram reflects the more pathetic information .

The people who have written the use case documentation may be most impressed by the sequential number of successful scenarios, branching processes, and so on. These functional elements are so important that we often overlook other parts of the use case. The constraints in your use-case documentation are often few, such as "Users must have logged in". Do you have a "user vision" or a similar section in your use case documentation? Does your use case document reflect the user's preferences, or does it simply mean that the constraints that you feel are the most important, or that the constraint column simply illustrates the constraints that affect the execution of the function, and lacks constraints on the attributes?

Of course, we must admit that the function of the product is the most important aspect of the user, because it is the reason that the user pays to buy the software. But ignoring other things can lead to software failure, so we can't ignore them.

How do we get them?

Getting information is a big problem. The user doesn't understand our language, and we don't know what they're thinking. How do we know what they're thinking? I think the key is to think in terms of the user, to think about the starting point of what they are describing, and to be more professional and concise, to understand their "vision."

A lot of times, there is a situation like this: the demand person asks the user, "Do you really think these reports are enough?" "The user said:" I think it should be almost. Besides, I can't think of anything else now. So the product was put into development. After a while, the user suddenly rushed over to say: "I think we need to add a report." So the two of them quarreled.

What are we going to explore?

What we're going to explore is not just what the user says, but also what they're motivated to say. If you think you are a qualified demand analyst, you should seriously stand in the user's position and discuss with the user, Why we need these requirements , hidden behind what is the vision, in order to realize these visions, we need something else .

Those who increase demand are fools.

Some people will laugh at this practice. Software companies are in a hurry to make money, users can not think of some of the features, even if the need to think of people, they will deliberately do not say. Why is it. People who do not speak out have their reasons: the difficulty in paying the same cost for the customer, the need to develop the function is not less the better.

This may make sense, but only if you can always (at least before the customer pays) not ask them to come up with these things. Customers have money to do a lot of things, why they have to spend the money on software projects. It's because our software helps them solve problems, and these problems are done with what we call "functionality." If our software helps them not to achieve this goal, the final result must be a huff.

And demand is determined by the vision. If the product can only achieve part of the demand (another part or be concealed, or have not yet been found), then the vision is not met, one day users will suddenly understand that the product also lacks some features. This day may already be a trial run after the product is delivered, and at this point you will pay a greater price for modifying the product again. And if you do not change, the customer will and you to the end. The person doing the demand analysis must understand: the smart person will be punished in the end .

So, do not mind have distractions, down to the user's heart, to explore what they want to be what the product will look like.

demand is constantly changing because the user's vision is not being identified

"The user's needs are always changing", which is one of the words I hear from our various software practitioners (from management to technicians). My view is slightly different, and I think: the reason for the change in demand is largely because we simply do not recognize what is really needed.

You might ask: Is there a real need, or is there a fake demand? I would like to say at least that some of the requirements are merely appearances, and because we have not touched upon the most fundamental visions under these appearances, they are likely to change constantly. The object of demand survey is a variety of users, and the user is just ordinary people (like us), ordinary people have a vague mind, and everyone's knowledge has limitations.

For example, users say: We need the system to be able to print these sales statistics. Why do you need to print this data? Users continue to say: Because leaders need to see. Why do leaders want to see this data? Because he needs to decide the number of plans for the next phase of production. So leaders need to decide the next phase of production is the real demand, and "Print sales statistics" is just a representation. If we only achieve the "Print sales statistics" function, then this demand is likely to change, because sales statistics may not be enough to be the basis for decision-making in the next period of growth.

If we recognize the user's vision correctly, then we can start from their perspective and explore what is the most reasonable solution. Such a solution is solid, because it has a solid foundation.

In fact, real demand may change, but it is related to the market or environment in which the user is located, or the user's business decisions change. But the odds of this change are small. If the user's situation and his own decision have not changed, and the demand has changed so-called, it means that we do not understand exactly what they want: we may just see the appearance.