Analysis: Requirements Development

Or; the development of Customer Requirements. Many people outside of the field see analysis as little more than asking questions, getting answers and writing them down for someone else to decipher and 'develop'.

There is of course much more to it than that. Before an analyst can ask any questions, they should learn their domain, and the customer's processes. They must understand the pain points and issues but also pay attention to the parts that are efficient and fine tuned. They need to understand the priorities, the risks and the high level requirements of the customer. Then, and only then, can they begin to drill down into those requirements to identify the real need of the customer and determine what can be done to meet it.

Quite often, the initial 'requirement' that kick-started the analysis process ends up being a minor requirement, or a non-requirement as it itself, was a result of a convoluted or inefficient process (either system or manual). By fixing the process itself, you satisfy the requirement or remove it entirely.

The job of any analyst is to take the requirements of a customer and turn them into something that can be delivered by a development team. The trick of a good analyst, is to take the requirements of a customer and develop them into something that meets not just the initially documented need, but something that addresses the core issues behind that inital need, and facilitates an improved business process, and a more efficient technological solution to support it.

Developing Real Requirements

There are many ways to develop requirements, to move away from documenting what the customer thinks they want, and manage to identify what the customer actually needs. It is inevitable that a long-standing business process will have manual procedures and ad-hoc activities ingrained, and very often the people responsible for those processes don't notice the effort involved. So many requirements are raised which when scrutinised, turn out to be supporting an inefficient or insufficient process; new reports because a system doesn't provide data at the right level, new system functionality because an existing workflow no longer reflects the business process, a new version of existing functionality because the customer offering has diversified since the existing system was built. It would be easy to take the tactical route, to build a solution to meet the initial requirement. But, is that the right thing to do? Is that supporting our customer and giving them what they need, giving them the best possible customer service as an analyst?

I would argue not, and that instead we should be focussing our efforts on addressing the underlying issues (budget, time and resource willing). It is inevitable in this digital age that the products a customer offers to the market will change rapidly, and that a solution built even a year ago may now be insufficient to support the business processes. The strategic route would be to address the real problem; the fact that the existing solution isn't satisfying the customer's needs.

But, How?

Every analyst has their own methods of requirements elicitation, and every analyst works slightly differently. Here, I've listed my tried and tested methods for eliciting requirements, investigating them, and developing them into something that will really satisfy the customer's needs.

1. Workshops

Possibly quite a few of them. Workshops are, in my opinion, the single best way of meeting your stakeholders, meeting your end users (if you're working towards a technological solution) and learning business processes.

Have everyone in the same room, or at least a representative from each stakeholder area. Explain your agenda, identify, examine, and refine requirements. Doing it together, with your customers will bring rewards; you'll identify pain points quicker, you'll get answers to questions quicker, and you'll build domain knowledge much, much quicker. If you're working with a development team, it's also invaluable if you can get one or two developers involved in the workshops; it gives them early visibility and can vastly improve the end product if they have a first-hand understanding of at least the high level requirements.

2. Modelling

Everyone is different, and in the world of 'agile' we're only meant to generate necessary documentation. For me, a good number of models - both UML and otherwise - are essential.

Model the business process(es) at both a high level and break down in detail, model the domain, build a use-case model, even if you're working with user stories. I am very visual and need to see a process laid out in front of me, and the added benefit of modelling your processes is that you can examine them together, in (another!) workshop, ensure they're accurate, and pinpoint complexities or wasteful practices. A good collaborative tool like Lucidchart is essential for this sort of activity.

3. Wireframes, Storyboards or Mockups

Initially this seems like something that is useful only if you're dealing with the implementation of a system; I've spoken to some Business Analysts who say that mockups aren't their remit. My role involves aspects of both Business and Systems Analysis (and Product Ownership!) and mockups are a very useful tool. I would also argue, however, that a good storyboard can add value to the analysis of even the most manual business process; say, customer services. A storyboard, at the right level, can help explore the user experience when interacting with the customer, and identify parts of the process that could be simplified.

4. Acceptance Criteria

In a truly agile environment, acceptance criteria may be written by the customer themselves, or a Product Owner. In reality, they are often written by an analyst, and it is certainly a large part of my responsibilities in my role. As well as being the main output that you will (may) provide to the development team, they play a crucial role in ensuring that you have understood the requirements from a business perspective.

Write them out and go through them with your customer and your end users, maybe in collaboration with a mockup or wireframe, and alongside a variety of process models, and make sure they're right before they go to be developed; this will reduce bugs that come from 'misunderstood requirements'.

5. Demonstrations

It may seem simple, but if you are working on a technological solution, giving or receiving a demonstration of the current system in use is invaluable. It will enable you to see the areas where the solution is lacking or inefficient, and sometimes even identify cases where a system is not being used to its full capacity, where user training or a few minor tweaks could massively improve the customer's experience. Remember; analysis is not all about gathering new requirements. If at all possible, it is our job to reduce the requirements in the first place.

All in all, it's clear that there are many different ways to gather requirements, but gathering the right requirements, involves collaboration, persistence and a lot of questions. Happy analysing!