Requirements engineering

Disclaimer: I am not a professional business analyst

I have been involved in a few projects and I have always followed a similar pattern into getting them to completion. I have broken down the process into different phases and although this may initially read like waterfall, in reality, it is a lot more collaborative as we try and find the hidden requirements through conversations rather than documentation.
This post is an effort to jot down a few notes and hopefully give readers a few things to think about.

Problem Discovery

· Understanding the constraints of the problem both technical and social
· Discovering the different stakeholder(s) requirements both explicit and contextual

We can't build the right thing if we do not understand the context in which the thing has to exist in. This can be both technical and social. Technical questions to ask:

• Who's going to use this?
• What other software are they familiar with?
• If we build it, how will it be deployed?
• Who will maintain it going forward?
• What technology stacks are the future maintainers comfortable with?
• Have the future maintainers been told that they will maintain it yet? Did they agree?

Social questions to ask:

• Which organisation(s) are funding this?
• Why are they funding this?
• Who will be the primary decision maker(s)?
• What are the main motivators for the primary decision makers(s)? Keep in mind that the motivations of the human decision makers are different to the broader motivations of an organisation.

Solution proposal

· Iteratively propose and refine solutions with the client usually with wireframes
· Arrive at a loose, shared conceptual agreement of what will be delivered

Hopefully after the problem discovery phase, you will have identified the primary decision maker(s). The goal of this stage is to reach a loose, shared conceptual agreement of what will be delivered and my favorite way of reaching that is through low fidelity wireframes using Pencil.

There are a few benefits to creating wireframes. Firstly, you can map it against your existing or hypothetical API to see whether or not your things is possible or not. Secondly, you can show them to clients and in seeing something visual, they can much more easily where you have missed key concepts and why it won't work for their use case. As it is easy to iterate on wireframes, you can incorporate their feedback to come up with new designs to meet their use cases. This has the very very important effect of making the client feel listened to which goes a long way to establishing trust. Furthermore, as the client sees their changes make their way onto the wireframes, they gain incrementally more ownership of it which may help increase the emotional attachment they have to the project.

After a few iterations, if there are no more major changes, then you can be fairly certain that you have reached the "loose, shared conceptual agreement" goal and the project can move onto the next phase.

Project delivery

· Set up architecture based on the skills/interests of the team
· Incrementally deliver and demonstrate developed functionality
· Negotiate and prioritise additional or changed client requirements as they are discovered

When choosing your technology stack, the most important thing to consider are the skills and interests of your team. I usually like to follow a very loose scrum process where we have standup to ensure that people aren't blocked for more than a day.

Post project

· Document lessons learnt
· Advise on possible futures for the delivered project seeding future collaboration opportunities

After the end of the project, it is important to hold a retrospective style meeting and to document the lessons learnt. By writing these down, it both increases your understanding of what went well or didn't go well and makes it available for other people to view thereby increasing the knowledge within your organisation.

It may also be helpful to have a more imaginative session with the team and the client where you muse on possible futures of your project. Although the money may not be available now, these seeds may fruit into future collaboration opportunities.