Woman with a headache sitting at a computer
Woman with a headache sitting at a computer
Business photo created by katemangostar, https://www.freepik.com/photos/business

Have you ever struggled to interpret a confusing computer message or figure out how to operate the unintuitive controls on a physical device? A product that functions in an unexpected way halts us in our tracks. We waste time thinking about what happened and backtracking to try to achieve the expected outcome.

Thoughtlessly designed products impose an unnecessary mental load on their users. They force users to think too much about how to use the product, struggle to interpret a message, or try to remember more information than necessary. …

Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are increasingly available to meet software needs as well.

Whether you’re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. …

A drawing of two theater masks, smiling and frowning.
A drawing of two theater masks, smiling and frowning.

You’ve performed your stakeholder analysis, identified several user classes, and perhaps lined up some people to serve as product champions, key representatives of those user classes. But what if you’re building a mass-market product and can’t connect with actual users to present needs and to assess your design proposals? Or perhaps a product champion or a focus group won’t always be available to answer the development team’s questions. Consider creating personas as substitutes for those absent human beings.

A persona is a description of an archetypical person that analysts and product designers can use to stand in for a particular…

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…

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…

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…

“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…

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