Posted on

Apple w-Measuring TapeAh weight loss, the story of my life. I used to view it as an ongoing struggle but now I view it as a journey. After all, I have been doing it all my life, a seeming testament of my failed attempts at controlling my weight – the struggle I would never overcome. Well I did not get into the shape I am in overnight, so therefore, it must be a journey I undertake to reverse years of bad eating habits vs. instantaneously seeking a quick fix. I must double my efforts if I want to achieve my goals, a journey requiring much focus, great commitment, and a strong approach. And although I know exactly what I should do, it is still very difficult to follow through on as I am influenced by people and the media; I endure social pressures and more. I am sure you can relate, if not to weight loss specifically, surely something else, perhaps to requirements?

Yes, requirements! Have you seen or been the recipient of a requirements document that was 100 pages long or more? Scary, right? My first thought is always, “Who has time to read it?” and that is quickly followed up with, “Do they need all of this?” Depending on the size of the project and the overall complexity it may very well be needed; however, is it palatable? Which requirements are actually needed – your protein, and which requirements are not – the bad carbs and corn syrup? I am frequently asked how detailed a business requirements document should be. Well that is a tough question to answer; and naturally, it depends. After all, there are a lot of requirements to consider including: business, stakeholder, functional, non-functional, transition, business rules, assumptions, constraints, process, data, scope, interface, and interaction to name a few (lol). So, when I see these 100+ page documents, I do think about requirements weight loss.

So how much is the right amount to document? I mean, we could elaborate on requirements forever right? Is there such a thing as too much? In today’s business world there is, so my rule of thumb is just enough to convey the information clearly, where everyone completely understands and then not too much, where the requirements do not add value. Oh, and you must do so with the appropriate text, models, matrices, and diagrams. Okay, on the surface that may seem like it does not help too much, so I want to offer a couple of things up that might help you determine if your requirements need some weight loss.

Many times in the past I have encountered gargantuan requirements documents (all over 100 pages or more). I have come forth to ask the Business Analyst two questions. In all instances after the two questions were asked, their gargantuan requirements documents shed a lot of weight!

Question #1: Are all of your requirements necessary? When you write requirements you need strong criteria for characteristics of requirements quality. These characteristics of well-written requirements ensure that our requirements meet the needs of the business. The BABOK lists cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable characteristics you could use. One of my personal favorite characteristics is “necessary”. Why? Because we have learned that when we focus on the needs of the business and not the wants, we have higher quality results. Wants may help us flesh out the overall picture, but the needs get the job done. I find time and again that there ends up being a lot of “wants” in our requirements documentation. And remember, we as Business Analysts must be advocates for the business as well as IT, so asking this question is pretty important if you want to be successful in that effort. The answer I typically get back when I ask this question is, “Well the business says EVERYTHING is necessary!” And if you believe that, I have a bridge to sell you… so with a reminder about what it means to analyze business capabilities, I then proceed to question #2.

Question #2: Do all of your requirements trace back to your goals and objectives? Traceability is often seen as too time consuming or obvious. As a result, it is often done very late in the project where it becomes too costly to manage and handle the rework that has taken control of your project. If we do our traceability early and we can often prevent rework, reduce costs, and ensure that we are not working on requirements that are technically out of scope. Requirements that do not trace back to goals and objectives are out of scope, either that or the goals and objectives were not well defined to begin with and that of course, is another problem that must be solved!

When faced with these two questions, necessity and goals/objectives traceability, the requirements documents naturally starts shedding weight. They stick to the protein (the needs) and they remove the bad carbs and corn syrup. Yes, the requirements may taste better with them, but they don’t actually need them. Then, the BA can focus on the right mix of models, matrices, text, and diagrams and the document sheds some more weight (a picture is worth a thousand words I hear).

What other ways have you helped your requirements shed some weight? Have they gained weight and how was it helpful? I am sure they have. This thing we do with requirements is an art form and a journey we take in order to tell a story. It requires much focus, great commitment, and a strong approach. Please do share your requirements weight loss story as it makes us all stronger! Whatever your journey is, be it requirements documentation, weight loss, or something else, I wish you great success!

2 thoughts on “Requirements Weight Loss

  1. Avoid excessive weight by defining clear scope up-front, and apply it as needed to determine if a requirement is in or out. This can be helped by eliciting requirements around processes within scope, and the data and rules that support those processes.

    • David – absolutely! Whole heartedly agree. Now there are of course many BAs that do not get the luxury to define scope up front as the project was “scoped” and “vetted” by another previously. To those BAs I say COURAGE! You still should clarify that the scope is correct and if it is not have enough courage to challenge appropriately. If the scope is correct, do as David suggests and “apply as needed” to determine that each requirement is valid.
      Thanks David!

Leave a Reply

Your email address will not be published. Required fields are marked *

PMBOK, PMI-PBA, PMP, PMI-ACP and CAPM are registered marks of the Project Management Institute, Inc.