The Incredible Expanding Requirement
The Incredible Expanding Requirement
A simple requirement statement might conceal much detail that eventually must be discovered and addressed.
Image by kjpargeter on Freepik
Some requirements are like icebergs: The portion that you see initially is only a small fraction of the whole thing. Whether it’s represented as text—such as a single functional or nonfunctional requirement statement, a feature summary description, or a user story—or visually in the form of an analysis model, there could be far more to it than first appears. Requirements analysis involves digging below the surface of a presented requirement to understand its full scope, complexity, and implications.
Let’s consider a simple, common nonfunctional requirement: “Only authorized users may access system services.” That security requirement could have originated from a company policy, government regulation, or other business rule. Can you just hand that requirement to a developer, or maybe write it in the form of a user story and add it to the product backlog? I don’t think so. Peeling away the layers shows that that one requirement statement can expand enormously, raising many questions and spawning many child requirements along the way.
This raises the question of how much detail to document for an unrefined requirement versus leaving it in the hands of the developer to process as they see fit. In other words, who do you want to make all the decisions associated with a complex requirement, and when? Considering that question will help you manage the transition from requirements to design.
If you want an initial high-level requirement implemented in a specific way, the business analyst should elaborate it into the appropriate level of detail and precision. That elaboration could impose design constraints on the developer, albeit for good and thoughtful reasons. On the other hand, if you’re okay with the developer having the final say on the functionality and user experience details (preferably with feedback from others on design documentation, prototypes, or screen sketches), then just pass the higher-level requirement along for implementation.
Looking Below the Surface
Consider some of the questions you’d have to answer if you were the developer asked to implement our one-sentence security requirement. It’s unlikely that you’d have all the answers yourself. As you study the requirement, you’d have to make up those answers, research policy standards, or consult with others to agree on how to resolve each issue. That’s what business analysis is all about. Let’s see how quickly an exploration of this single requirement statement expands into many detailed requirements.
First, we’ll need a clear definition of exactly what an “authorized user” is and just what system services cannot be accessed unless a user is authorized. Do different parts of the system require different privilege levels or access credentials?
How should each user be uniquely identified? With a login name, an email address, using a third-party account (like Google, Apple, Facebook, or X), or something else? Will the user ID be assigned by a sys admin or user-selected? What are the rules for the user ID: minimum and maximum length, allowed characters, and case sensitivity? What happens if the user selects a user ID that’s already in use?
Next, what is the primary user authentication mechanism? We have numerous choices, including password, passkey, PIN, and biometrics of various kinds. Let’s just think about the venerable password for now. Here are some questions that come to mind regarding passwords:
- What are the rules for the password: minimum and maximum number of characters; allowed, prohibited, and required; characters, case sensitivity; pattern restrictions (such as no more than two instances of the same character in sequence); required patterns (such as at least one each of upper- and lowercase letters, numbers, and symbols)?
- Must the user re-enter the same password in a separate field during creation to verify it? If so, what happens if the two entered passwords don’t match?
- Can the user toggle the visibility of the entered password on and off, either during creation or during logins?
- How is the password masked in the entry field? With asterisks or dots? One symbol per entered character or a random number of symbols to conceal the password length from an onlooker?
- What feedback will the system provide if a login attempt fails?
- Is the user blocked after too many unsuccessful login attempts? If so, how many tries do they get?
- If the user’s account is locked after too many failed login attempts, how long does the account remain locked? How can the user unlock it?
- What happens if the user forgets their login ID or password? What recovery method is used? I can’t get into my original YouTube account because I’ve long since forgotten the password, and the phone number on the account cannot receive texts. Google offers me no other identity verification options.
- Must the user change their password periodically? If so, how often? Are there restrictions on what the new password can be, such as not reusing any of the previous N passwords?
- Can the user define a personal identification number (PIN) as a shortcut for the password, as on a Windows PC? If so, what are the allowable characters and the minimum and maximum length of the PIN?
These are some of the issues associated with specifying a security requirement for just a simple password mechanism. You can see how the answers to those questions lead to more and more functional requirements to satisfy the nonfunctional security requirement. But the expansion can get much worse.
The Many Modes of MFA
If your project’s decision makers want better security than a password provides, you’ll explore multifactor authentication (MFA) options. You’ll need to choose from numerous options for both MFA techniques and their implementation details. Start by deciding what types of MFA the system should enable to provide the desired security level. Options include:
- Sending a one-time code that the user must enter to verify their identity
- Sending an email containing a one-time login link
- Biometrics, such as fingerprint, facial recognition, voice ID, and iris or retinal scan
- A physical security token
- Using an authenticator app, perhaps on a second device
Here are a few more general questions:
- How many of these MFA options should you make available to the user?
- If more than one, can the user select their default preference to use initially for each login attempt? Can they change that default?
- How will the user enable and disable MFA on their account?
- If for some reason the user can’t employ their initial method (such as not having access to the device with the authenticator app), can they select another method for that session?
- Will there be some other backup action, such as contacting customer support, in case none of these MFA methods work for the user?
Let’s take a closer look at just the technique of sending the user a one-time code. Contemplate these questions:
- What options will you provide for sending the code: text message, e-mail, or phone call? Will the user have more than one option available?
- If text message or phone call, can the user save more than one phone number in their application’s profile? Can they specify the default and select the number to use for each session? Can they change or delete a saved number or change which is the default?
- How many characters are in the one-time code and what are the valid characters?
- How long is the one-time code good for? If it’s limited, should the application display a countdown timer? Can the user request to have the code re-sent? If so, is the same code sent again or a new code? What happens if the user enters the one-time code after the time-out period?
- What happens if this secondary authentication attempt fails? Is the entire login session terminated, or can they try the MFA again? How many tries does the user get at the MFA action? If it’s limited, do attempts using different methods all count toward the limit?
- Can the user opt to have their authenticated device and login recognized for some period of time so they won’t have to re-authenticate for each session? If so, how long is that period? Where should that information be stored? I use some apps that recognize my device even if I restart my browser, while others lose my remember-me setting whenever I clear the browser cookies.
I’m sure there’s even more to it than this, but you get the picture. Drilling into the particulars of an initial, concise requirement statement often opens a sizeable can of worms. The answers to the resultant questions lead to an explosion into more and more requirements. This fact is true whether the exploration is performed by a business analyst during requirements specification or by a developer who’s been tasked to write the user authentication code. The original requirement isn’t actually growing, so this process isn’t changing the project’s scope. It’s merely revealing the true scope.
The good news is that if you can craft a well-thought-out set of requirements for a complex function like user authentication, you can likely reuse them in multiple applications. At the least, they should provide an excellent starting point.
Beware the Blast
I’ve used a common nonfunctional requirement to illustrate how much complexity can hide beneath the tip of that requirement iceberg. The same can apply to functional requirements and product features, of course.
One of my consulting clients held a large workshop to gather requirement ideas for a new flagship product. One of the requirements stated, “The product shall respond to editing directives entered by voice.” This was at a time before speech recognition capabilities were built into all of our devices. That one simple requirement statement looked to be no bigger or smaller than all of the many others in the set. However, you can guess how large the requirements explosion would be when someone looked into everything involved with the details of that speech recognition feature.
Understanding the true scope of a requirement so your team can estimate and plan for its design and implementation often requires a fair amount of exploration. During that exploration, you can set the priorities of the various child requirements, perhaps deferring some functionality to later development iterations and maybe never implementing others. That thinking process is less painful than encountering one additional, unexpected need after another and continually revising the product.
======
Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.