The Overarching Goal of Requirements Development

Clear and effective communication. It’s that simple. There are many ways to achieve that.

Karl Wiegers
Analyst’s corner

--

A photo of two men talking to each other using tin cans and string.
Image by luis_molinero on Freepik

Software development is partly about computing and partly about communication. Requirements development, though, is entirely about communication. In general, we’re better at the technical side of software development than the human side. Those team members who lead requirements activities — I’ll call them business analysts (BAs), regardless of their job title — sit at the hub of a project communication network (Figure 1). They coordinate the exchange of requirements knowledge among all project participants.

A figure that shows the business analyst in the center with two-way arrows between several types of people in the customer domain and several types of people in the implementer domain.
Figure 1. The business analyst coordinates the communication of requirements knowledge among all project participants.

The communication links in Figure 1 are all two-way arrows. Some participants primarily supply requirements input to the project from the customer domain: project sponsor, marketing, key customers, and user representatives. Other participants lie in the implementer domain and consume the requirements process outputs: architects, software and user experience designers, developers, and testers. If your product contains both software and hardware components, electrical and mechanical engineers also could be involved.

--

--

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