SHOW NOTES
Jerry Weinberg had a tremendous impact on our world. That includes his teaching, writing over 40 books and 400 articles, and helping to send a human into orbit around Earth.
Jerry joined us about a year ago in episode 130 where he talked about exploring requirements. Today’s episode includes some extras from our discussion and Jerry shares some of his thoughts about requirements.
The Reason for Requirements
Never forget that we use requirements to solve a problem, not to get people to write software code. The requirement is not to write a software program. The requirement is something that satisfies a person’s need.
Cautionary Tips from Jerry
We often don’t take requirements seriously until we feel the impact of a missed requirement. You must take requirements seriously or you’ll suffer the consequences.
When people say “don’t worry about that”, that’s the time to worry. Explore this further and ask why we shouldn’t worry about that. It often means that there are underlying assumptions that have not been validated.
Bringing Humanity to Requirements
Take the time to make sure you have the right people involved and you’re listening to them without bias. Learn to be a more accepting listener and learn to value the expertise of other people.
The requirements process is an iterative process. You can’t just get it right in one shot. It’s not something you do at the beginning of a project and then forget about it.
Set a reasonable goal and allow for testing and iteration. If you don’t test your requirements, there are going to be problems.
The requirements process is a first step in building a team. Let people interact in a way that leads to better team building.
Requirements for New Products
If you’re building requirements for something that’s entirely new, look for something that is like what you want but perhaps from another industry. To get it right, you’ll need to test.
Build things incrementally. You don’t need to create all your requirements up front. You do need to determine if the requirement is needed at all. Does the product satisfy a customer need?
From there, you can test using mockups or prototypes to ensure you’re on the right track. Remember that you’re building systems to satisfy people.
Start by honoring that people may not be able to tell you what they want, but they’ll know what they want (or don’t want) when they see it. You need to give them something to react to.
Watch the Detail
The top level of requirements is “what is it that the customer is really trying to do?” The problem is, we often work at the wrong level of detail.
We need to be able to speak less precisely at the beginning of the process. As we progressed through iterations, we can get more detailed as we test and learn.
When we define solutions in much detail, we take away the creativity of software engineers and those developing the solution.
Be sure to honor both sides of the equation. Customers at some level know what they want and know what they don’t want. Engineers and solution developers know how to create the solution for the customer’s problem.
Listing to this episode to get Jerry’s advice on taking requirements seriously, iterative development, when to get into detail, and treating people with humanity.