Six Key Themes About Software Requirements

For more than 35 years I’ve been learning, applying, and teaching about ways that software teams can improve how they develop and manage their product requirements. I’ve observed six requirements-related themes that pertain to every project, regardless of what you’re building or how you’re executing the project. Keep the following themes in mind as you select requirements practices to use on your projects and tailor them to suit each situation.

1. Requirements development demands an incremental and iterative approach. It’s highly unlikely that anyone will think of all the requirements before development begins and that they all will remain static. People get more information, have fresh ideas, remember things they had overlooked, and change their minds. Requirements—and teams—must adapt to changing business and technical realities. All of this shows the value of progressively refining preliminary requirements into suitable levels of detail before commencing development, but not too long before.
2. No matter how you choose to represent requirements knowledge, the goal of all specification activities is clear and effective communication. The artifacts that a business analyst, product owner, or product manager creates have multiple audiences. Those audiences may wish to see information presented in different forms and at various levels of detail. Consider how to communicate with your various audiences as you produce requirements deliverables.
3. Requirements engineering is a collaborative process. Requirements affect all stakeholders. Many people can supply input to the requirements, many people do work based on them, and many people use the resultant solution. Customer engagement is a powerful contributor to a successful outcome. The analyst must work with people who can accurately present the needs of diverse stakeholder communities. Most requirements decisions involve multiple participants with different, and sometimes conflicting, interests and priorities.
4. Change happens. A solution-development effort is chasing a moving target. Business needs, technologies, markets, regulations, and users change. A BA must keep up with evolving needs and make sure that changes are clearly understood, agreed upon, recorded, and communicated to those they affect. But don’t use the reality of change and the ability to adapt as an excuse for skimping on requirements exploration beforehand. Thinking is faster and cheaper than re-coding.
5. A powerful way to increase development productivity is to minimize the amount of unnecessary rework the team must perform. Therefore, try to push quality activities to the front of the development cycle—that is, earlier rather than later. Better requirements pay off with less unplanned, expensive rework later in development or following delivery.
6. Use risk thinking to decide which requirements practices to employ, when to perform them, how much detail is necessary, and when to stop. For instance, the risks of miscommunication and wasted effort are greater when development is outsourced or teams are remote than when participants work in proximity. Therefore, plan to write requirements for such projects more precisely and in more detail than when developers can quickly get answers from the people around them.

Remembering these six themes can help any software team elicit, analyze, specify, validate, and manage their requirements more effectively.

====================

This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson. Karl is the author of numerous books on software development and other topics, including Software Requirements (with Joy Beatty), Software Development Pearls , and The Thoughtless Design of Everyday Things . Candase is a business architect at ArgonDigital. She has written numerous articles on best practices in requirements management and agile product ownership.