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 you’re an extraordinarily gifted — and lucky — designer, your first solution ideas won’t be the best. This reality leads to an important lesson for every designer to…


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 know — or don’t need to know — is distracting, not helpful. …


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 richer understanding of the system than can any single representation. Some agile development methods emphasize writing user acceptance tests from user stories in lieu of writing detailed functional requirements. Thinking about the system from a testing perspective is valuable, but that approach still leaves you with just a single representation of requirements knowledge, so you must trust it to be correct. …


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, Dave. Of the 84 requirements for the subsystem, 61 are implemented and verified, 14 are implemented but not yet verified, and I haven’t implemented the other 9 yet.” Tracking the status of each functional requirement throughout development provides a more precise gauge of project progress than top-of-the-head guesses about percent completion. …


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 process assessment, review a project’s requirements, or advise how to improve their BA processes. …


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 question or to demonstrate newly developed functionality. …


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 for “decibel prioritization,” in which the loudest voice heard gets top priority, and “threat prioritization,” in which stakeholders holding the most political power always get what they demand. These traps can skew the process away from addressing your true business objectives. …


Image for post
Image for post

As a consultant and author, I often receive emails posing questions about the challenges people face dealing with requirements issues on their software projects. Here’s a question on an issue many teams encounter: replacing an existing software application.

George’s Question

“I am responsible for implementing a new system to replace a mainframe application that has been in production for a very long time. We have no documented requirements for the current system, the original developers are long gone, and our user community has since been changed out.

“Does it make sense for us to document the requirements of the current system as a prerequisite to documenting the go-forward requirements? Or should we disregard what we now have in production and document the go-forward requirements from scratch? …


Image for post
Image for post

I learned a powerful life lesson from a date that did not go well. The poor date was entirely my fault; I make no excuses. I was not in a good state of mind, distracted by thoughts of another woman who had just dumped me. I wasn’t focused on Chris during our date, even though she was much more my type.

I’d known Chris for several years; we worked at the same company. We had joked around with each other and even flirted a bit. I thought she was cute and funny so I asked her out. But I wasn’t good company that night. We watched a terminally boring movie at my house, and neither of us had much fun. …

About

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