How to Build Winning Products by Microsoft Sr. Product Manager
Requirements
1. Requirements
Why Dr. Evil Couldn’t Get His Sharks With
Freakin’ Lasers On Their Heads
Lunch and Learn
6 August 2009
Harry Marlin
2. Why Requirements?
A customer wants something
You want to give it to them.
How do you know what they want?
Requirements!
3. What are Requirements?
• Requirements are
– A specification of what should be
implemented
– A description of how the system should
behave
– A constraint
A “contract” between the user and the
developer
4. Requirement Types
• Functional
– Functions the system should provide
– System Behavior
– Austin Powers shall die
• Non-Functional
– Speed, reliability, size
– Fish shall skeletonize a person in 30 seconds
– The death shall be slow and agonizing
5. What is a good requirement?
• Complete
• Unambiguous
• Necessary
• Describes one item
• Feasible
• Necessary
• Testable/Verifiable
Should define WHAT not HOW
6. The Customer/Stakeholder
• An individual or organization who benefits
from a product
• May: • Pay for • Select
• Specify • Use
• Receive output
Should “sign off” on requirements before
development
11. Conclusion
• Requirements give the customer what
they really want
• Good requirements are hard to make –
but critical
• Changing a requirement is easy, changing
a system is hard
Sometimes Sea Bass are better than
Sharks!
Editor's Notes
Our Customer intuitively understands what outcome he wants, but never really specifies his requirements. He expects his minions to give him exactly what he wants, and is peeved when he doesn’t get it.
Number 2 is like many developers – the customer wants something, and we can’t provide it, so what is the next closest thing which would fulfill his wants. In this case, it worked out well – but that’s also because Number 2 had a long relationship with the customer beforehand, and understood what he wanted to accomplish.
Our next developer thought a little deeper about what the customer actually wanted to accomplish, although he fell into the classic mistake of offering a solution, rather than defining the requirement.
----
The customer *really* didn’t like his idea, and you may have heard this last part at some of our own meetings with our customer
