Six key themes about software requirements

Karl Wiegers
Analyst’s corner
Published in
3 min readSep 12

--

Image by Annette from Pixabay

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…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com