In-depth introduction to software development-(2) Game demand

(Reading Notes from iteye many years ago)

When I selected the title "demand game", I hesitated again and again, but I still used this title. This does not mean that you hold the game attitude when capturing and analyzing requirements (of course, this is also not appropriate ), it means that some of the methods we use in requirement capture and analysis are like playing games. The form is easy and the effect is good.

 

In the previous article, we mentioned that "a software or project originated from a user's idea". In most cases, the user's idea is general, vague, and incomplete. As a software developer, we are obligated to help users explore all their concerns, refine their ideas, clarify details, evaluate requirements, and prioritize them.

 

First, we need to explore the customer's needs to the maximum extent at the beginning of the project. Of course, we cannot obtain all the requirements, nor can we fully and correctly obtain each requirement. However, as iterative development continues, we will get feedback from users and adjust our demand list based on user feedback. These problems will be solved slowly . We have three methods to obtain the requirement: Bluesky brainstorming, roleplay , Observation .

 

• Bluesky brainstorming---- Unlimited brainstorming. All people who need software can use their brains to find out what I need to do for me? What kind of functions do I want my software to provide? Everyone should have an equal say and can speak their own ideas. As developers, we record all the ideas that can be collected, regardless of whether the ideas are practical or not. Because we need to understand all the potential requirements at the beginning, and our projects or software will still be developed based on the core requirements. What is the core requirement? This will be determined by our customers! However, what should I do when the brainstorming effect is not ideal. For example, users do not want to think about what they need software to do? Or you are not used to this method, or you can't think of it... this is the time for the two methods below to debut!

• Roleplay ------Role-playing: If your users feel it is difficult to describe "What does the software need to do and how to do it ". use Role-playing to show it. You play the software role, and the user tries to command you to do what they want to do. This is a more visual and intuitive way to get the user's needs.

• Observation----- On-site observation, sometimes the best way to understand how users will use your software is to observe their daily work and find out where the software can be cut in. First-hand information is the most authentic and accurate, and we can obtain detailed first-hand information through field observation. For the same activity, we need to observe several different people to obtain general information without being influenced by the individual's style of action. At the same time, we can also use "field observation" to obtain details or constraints missed in brainstorming or role playing.

Then we need to sort out the obtained requirements. Why do we need to sort out these requirements? This is because the customer's brief description is obtained, which may be incomplete or inaccurate. In addition, we also need a technology to write and name all the requirements in a uniform format, which is also conducive to the management of requirements, this is the time for user story to show their skills: user story (consists of two parts: Title and description)

 

There are many books and materials about user story for reference. I will not detail them here. Only list some rules that need to be followed when writing user story.

• Each user story only describes what the software does for the user.
• Use a language that users can understand. Do not use professional technical vocabulary.
• Written by the user or from the user's perspective.
• It is short and clear. Do not describe it in too long text. If it cannot be described in a short text, it is further split.

In short, user story should be described from the user's perspective so that both users and developers can understand it well. User story defines "what the customer need ?", The Demand Evaluation defines "when we can deliver them ?". The next article will describe how to evaluate the requirements.

In-depth introduction to software development-(2) Game demand