Why I wrote this, because once when I wanted to go and explain the needs with the development, I was very flustered, although I have said it many times, but this time I was inexplicably flustered. I want to be prepared and methodical to explain this need well, and the previous explanation made me wonder what the methodology of the demand explanation was.
Now let me summarize the methodology, every time I explain the needs, do this well, and I will not be flustered.
First of all, what is the goal of expressing our needs?
(1) The needs are clear and can achieve multi-party recognition
Communicate with customers to confirm the needs through verbal expression to development, testing, development and testing can be from their point of view to question the requirements, and ultimately make the requirements more and more clear and accurate.
For people in need, it is a great Latest Mailing Database sense of accomplishment that the needs you express can be understood and recognized by others.
(2) Once passed the requirements review, it will not be called back
A request for development and testing of many issues will not pass the review, be beaten back, be beaten back to show that their needs are not clear enough, and need to communicate with customers.
Passing the demand review once not only shows that you can do what you need, but also saves everyone's time and cost.
(3) Improve your expression ability
Isn't it fun to improve your abilities with each thing?
Once you've made your purpose in expressing your needs, let's look at how you want to express your needs to development, testing, or others.
Knowing our goals, see how to effectively express the needs?
(1) Before the demand explanation
For a document and documented requirements, it is necessary to explain and develop tests, and some preparation needs to be made before the explanation, so that in the requirements review, there are fewer problems and less difficulties.
When writing the requirements specification, establish the requirements matrix and think clearly why you want to do this requirement? That is, what is the business scenario. 80% of developers will want to know what the reason for doing this feature is.
Communicate some difficult needs with demand colleagues, development colleagues, and test colleagues first, communicate in advance, and see what questions they will ask, anyway, offstage, and will not be embarrassed.
Ask for a demo, start with one of your own, like a speech, and assume that you are a developer about what questions you will ask.
(2) When explaining the needs
When opening the requirements document to talk about requirements, first talk about the total, then talk about the score, and finally summarize, just like writing the structure of the article: total - score - total.
Some developers only care about what they want to develop, and don't pay so much attention to some customer backgrounds and departmental businesses that he thinks are irrelevant, which will make you skip the overall introduction and then disrupt your rhythm.
But I want to say! You are the keynote speaker, and you have the right to control your own rhythm and not be led by the nose, except in the case of a special rush of time.
2.1 Introduce customers, user departments, number of users, business, function list, development function requirements, etc.