A scary-looking hooded man in front of an electronic display.
A scary-looking hooded man in front of an electronic display.
Image by Pete Linforth from Pixabay

Thoughtful design of both software and physical products takes a usage-centered perspective rather than a feature- or product-centric perspective. Understanding who the users are, what they need to do with the product (their usage scenarios) and the usage environment is the best way to determine the product’s requirements and derive effective designs. Requirement writers, designers, and consumers naturally focus on the normal usage scenarios that lead to successfully achieving some useful result. Software people often refer to these kinds of activities as use cases — goals the user wishes to achieve with the product.

For effective requirements analysis and design…


A woman with a thoughtful expression standing in front of a blackboard covered with question marks.
A woman with a thoughtful expression standing in front of a blackboard covered with question marks.
Pattern photo created by creativeart — www.freepik.com/photos/pattern

A business analyst is not merely a scribe who records whatever customers say and passes the information to the development team. The BA needs to ask thought-provoking questions to stimulate the thinking of the people they’re interviewing. This article suggests some unobvious questioning tips for BAs to consider as they cast a wide net for requirements input. Keep in mind that an elicitation discussion is an inquiry, not an interrogation. Watch out for questions that could come across as aggressive or confrontational.

Probing Beneath the Surface

As well as exploring the functionality that customers bring up, the BA should help customers think at a…


An image of a human brain in a 3D prototyping machine.
An image of a human brain in a 3D prototyping machine.
Technology photo created by kjpargeter — www.freepik.com

Designing a new product is a messy process. It involves initial brainstorming, rough concepts, false starts, and extensive refinement. Good designs begin with an identified need or opportunity, and they’re based on a solid understanding of the product’s requirements. No matter how skilled the requirements analyst is or how informed and cooperative the customer participants are, the first set of requirements they develop will be only approximately correct. It takes a process of iterative refinement and validation to accurately understand the requirements for any nontrivial product.

Designs that sound good in theory often do not succeed in real life. Unless…


Image for post
Image for post

If you’re a business analyst, product manager, or product owner, don’t expect your customers to present you with a succinct and organized list of their requirements. Instead, you must organize the myriad bits of information you accumulate during requirements elicitation into various categories so you can record it appropriately and other people can work with it.

Figure 1 illustrates nine common categories of requirements knowledge. During elicitation activities, you can add indicators in your notes if you detect some bit of information of one of these types. …


A man holding a sign that says system error
A man holding a sign that says system error
Background photo adapted from rawpixel.com — www.freepik.com

Software applications, cars, kiosks, and many other products must communicate important information to users. These feedback messages most commonly contain information about errors; warnings or alerts; and task progress, completion, or confirmation (Constantine and Lockwood, 1999). Feedback from a product is most effective when it exhibits these seven characteristics:

  • Immediate. Delayed feedback makes it harder for the user to associate a message with its triggering event or condition and inhibits productive use of the information (Norman, 2013).
  • Informative. A communication that conveys nothing of value or that users don’t understand is wasted (Norman, 2013).
  • Necessary. Telling users what they already…

Image for post
Image for post

Someone once asked me when you can begin testing software. “As soon as you’ve written your first requirement, you can begin testing,” I replied. It’s hard to visualize how a system will function by reading some requirements. Tests that are based on requirements make the expected system behaviors more tangible. Even the simple act of designing tests reveals many requirements problems long before you can execute those tests on a running system.

Requirements and Tests

Tests and requirements present complementary views of the system. Creating multiple views of a system — written requirements, diagrams, tests, prototypes, and so forth — provides a much…


Image for post
Image for post

“How are you coming on implementing that subsystem, Yvette?” asked the project manager, Dave.

“Pretty good, Dave. I’m about 90 percent done.”

Dave was puzzled. “Didn’t you say you were 90 percent done a couple of weeks ago?” he asked.

Yvette replied, “Yes, I thought I was, but now I’m really 90 percent done.”

Like nearly everyone, software developers are sometimes overly optimistic when they report how much of a task is complete. The common “90 percent done” syndrome doesn’t tell Dave much about how close Yvette really is to finishing the subsystem.

But suppose Yvette had replied, “Pretty good…


Image for post
Image for post

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction when working with clients and a different source of satisfaction for the consultant. This article describes these three modes of engagements based on my experience as a business analysis and process improvement consultant.

Mode #1: Outside Looking In

As an expert, you’re working with a client who has a problem and wants you to fix it. I’m working in the expert role when a client brings me in to deliver some training, perform a…


Image for post
Image for post

Rather than building software systems in-house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they lack in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.

The role of a business analyst (BA) is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a…


Image for post
Image for post

When customer expectations are high and timelines are short you need to make sure your project team delivers the most valuable functionality as early as possible. Prioritization is the only way to deal with competing demands for limited resources.

Stakeholders on a small project often can agree on requirement priorities informally. Large or contentious projects with many stakeholders demand a more structured approach. You need to removes some of the emotion, politics, and guesswork from the process. This article discusses several techniques teams can use for prioritizing requirements and some traps to watch out for.

Two Big Traps

Be sure to watch out…

Karl Wiegers

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store