How to identify requirements
This afternoon, I joined a meeting of a component requirement. I have been a long time since I joined a requirement meeting last time. I found that I had forgotten how to identify requirements.
When the meeting began, I fell into details soon. At the middle of the meeting, a colleague came into it. His first question was:
“What’s the problem you want to solve by this requirement?”
I was shaken by this question. In the past, I would ask this question to the product manager. But now I have forgotten the methods of identifying requirements. This makes my questions meaningless.
So I decided to write the principles of requirement identifying down in order to make myself know what to do in the following meetings.
What’s the problem you want to solve by this requirement?
I must confirm the purpose of a requirement before we starting doing it. Every requirement must solve a clear problem for its customer. That’s also our goal of work.
Show me the quantified number
Quantified number is the best index to measure how important the thing is.
Such as:
- How many customers would use this product?
- How much money would this product make?
- How many new users would this new function bring to our company?
Give me the extreme data in order to consider the extreme scenarios
Extreme scenarios will crash the product if you don’t consider it carefully.
When will it be published to users?
We usually have a couple of tasks at a same time, so we need to rearrange schedule to push forward the process of the requirement.
What does the previous product perform?
We need know the previous product’s indexes so that we could know the outcome of our work.
The data will also tell us whether the product manager and designer are reliable or not.
The details
- Font size
- Breaking rules of the text
- Interval width between two objects
- Size of objects
- Zoom
- Resize
- Which platforms will it be shown on?