BA Brew Insights: Requirements

The BA Blog is back! This new series of short-read BA Blogs summarise key insights from past BA Brews. We’re kicking off with Requirements. Are they redundant, or relevant?

These insights are from BA Brew Episode 13 – Requirements: Redundant or Relevant

Requirements – What are they Good For?

This BA Blog shares some key insights from BA Brew Episode 13 on Requirements. It is the first in a new series of short-read blogs inspired by past BA Brews.

What are Requirements?

Any stated want or need is a requirement. Requirements are relevant in any project lifecycle.

Why do some people have a problem with the term Requirements?

There could be an overemphasis on the ‘engineering’ word in Requirements Engineering, which might scare some people off. However, the engineering term is not prescriptive.

There has been a habit of requirements engineers filling in a template without thinking about the context, the priority, or the innovation. That could be part of the problem. When people encounter overly wordy, overly detailed requirements documents this can give them a negative perception. It is not Requirements that is the problem in such cases, it is the misapplication of the technique.

How do you resist going into too much detail with Requirements?

With Requirements there is a risk of going into too much detail up front – without stepping back and looking at the bigger picture.

In essence, a Requirement is something you require, it is as simple as that. The best Requirements can be captured on one page in a Use Case Diagram, with clear boundaries and features.

Context is key to everything we do. Sometimes there is a requirement with a lot of depth and business rules, where the end user did not know the rules and it’s necessary to look at many different documents to find out those rules. Other requirements are less complex, such as prototyping and testing on screen. If you are a professional BA, you should be able to appreciate the context and adapt your approach. This is achieved through effective engagement with Stakeholders.

It is better to adapt Requirements to context, and we always need to think about outcomes and innovation, rather than unthinkingly filling in templates.

Requirements engineering is often happening even when it is not formalised – when people are thinking about the desired business outcome without getting tied up in the method.

What are the benefits of Requirements?

Requirements give you a standard of framework you can apply in any context, a repeatable process where you can learn from successes and failures and make improvements.

A good requirements model allows you to capture and re-use knowledge to improve business outcomes. It serves as a foundation for business agility and can drive improving business architecture and business design.

As professionals with a toolkit and an understanding of business outcomes, Requirements help us do a better job.

Good Requirements Engineering requires analytical thinking and an understanding of business and of our colleagues. It is about understanding the bigger picture including timescales, context and priorities. The word Requirements is not the problem, the quality of the application and understanding of Requirements informs the outcomes.

If you are interested in Requirements you may be interested in the following articles, courses and BA Brews:

ARTICLES

Who’s Afraid of the ‘R’ Word

COURSES

Requirements Engineering (Available as a three day live, virtual classroom course, as a self-paced eLearning course and as a face-to-face classroom course)
Advanced Requirements Engineering (Available as a three day live, virtual classroom course)

BA BREWS