What do we need to focus on?

What are specific requirements?

Although each of us is talking about "demand", what is "demand? We need to pay attention to the requirements, but what are the specific aspects of the abstract "requirements? I think it is worth the attention of each of us, especially our analysts and designers.

From the book "Exploration needs-quality before design" between Goss and winborg, we can get some inspiration: when focusing on needs, we need to focus on several specific aspects, that is, functions, attributes, constraints, and preferences.

You should be familiar with the functions and attributes. A software product is needed because it has certain functions. To meet the specific functional needs of users (such as sensory and performance), we must make the product have some attributes.

As for constraints, it is also easy to understand what attributes a product must have. This is the constraint. For example, the product must support keyboard (no mouse) operations. When some functions are implemented, there are also some constraints, such as permission control. For example, the product stability (such as MTBF) must be achieved.

"Preferences" refer to some implementations of attributes, which are not necessary (so users can accept them without these attributes ), however, some conditions can be improved to improve user satisfaction. For example, the "Exploration demand-quality before design" once gave an amazing example: in some products, development time is a constraint, and in some products, development time is a preference.

Are you exploring your needs correctly?

Here, you may ask: After talking so much, what exactly does the author want to explain? In fact, I want to ask another question:Are you sure you have correctly defined these aspects in your demand work?? Are you sure you want to find the correct method?

Aspects we may ignore when using case Modeling

Many projects are currently using use cases for modeling. Use Cases are good, but the emphasis on Functions of use cases is easy to ignore other requirements.The information reflected by the use case diagram is even more pitiful..

People who have written use case documents may be most impressed with successful scenarios and branch processes numbered in sequence. These functional elements are so important that we often ignore other parts of the use case. Are there only a few constraints in your case document, such as "users must have logged on? Is there a "User vision" or similar part in your case document? Your use case document only shows the most important constraints you think, or the constraints column only describes the constraints that affect the function execution, what about the lack of attribute constraints?

Of course, we must acknowledge that the features of the product are the most important aspect of the user, because it is the reason why the user pays for the software. However, ignoring other aspects may lead to software failures, so we cannot ignore them.

How can we get them?

Getting information is a big problem. Users do not understand our language, and we do not know what they are thinking. How can we know what they are thinking? I think the most important thing is to think from the perspective of users and think about the starting point of what they describe. If they are more professional and concise, they will understand their "vision ".

Most of the time, there will be situations like this: Ask the user: "Do you really think these reports are enough ?" The user said, "I think it should be similar. Besides, I cannot think of anything else ." As a result, the product was put into development. After a while, the user suddenly rushed over and said, "I think we still need to add another report ." So the two men quarrelled.

What are we going to explore?

What we want to explore is not only what users say, but also what they say.Motivation. If you think you are a qualified demand analyst, you should seriously discuss with the user from the user's standpoint,Why do we need these requirements?What kind of vision is hidden behind it,What else do we need to achieve these visions?.

Are the people who want to increase their demand all dummies?

Someone will laugh at this practice. Software companies are eager to make money, and users cannot think of some of the functions. Even if the demand personnel think of them, they will deliberately leave it out. Why? People who don't mention it have their reasons: when the customer pays the same cost, isn't the fewer features that need to be developed, the better?

This statement may make sense, but the premise is that you can never ask the customer to come up with these things forever (at least before the customer pays. Customers with money can do a lot of things. Why do they have to spend the money on software projects? It is because our software can help them solve some problems, which are accomplished by what we call "functions. If our software doesn't help them achieve this purpose, the final result will surely fail.

The requirement is determined by the vision. If the product can only meet some of the requirements (the other part is hidden or not discovered), the vision is not met, one day, the user will suddenly understand that the product still lacks some features. This day may already be a trial run after the product is delivered, and you will pay a higher price if you modify the product again. If you do not modify the settings, the customer will make a fight with you. The requirement analysis personnel must understand:A clever person will be punished in the end..

Therefore, do not go into the user's mind and explore what they want their products to look like.

Demand will change constantly because the user's vision is not being identified.

"User requirements are always changing." This is the most widely spoken phrase (from management to technical personnel) from various software practitioners ). My opinion is slightly different. I think the reason for the change in demand is largely because we have not identified what is a real demand at all.

You may ask: Are there any false demands? I think at least we can say this: there are some requirements that are just representations. Because we have not touched on the most fundamental visions under these representations, they are likely to change constantly. The target of the Demand Survey is a variety of users, and users are just ordinary people (like us). When ordinary people have vague minds, in addition, everyone's knowledge also has limitations.

For example, the user said: we need the system to print these sales statistics. Why do we need to print the data? The user continued: Because the leader needs to check it. Why are leaders looking at this data? Because he needs to determine the number of plans for the next phase of production. Therefore, the leaders need to determine the next phase of production is the real demand, and "print sales statistics" is just a representation. If we only implement the "print sales statistics" function, this demand may change, because the sales statistics may not be enough to become the decision basis for the next growth period.

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

In fact, the real demand may change, but this is related to the user's market or environment, or the user's business decisions may change. However, the probability of such changes is not high. If the user's situation and his decision-making have not changed, but the demand has changed, it means that we do not understand what they really want: we may just see the appearance.