How do I analyze statements of requirements?



  • 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?



  • 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 https://en.wikipedia.org/wiki/KISS_principle and https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it principles in mind whenever possible.

    Why Conversations Matter

    The https://en.wikipedia.org/wiki/XY_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!


Log in to reply
 


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2