0

I am trying to understand how to create a requirements tree but i'm struggling to understand how to decompose them.

If i have the requirement:

  1. The system shall be able to achieve 50% uptime.

How do I analyse more requirements from this?

2 Answers2

2

The Requirement May Be Fine

The system shall be able to achieve 50% uptime.

To be honest, I don't know what your specific issue is with this requirement. So far as it goes, it seems clear enough absent some additional context.

So on one hand, it may be fine just as it is. On the other hand, maybe "uptime" in your organization means something company-specific like "excluding scheduled downtime, power outages, disaster recovery exercises, or force majeure." Or maybe someone wants you to define the uptime percentage as units of time instead.

Unless you've received specific feedback saying that this requirement isn't sufficient for some reason—which isn't information provided in your original post—or that it needs to be linked to some other functional or non-functional requirement that you haven't defined in your question, then my assumption would be that it stands on its own. Don't create additional complexity in your specifications for its own sake; always keep the KISS and YAGNI principles in mind whenever possible.

Why Conversations Matter

The X/Y problem you seem to be facing isn't about decomposition, since there may or may not be any decomposition or additional detail needed. What is missing is stakeholder conversations. In other words, you're treating requirements as self-evident future-state facts about a system, rather than as placeholders for understanding what stakeholders need or want from the system.

A good requirement should be reviewed with stakeholders for accuracy, suitability, or other business-facing validation. It should also (when possible) be defined in ways that are testable. So, depending on what "50% uptime" means to your stakeholders, and how they plan to measure it, you might want to expand the requirement to cover the metrics or tests that will validate that the requirement has been met, or link to related requirements about testing and validation.

Again, I want to stress that you may not need to do those things. The level of granularity, testability, auditability, and other functional and non-functional aspects are always going to be organization- and product-specific. That means:

When in doubt, ask someone in authority within your organization!

No one outside your organization can really definitively answer questions about your company's internal requirements or its requirements process, so identifying the right people to ask and then talking to them directly is really the only way to ensure you're meeting expectations. Like almost everything else in project and product management, communications is the primary key to success!

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
  • Ah i think i sort of understand what you mean, the requirement is a statement of fact when it should be more like a statement of need? – Richard Bamford Apr 12 '22 at 19:54
  • @RichardBamford I'm saying something a little different. A requirement shouldn't be arbitrary; it's more about understanding why the organization wants X% uptime, and then building the requirements to support that. If there isn't a reason, then there's not really much else to say about it. However, if there's a reason and it impacts architecture or other requirements, then there's more to unpack. That's why you can't do this in a vacuum. – Todd A. Jacobs Apr 12 '22 at 21:53
  • Aha thank you Todd! – Richard Bamford Apr 14 '22 at 11:46
0

Requirements tree example from a non-IT domain

Let us say a car company wants to provide high uptime (say 99.99% = less than an hour of downtime per annum) for their customers. First of all, they have to build the cars to be of high quality so that it needs to be serviced less often and breaks down less often. However, buyers do need to bring it in for servicing, namely, oil and filter change as well as for the occasional breakdown. The car company has to get their dealers to do the servicing quickly. So at the first level, we will have the above requirements.

Improving build quality, in turn, will need skilled factory staff, precision machines and quality vendors. These are the branches of the build quality requirement.

In a similar manner, we can decompose each of the requirements into their branches, resulting in a requirements tree that looks something like this:

  • Improve build quality
    • Quality people
      • Hiring
      • Training
    • Invest in precision machines
    • Quality vendor
  • Reduce service frequency
  • Reduce service wait time
    • Stock more spare parts
    • Use better diagnostic tools
    • More service automation
    • Provide loaner car
Ashok Ramachandran
  • 11,082
  • 1
  • 22
  • 50