Functional Requirement Engineering

People who don’t know the best order for producing product development documents devastate their productivity, trash vast heaps of time, and unnecessarily burn mounds of money.

The real tragedy is that they aren’t aware of what they don’t know without adequate levels of expertise, knowledge, and insight. And people typically dump everything into a massive ‘requirements’ document, thinking they are doing the right thing. The collateral damage devastates projects, careers, and companies even with the best intentions.

Here’s one way to look at it. Imagine a toddler picking up a loaded gun. They can barely speak, much less understand the danger. The safety is off. Without knowing better, they throw the gun on the floor. It discharges. They unintentionally shoot themselves in the foot, and the bullet ricochets around, destroying the entire project and wounding everyone involved.

I don’t want to see this happen to you. There is a better way. And we’ll discuss it here.

To help dodge the bullets, or prevent them from firing in the first place, let’s walk through why we have different document types for different purposes in different project stages.

Separation of Concerns (SOC)

First, let’s quickly visit an engineering principle called Separation of Concerns and why it matters.

The term appeared in Edsger Dijkstra’s 1974 paper titled “On the role of scientific thought.”

Today, separation of concerns is a vital system design principle across engineering disciplines, even outside software like urban planning, architecture, and information design.

This concept is relatively simple. The purpose is to understand, design, and manage complex interdependent systems more effectively. And to accomplish this, you break extensive systems into smaller parts.

Here’s how it works:

Imagine you live in a wacky world with no separation of concerns.

You are driving your car down the highway, and your steering column is shaking uncontrollably. Realizing you have a flat tire, you pull over to the side of the road. Unfortunately, there is no spare tire in the trunk because your car is one giant monolithic system. You’ll have to send the entire car to the scrapyard or rebuild the whole thing from scratch due to your flat tire.

Now imagine you live in a sane world with no separation of concerns.

You get the same flat on the highway and pull over. You pull out the jack, raise the car and change the flat with a spare tire. Fortunately, someone had the forethought to engineer the wheels to come off and be managed independently. Not only that, but you can even swap out your normal tire with a special one designed for emergencies. And when you take it to the shop, you don’t even have to replace the whole wheel, because someone engineered the rubber parts that contact the road to be removed and managed independently of the wheel.

So in a world without separation of concerns, you rebuild every aspect of the entire vehicle every time you have a flat. In the real world, we separate these concerns.

Back to the wacky world with no separation of concerns.

So you’ve scrapped your car and will need to buy a new one tomorrow. The sun is setting, and you are on the way home in a taxi, which you already know will probably the most relaxing part of your evening. You get to the front door of your beautiful two-bath three-bed home, take a breath to prepare for what’s ahead and open the door and step through.

You’re greeted with a wall of sound. The doors open to a single massive room, not much different from a big-box warehouse. The kids are screaming, running across the enormous disorganized space. The stove burns in the middle on the mess. Everyone is tripping over the wires and pipes strewn across the floor like spaghetti.

Kitchen plates and utensils lie sprinkled across the floor. Your beds, toilets, tub, and sinks are scattered haphazardly in view. You see the entire mess from where you stand. The visual noise is overwhelming.

Then your power goes out. And, as there’s only a single circuit, the entire family plunges into darkness. The kids start crying, scared to move. As you move forward to console them, you trip over a pile of towels tangled in the middle of a heap of wire and pipe.

The impact of your body hitting the floor sends all your pots and pans exploding across the open, cluttered space. You narrowly escape breaking your leg as you send piles of cutlery clattering across your floor.

To make things worse, you know the entire house will have to be torn down tomorrow and rebuilt from the ground up because there is no separation between your circuit and the foundation or frame.

I know it sounds ridiculous, but this high degree of disorganization plagues most requirement documents handed over to technology teams today. And, it’s a cancer that spreads to damage every aspect of the business. We have to do better because the lack of design and engineering of the foundational information makes success unlikely.

Alternatively, here’s the story in a world where we separate concerns.

You drive home after changing your flat and putting on the spare. You breathe a sigh of relief as your beautiful home comes into view. The car coasts quietly into the drive, and you get out and walk through the front door.

You turn on your hall lights and walk past the living room where the kids are playing. With all the utensils safely packed away in the cupboard, you walk through the kitchen and grab a cold drink from the fridge. Then you walk into the den, close the door, and turn on the TV to sit for a few minutes to decompress.

You hear a knock on the door and your kids tell you the power went out in the living room. So you go down to the breaker box and flip the breaker back on.

In the real world, we separate the different concerns of living into different rooms of our homes. Each room encapsulates specific activities. No matter how messy one room is, it doesn’t affect the other room, except through the designed interface, which is the door.

No towels, pipes, or wires to trip over in your foyer. Food stays in the fridge. Your toilets, tub, and trash bin stand safely tucked away in your bathroom.

And the living room and kitchen lie on different circuits, so if we trip one, the others keep working.

Another engineering principle comes into play worth quickly covering, called the Stable Dependencies Principle (SDP).

Stable Dependencies Principle (SDP)

Like the separation of concerns principle, the Stable Dependencies Principle is also a simple, levelheaded, logical concept.

The idea is that you only have dependencies in the direction of stability. So, when organizing how you connect things, you ensure that anything frequently changing doesn’t depend on anything changing more slowly.

For example, you don’t want to have to change the entire axle to fix a flat on your car. The axle changes less frequently than the wheel, and the wheel changes less regularly than the tire. So we arrange things so that we can change a tire without having to replace the wheel or axle because we engineer these dependencies in order of stability.

Here’s another example. You put the frame of a house on a foundation. Put the wires and pipes in the frame. Put the drywall on the frame. Paint goes on the drywall. Carpet goes on the floor. And finally, the furniture goes into your finished room.

This is the optimal organization of dependencies because your furniture changes more frequently than your foundation.

Simple, right?

How this impacts product development

So, I’m hoping you can see the common sense of separation of concerns and only allowing dependencies in the direction of stability.

With ANY development process, you dissect a system into distinct parts and then engineer, manufacture, and optimize each independently. You assemble the pieces through interfaces designed to maximize utility, assembly, and maintenance efficiencies.

Using basic design principles, you:

• Insulate each part from a potential failure of the others.
• Drastically reduce costs by being able to use parts manufactured somewhere else.
• Optimize the construction process, turning construction into an assembly process.

And here’s the thing: today, every digital product is a system. But it doesn’t stop there.

Your documentation is a system because different independent parts change at different rates. And systems of design and description are worth engineering.

Use the correct type of content organized specifically for each activity. Keep your dishes in your cupboard. Keep your toilet in the bathroom. And keep your cloths in your closets.

While these are straightforward concepts, it’s shocking how many people do things in a suboptimal order. And they throw everything the same document, including the kitchen sink.

Don’t let this happen to you.

Document Types

Prevent project, product, and business disasters through deliberate design. Think things through before making a move.

While these are well-known concepts for any capable designer, most without professional engineering training aren’t aware. Fortunately, the industry standard names for the types of documents make their purpose easy to comprehend once you have context.

• BRD—Business Requirement Document
• FRD—Functional Requirement Document
• SRS—Software Requirement Specification
• Project plan

And there are also four primary phases of a product development project.

Here is the type of document you should create in each stage:

Step 1. Understanding the problem: Nail down the business value and constraints with a Business Requirements Document (BRD)

Step 2. Model a solution to the problem: Design a solution mechanism and nail down the functional requirement of that solution with a Functional Requirement Document (FRD)

Step 3. Design the technological solution to manifest the solution. Describe the technical design with a Software Requirement Specification (SRS).

Step 4. Design the assembly process with a project plan.

Why this order?

Let’s think it through together. Take a few minutes to think through each of these questions and decide the optimal order for yourself.

• Do the business problems and solutions change at different rates?
• Do new solutions frequently emerge for the same business concerns that provide better, faster, or easier solutions than the existing ones? Isn’t this the definition of innovation?
• Do you want to avoid scraping and completely re-evaluating the business needs with every new solution?
• So aren’t you better off separating your model of the problem and your defined solution?

Let’s think through the connection to technology.

• Are technology and your business the same thing, or do they change at different rates?
• Do you want to avoid a complete re-evaluation of your business, products, and services whenever there is technical innovation?
• Do you want to be able to adapt quickly and leverage the latest cutting-edge technologies?

And let’s look from an efficiency perspective.

• Do you want to reuse as much as possible where you have invested time, money, and effort?
• Do you want to have an agile business, system, and product that can rapidly adapt to change, thrive, and survive?

And let’s dive deep to another level of detail.

• When you think things through, doesn’t it makes sense to have each document deliberately designed to maximize utility?
• Shouldn’t you know your primary objective at each step and keep everything aligned to optimize your outcome?

Spend some time and imagine if you can get these simple elements straight. How much competitive advantage will you hold over others struggling with structure?

Want Some help?

At Truth Shield, our mission is to crystallize focus to raise maximum efficiency. We help you drive up quality and value, drive down costs and waste, and eradicate risks.

While we’ve engineered a deliberate product design system, most of these ideas are not ours. We simply stand on the shoulders of intellectual giants innovating across product design, development, and manufacturing industries for a couple of centuries.

Reach out if you would like a boost to elevate your functional requirement foundation.

Apply Today!