As developers, we have a mountain of technical skills we try to master. As junior developers, we try to stand out by learning a little bit more about our tech stack, getting acquainted with a new framework, and challenging ourselves with complicated side projects. It's easy to forget about honing our soft skills, even though these can help us stand out even more. Today, I want to talk about a soft skill that does not get the attention it deserves: requirements management.

I try to keep most of my articles under 4 minutes, but this is an important topic and there's a lot to say about it, so buckle up.

What is Requirements Management and is it Really a Soft Skill?

"Requirements" are things that a system or piece of software must do in order to satisfy stakeholder (people paying for the system) desires. They can be

• Functional: Things like "users can comment on another user's post"
• Non-Functional: Things like "The system should not show any noticeable lag when up to 1000 concurrent users are using it"

Requirements management is the practice of eliciting and maintaining those requirements. In academic circles, this is instead called "requirements engineering." "Engineering" because there is a defined process with expected results. I don't like the "engineering" part of the term because in my humble opinion, it dehumanizes what is essentially an exercise in advanced interpersonal communication.

When people think of soft skills, they mean things like communication, creativity, and teamwork. Requirements management involves all these things and more, to a pretty intense degree. These are things we can (and should) learn in parallel with our technical skills. It is a vitally important skill for a developer to have, which makes its rarity among developers so odd. But why is it so important?

The Importance of Requirements Management

In one sentence, why is requirements engineering management important? Because "... the cost of fixing a requirements defect later in the development stage is much higher than the cost of identifying and fixing it in the early stages of development" Pandey, D. & Pandey, V. (2012).

Every change to a requirement has a price, and that price gets steeper the later that change is implemented. Effective requirements management ensures that requirements are understood as thoroughly as possible and as early as possible, minimizing future changes. Requirements management is, therefore, one of the most valuable skills a developer can have.

I feel it's important to mention that requirements management is not the sole responsibility of the developer. In larger teams, requirements management is the responsibility of people with titles like "business analyst." On smaller teams, the brunt of this job may fall to the lead dev, tester, or project manager. But ultimately, the final quality (and therefore all practices contributing to quality) of a product is everyone's responsibility.

Why do Requirements Change?

No matter how advanced a team's requirements management competency, requirements will change. There are several contributing factors to this.

According to Ian Sommerville (noted academic and author of Software Engineering, probably the most common SWE 101 textbook), requirements change primarily for the following reasons:

• The world changes: Whether the goals of your business change, new laws are passed, or any other of a myriad of reasons, the world changes. Requirements can and do change with the world.
• Difficult to imagine a future system: You'll find that a lot of times, stakeholders and customers can't really tell you exactly what they want until you put a prototype in front of them. To expect a user to explain exactly what they expect from a piece of software without anything to compare it to is unrealistic and unfair.
• Multiple Stakeholders: Often times, the systems you develop will be used by people spanning multiple departments or lifestyles within your organization or customer base. With that many different perspectives, what one person considers "right," another might consider "wrong," "useless," or even "stupid."
• Requirements are compromises: Users will always want more, and that's OK. The problem is, we don't have the time or resources to give them everything they want. If we had unlimited time, we could give them the world, but we don't, so we have to find the point where the time invested in a feature is worth the value we'll get from it. Sometimes this value changes, and thus the requirement changes.
• Organizational politics: Sometimes users do not want to use your product, their boss is simply forcing it on them. Other times, a new manager may simply just nuke a project because they didn't like the person who started it. It happens (and it's not your fault, so don't take it personally).

Even though change is indeed inevitable, there is still a lot of monetary value to be gained in the effective management of requirements.

Many Great Developers are Great at Requirements Management

As a disclaimer, I should mention that I've been a developer for only a year, and was a QA Engineer for about a year before that, so I am not exactly a seasoned guru. The advice I'm imparting is from my personal experiences in that amount of time and from watching how my senior coworkers do their jobs.

The best developer I know, aside from being wizard-like behind a keyboard, is a great requirements manager. I remember a particularly funky requirement from the customer (a department within the company) that was estimated to take about a month to implement. The developer pointed out that this requirement was almost satisfied by another feature, and that a negligible amount of extra effort from the user would solve their problem.

Imagine the business value of such an observation. Developer time is not cheap, so the features we build have to bring real value to our customers. To be able to point out to a customer that they are effectively spending too much money on something they don't need (tactfully of course) has real value to the company's bottom line.

Tips for Managing Requirements

If you want to stand out as a junior developer, aside from mastering your tech stack, being good at requirements management will have a real impact on your team's performance. Keep your company and team culture in mind and respect your team's processes when applying these tips (ie, don't march into the VP of Accounting's office and say "this requirement is STOOOOPID!").

In a Requirements Engineering class, you'd learn that there are 4 phases to the process: Elicitation, Analysis, Validation, and Documentaiton. At each stage, there are things you can do to ensure the requirements are of high quality (well understood and actually needed).

All these tips can be summed up with two attitude adjustments:
1 - Be empathetic. Do your best to see the system from your customer's point of view.
2 - Be humble. As a developer, it's hard to admit when something you built might end up being useless. Also, be sure you're not pushing for or against a requirement because you especially do/don't want to build it.

Elicitation

This is where you get the customers to say what they want. This could be as formal as a meeting between the apps team and the business, or as informal as a water cooler conversation. Either way, you want to get as much clarity (not detail) as you can from your customer.

One of my go-to strategies is to say, step-by-step, what I think the user is looking for and have them comment. Something like:
"So you want to log in, click a button, and see a list with a short description of all the things you have to do today, right?"

Spelling it out like this is helpful because it gets the customer to imagine actually using the system. Sometimes you'll get a yes and sometimes you'll get something like "No, I want the list to already be there after I log in". Clearing these things up in the Elicitation phase is an automatic win.

As a developer, especially a junior, you might not get as much face time with the customer as the other team members, so you might have to funnel your questions through a more senior teammate. Don't be afraid to ask questions though, and if your company culture allows it, don't be afraid to send a quick email or even have a five minute phone call with a customer.

Analysis

This is usually right after Elicitation. You look over the requirements and think about what the customer's problems really are. Lots of diagrams come out of this phase, but personally I only find 2 of them effective: the Data Flow Diagram (DFD) and the Entity Relationship Diagram (ERD).

DFDs conceptualize a process into a picture like this:

You can make them proper UML (Unified Modeling Language) diagrams but at this phase, it's more important to have a rough sketch of how you believe a process works or will work.

The ERD is a diagram showing how different data objects are related. In my personal experience, these are more useful as a communication tool between developers and analysts, and less so as a tool for communicating with customers. Here's an example ERD:

The example above uses what's called "crow's foot notation" and is used to show cardinality. You can read the above diagram as "Product has many Order Details" and "Order has one and only one Headquarters" for example.

This stage is also the time to make prototypes if that's something your team does. To use or not use prototypes is another subject with lots of other considerations to be made, so for now just suffice it to say that you make prototypes in this stage.

From a developer's point of view, you might not be included in making these things and will probably end up a consumer of these documents. If you do find yourself contributing to the analysis phase, this is the best stage to practice your empathy. Do your best to put yourself in your customer's shoes and see things from their perspective. The problem they told you they want solved might not be the actual problem. You have to think both from their point of view, and from a 10,000 foot view of the system.

Validation

Remember this is a phase within the requirements management phase. Therefore, in this case, validation does not refer to a user testing the system after it's built. What we are validating is that we understand the requirements and if they can be satisfied.

This is usually the next conversation with your customer after the initial elicitation conversation. In this situation, you will show the customer what you've come up with (DFDs, prototypes if applicable, anything else) and explain your proposed solutions.

Again, as a developer, especially a junior, you may not find yourself participating in this phase, but you it's not uncommon either. This is a time when humility is important. You might have misunderstood a requirement, you may have misunderstood a process flow, you could possibly have missed the mark entirely. Listen to your customers in this phase, ask follow up questions, and do your best to truly grasp what they want.

This is also the phase in which you should ask things like "is this really needed?" This is such an important question, and it does not get asked enough. It definitely requires some tact; you are essentially saying "ok but is that what you really meant?" but you need to ask it anyway. Think about the current solutions that exist within your company. Do you need an in-system chat if you're already using Slack? Do you need the ability to copy-paste rows from an Excel file when you could import it instead?

Documentation

In the context of requirements management, this stage refers to writing down the accepted requirements. When we say accepted, it means the customer has agreed that we know what their problem is, and they're ready for us to attempt the solution we've proposed. This is usually when requirements turn into Jira Tickets or Kanban cards and assigned out to developers.

There is not a lot you can do in this stage to ensure high quality requirements aside from accurately conveying that requirement in the design docket/ticket/card.

Conclusion

Like I said at the beginning of this article, requirements management is a soft skill that many developers do not cultivate within themselves. It is, however, a very important skill with a lot of impact on a team and company's performance.

Learn to ask good questions so you can clarify requirements early. You don't have to be a ninja at your tech stack to stand out. Taking time to understand the business, your customers, and their needs will make you stand out just as much.