Two Useful Additions to a Requirements Package

When implementing a new solution within an organisation, communicating and gaining a common understanding of the requirements is crucial. One way of achieving this level of common understanding is to put together a requirements package. The content and style of that package may vary dramatically depending on the organisational context, the nature and size of the problem being solved, and whether the initiative is being delivered in a predictive (waterfall) or adaptive (agile/evolutionary) fashion. Either way, the requirements package is crucial as it helps communicate what the organisation needs.

 

The focus, quite rightly, when putting this together will be on capturing, analysing and validating the needs of the organisation’s stakeholders. The focus will be on articulating these requirements precisely and succinctly – and it is very tempting to focus purely on the requirements. Yet there are other useful items that we might choose to include that can help to remove ambiguity and create clarity.

 

In this article we’ll examine two other items that we might choose to include in our requirements package to help aid understanding. Both are relatively simple, but are easy to overlook:

 

1. Common understanding starts with common terminology—the benefit of a glossary

It’s important that our stakeholders have a common understanding of all relevant aspects of the project and the problem being solved, else we risk causing disappointment or—in a worst case scenario—misunderstanding and delivering the wrong solution! Putting thought into how a shared understanding can be achieved is particularly important when working with an external partner or supplier. This includes when buying a commercial off-the-shelf (COTS) package, or when working with an external development or managed service provider (MSP). When writing and communicating requirements to someone outside of our organisational boundaries, we need to be doubly sure that we are clear and unambiguous. Internal and industry terminology that we take for granted may have a very different meaning outside of our organisation or industry. This is even more relevant when the external partner is in a different culture or country.

Including a simple glossary can make a huge difference. In fact, it is good practice to utilise a glossary in just about every type of project–it helps ensure that we have the same understanding of core business terms as our stakeholders. It also helps us to uncover situations where stakeholders use the same term differently.

For example, we might find that the term “customer” is used by the field sales force to mean a large organisation (i.e. a company), whereas staff in a call-centre may use the term “customer” to mean individual customers that ring in. This could cause misunderstandings, and it could be better to refine the definition and use “corporate customer” and “retail customer” instead. Defining this up front helps avoid trouble in the long run.

A glossary needn’t be complicated: a table with ‘term’ and ‘definition’ works perfectly. This can then be shared with our stakeholder community.

 

2. Project Objectives, Outcomes and Benefits

Communicating the requirements to those responsible for delivering a solution is crucial, and it would be easy to fall into the trap of thinking that this is all we need to do. However, it is also extremely beneficial to communicate and share a summary of the project objectives, outcomes and anticipated benefits.

Providing this summary helps those developing the solution to gain an understanding of why the solution is needed in the first place. It provides an overall context for the requirements package and can help inform detailed design decisions–this is particularly relevant if a design trade-off needs to be made. If the desired outcomes and benefits are known, the supplier is able to come back to the client with suggested proposals, which will be aligned with those objectives. For example, if the main objective of the project is to increase efficiency, then ensuring the solution is quick and allows users to process work quickly will be crucial. This will no doubt be reflected in the requirements also, but stating it up front will help all involved to see the wood for the trees.

Additionally, having the project objectives, outcomes and benefits clearly signposted has another significant advantage: it helps keep our focus on the scope. If we can’t map a requirement to one of the objectives, then we should ask “is it really needed at all?” Ensuring everyone on the project — whether they are internal or external — are keeping a firm focus on scope is extremely beneficial.

 

These are just two potential candidates for inclusion in a requirements package. As business analysts it’s important that we capture the right information for the project and organisational context. However, adding these two core sections to our requirements package can help aid communication and avoid confusion in the long run.

 

What are your experiences and tips? I’d love to hear from you. Please add a comment below.

 

If you’ve enjoyed this article don’t forget to subscribe.

 

---

This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business