SMART Requirements for Business Analysts

      No Comments on SMART Requirements for Business Analysts

SMART Requirements:

Requirements gathering is usually divided into 4 phases: Elicitation, Analysis, Organisation, and Validation.

The aforementioned phases are not linear, they are iterative and can be mixed and matched.

Apply the SMART techniques explained below to the requirement phases as you identify and refine the requirements.

You don’t have to get stuck on a particular requirement until it is crystal clear at the first go itself. If a requirement is unclear or doesn’t fit in the context then you can take a note of it and come back to it later.

Nevertheless, when you create the final version of requirements they should be solid and SMART.

Applying the SMART technique to identify and refine requirements

Every textbook and guideline will have their own way of explaining what is a “good” requirement.

In this article, I distill out the essence of what a “good” requirement is by borrowing from the SMART goal acronym.

Specific

Description:

A requirement can be termed specific if:

  • It is clear and non-ambiguous.
  • It is consistent and uses the same terminology throughout.
  • It is short and simple.

Validate if a requirement is Specific by asking the following questions to the requirement:

  • What?
  • Why?
  • Who?
  • Where?

Suggested Techniques:

  • Avoid words like “some”, “several”, “many”. Always be exact, precise and binary ( wherever applicable; yes/no, true/false)
  • Specify pronouns understandably: e.g “A calls B, it is updated”. Clearly state whether A or B is updated.
  • Always specify the unit. E.g the download should begin in 4. It should have a unit; 4 seconds, 4 milliseconds, etc.
  • Wherever possible explain a requirement with an associated picture
  • Provide explanations for terms like “transmitted”, “sent”, “downloaded” and processed.
    • E.g the file needs to be sent.
    • You need to explain
      • when it needs to be sent,
      • where it needs to be sent,
      • how it needs to be sent,
      • etc

Measurable

Description:

  • The requirement should be measurable in two ways:
    • Completion of a requirement should be a measure of progress towards a goal.
    • The requirement completion itself should be measurable. For this, the indicators of completion should be quantifiable.
      • E.g The response time should be very fast. That isn’t measurable. Hence you say, the response time should be 2 seconds from the time the request was first sent
  • You should be able to prove whether the requirement was met or not during development, testing, and real-time.
  • The requirements should be detailed, specific, and quantifiable.

Validate if a requirement is Measurable by asking the following questions to the requirement:

  • How much?
  • How many?
  • How will I know when it is accomplished?
    • Some examples are:
      • Database entry is done.
      • A confirmation dialogue box displayed.

Suggested Techniques:

  • Ensure the requirement’s measurability during the elicitation phase itself and not during later phases.
  • Ensure the success of the requirement can be proven.
  • Determine the tests that will verify the requirement was met.

Attainable

Description:

  • Do feasibility and a sanity check on requirement based on:
    • Technical expertise
    • Scope of the project
    • Budget
      • E.g. Sometimes a stakeholder may suggest an outlandish need like they may want the chair to vibrate every time there is a notification on the screen based on the 5D technology. If the expertise, scope, and budget don’t allow for it then it is unattainable and hence the requirement will be dropped.

Validate if a requirement is Attainable by asking the following questions to the requirement:

  • Is there a theoretical solution to the problem?
    • If not, then take a note of it and review it during the solution design phase and accept or reject it based on the aforementioned feasibility parameters.
  • Is the requirement previously done?
    • If yes, then find out how, what, when, budget, duration, etc to replicate it in the current project. If no, then find out the reason whether it was because it was never asked for or because there were constraints or feasibility issues.
  • Are there any known constraints? (environmental, physical, etc)
    • E.g. The response time to a request should be less than 1 millisecond but because the server location is very remote it is not feasible.

Suggested Techniques:

  • Identify individuals or groups who are responsible for satisfying the requirement and validate they can deliver i.e. identify technical expertise
  • Ensure sufficient time, resources, and budget. E.g. For a requirement, the technical experts determine they can design a solution but they suggest duration and resources that are not within the agreed project constraints. You may have to modify or drop the requirement in that case.
  • Reuse modules, components, features, functions from previous projects. If you directly use it (or use it by modifying it) you will have a good starting point from where you can accurately estimate what it will take to accomplish the requirement.

Reasonable

Description:

  • Validate the effort is worth the requirement.
  • This feature is an extension of the Attainable attribute covered previously.

Validate if a requirement is Reasonable by asking the following questions to the requirement:

  • Is it worthwhile?
    • Example:
    • Let us assume that there is a fictitious process in which a single user is assigned with the task of emptying the closed-lead record every week.
    • It is a manual process in which the user has to just select the records and move them into another directory. It takes the user just 10 seconds each time i.e ~9 mins a year
    • To solve this problem you figured out 2 solutions
        • Do nothing
        • Automate the system
    • Assume you plan to automate the system and the potential solution takes 20 hours to build. It will take approximately 133 years to just break even. You understand that there is no point to do anything and so you don’t bother to proceed.
    • At this point, you deem the requirement unreasonable and not worthwhile.
  • Is the timing right?
    • Example:
    • A component of a requirement is already in progress or is planned in another project. In that case, you decide to wait as the timing is not right because:
        • The component was done successfully in the other project and you could just replicate it directly or with minor modifications in your project.
        • The component failed in the other project and you studied and learned that it’ll be difficult to execute in your project as well. The ROI doesn’t match and hence you have to drop the requirement.
        • The requirement was deemed unreasonable in the other project. You studied and learned that it’ll not be doable in your project either.
    • In any of the above cases, you minimise your risk and leverage the effort of the other project’s team.
  • Does this match our other efforts/needs?
    • E.g. If you classify a requirement as a “nice-to-have” and it requires an unreasonable amount of time to complete then you may drop it.

Suggested Techniques:

  • Perform a sanity check on each requirement
  • Ensure the requirement makes sense in the project’s context

Traceable

Description:

  • You should be able to trace a requirement through design, implementation, and testing.
  • The formality of tracing a requirement varies from organisation to organisation. It is an expensive process for an organisation. Some are very stringent, some are flexible and few don’t consider it important. In any case, you as a Business Analyst should maintain some system to trace your requirements.

Validate if a requirement is Traceable by asking the following questions to the requirement:

Can I ensure this requirement has been met in:

  • Design Solution?
  • Implementation?
  • Testing?

Suggested Techniques:

Requirements should include:

  • Originators: You want to know the origin of this requirement. If this is a standalone requirement or a sub-requirement and the origin of this requirement is another requirement i.e. the originator requirement.
  • Assumptions: You want to mention the assumptions associated with the requirement that would be useful when it would be later designed or developed.
  • Business Justifications: Why the business needs this requirement?
  • Dependencies on other requirements: E.g. There may be a requirement for a report which is dependent on another feature in the system.
  • Importance: You want to know the priority of the requirements.

The post is  based on my notes and understanding from this BA tutorial