Timeless Pearls of Requirements Wisdom
Fifty Years of Development Experience
Dr.Karl Wiegers, a 50-year software development veteran, has written ten books on the subject, including two deep dives into developing requirements: Software Requirements (with Joy Beatty) and More About Software Requirements: Thorny Issues and Practical Advice.
This year (2022), Dr. Wiegers published a new book, Software Development Pearls: Lessons from Fifty Years of Software Experience. He then presented his five top pearls of requirements wisdom for Modern Analyst. The sections below list these insightful lessons, with comments from a Purposeful Architect perspective.
Lesson 1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.
Getting “the requirements right” means they cover the organization’s needs within a well-defined scope. It implies the development team will understand them. A solution built by the best development team with missing or misunderstood requirements will most likely disappoint stakeholders. They will have to restart the project from the beginning, costing unexpected time and effort.
Complete, well-understood requirements put a solution on a course to please the stakeholders.
Lesson 4. A usage-centric approach to requirements will meet customer needs better than a feature-centric approach.
Too often, stakeholders start a project by discussing a solution’s features without establishing what the organization needs from it. First, business stakeholders promote ideas to relieve pain points, while technical stakeholders feel more confident talking about features rather than understanding what's driving the need. Instead, business analysts should first capture and acknowledge pain points. Then they should establish a business context covering the organization’s needs.
A thorough usage-centric approach ensures the requirements cover the organization’s needs.
Lesson 6. Agile requirements aren’t different from other requirements.
Any development methodology, including agile, does not affect requirements. Developers need to understand them to build solutions right the first time. Agile development covers fewer requirements in a shorter time for each solution version. Its fine-grained approach reduces the cost of adapting to changing needs.
A development team’s requirements understanding has far more impact on solution success than their methodology. See Lesson 1.
Lesson 7. The cost of recording knowledge is small compared to the cost of acquiring knowledge.
A new team taking on a development project often “reverse engineers” the product to obtain information because it lacks documentation. Reverse engineering takes more time and effort than documenting the solution in the first place.
Instead, business analysts and architects should record their knowledge throughout the development process. They create documents and diagrams to show stakeholders their understanding of their requirements and how the solution would meet them. If they keep their artifacts current, they eliminate future reverse engineering.
Up-to-date documentation makes ongoing development easier for the current team as well as the next one.
Lesson 12. Requirements elicitation must bring the customer’s voice close to the developer’s ear.
Whoever elicits requirements from stakeholders should get them right, understand them, and communicate them clearly to the development team. A business analyst captures requirements with a product owner or solution champion in most cases. Both should understand the requirements thoroughly and have access to stakeholders when developers need clarifications.
Clear requirements communication keeps solution development on track for success.
Stringing the Pearls Together
Successful solution development starts with getting the requirements right (Lesson 1), including a process and user-centric approach (Lesson 2) rather than a feature-centric approach that can leave gaps. Next, business analysts and architects should verify they understand the requirements by reviewing up-to-date documentation with the stakeholders (Lesson 7).
When business analysts and architects finally understand and agree with stakeholders on the requirements, they communicate them to the development team (Lesson 12). Then, the team needs to understand the requirements for any development methodology they employ (Lesson 6).
A Plethora of Valuable Pearls
The Software Development Pearls book contains sixteen requirements lessons, plus:
Six design lessons
Twelve project management lessons
Eight culture and teamwork lessons
Eight quality lessons
Nine process improvement lessons
One bonus lesson on what to do next
The book includes stories, descriptions, and next steps for each lesson without getting into technical jargon. Business analysts and architects would likely find each pearl invaluable.
Sixty Software Development Pearls of Wisdom summarizes all of the lessons.
Karl Wiegers offers the benefits of his experience eliciting requirements and running software projects in Software Development Pearls: Lessons from Fifty Years of Software Experience.