Requirements vs. Solutions

Welcome to our first post, and what we hope will be one of many in a series on analysis and project life cycle. This series is designed to help our clients prepare for early-stage analysis - getting everyone on the same page with a shared vocabulary from the start.

The topic for this post is requirements vs. solutions.

One of the great things about the human mind is its ability to imagine the future. Even better is when we work together as a group, combining our imagination to create a shared vision of how something might be. If we can create a collectively agreed shared vision, then all that's left is to create a plan and make it so.

Depending on how big the plan is, you'll likely also need some kind of process to help steer things along. In software development, we typically refer to a process called the system development life cycle, or SDLC. We'll be writing another post that describes the SDLC in more detail (including various methodologies within the SDLC) but for now, suffice to say that every project begins by articulating a problem, a desire, or an aspirational future state. This is the project's mission, and is quickly followed by the first formal phase of analysis - generally referred to as the conceptual design phase.

One of the tasks of the conceptual design phase is to break the project's mission into smaller bite-sized chunks, and then describe respective requirements for each. There are several approaches and tools that can help with conceptual analysis. For the moment, let's pretend we're clear on why and for whom we're building our system and focus on one of the early challenges of language and how we express our requirements for the problems we're trying to solve.

Let's also pretend that in this case we're discussing just one component of a learning system - specifically, course registration.

Before we create a more formal specification we'll state a few high-level requirements - things we imagine will help visitors easily register for a course.

For example:

1. It should be easy for users to register with a minimum amount of personal data supplied.
2. There should be an easy way to contact someone for any questions about the course, or questions about the registration process.
3. There should be plenty of easy-to-access information about the course available before registration in order to help the visitor decide if this is the right course for them.
4. The visitor should somehow receive confirmation that they have registered.
5. After registration the visitor should be guided to some additional introductory material for the course.
6. After registration the visitor should also be encouraged to complete a more detailed personal profile and join an introductory discussion forum.

We have a pretty good list of requirements. What's more, at no point have we said how we plan to do any of this. We've kept possible solutions (the actual way in which we might implement some of these requirements) out of the equation for now. At no point did we specifically say this has to be a computer system or an online registration. If you read the points above again you could also imagine all of this being done by paper with forms dropped off at a learning center with staff available to help with the registration as well as provide additional information. Even the 'introductory discussion forum' could be a group meeting or workshop run at the learning center.

Let's assume that we are building some form of online course registration system and we're discussing the requirements - essentially the points we've already included above. But let's also assume that in this case we have an excited team and they're discussing possible solutions - mixing requirements and solutions together in their description of how they imagine the system might work.

Here are a couple of examples of the team's stated requirements:

We need a form with a nice large button and just a few fields, so that people can easily register.

As hinted at above, we've jumped ahead a bit by including requirements and possible solutions - mentioning a form, a large button, and just a few fields. This might seem innocent enough, and of course the team working on this might all agree that this seems reasonable, but a more accurate way to describe this is to say (as we've said in point 1 above) that "It should be easy for users to register, with a minimum amount of personal data supplied."

Here's another...

We need to create a help area, maybe a tab at the top, that visitors can click on to find extra information about the course.

Again here we've made some solutions statements before clearly identifying the problem we're trying to solve. A 'tab' has been mentioned - does this really mean a tab? Or a menu item? The position of the help area has been suggested as 'the top' - again a design suggestion that might be a good one, but why not at the side? Or on the left? Again, as in point 3 above - what we really wanted to say was that there should be plenty of easy-to-access information before a visitor registers.

The point to all of this is not to take the fun out of imagining how the system might be built, but rather to help us all understand the difference between possible solutions and the problems we're trying to solve.

Keeping requirements or problem statements separate from solution statements for as long as possible in the early stages of planning and conceptual design helps to cleanly separate these concerns and extracts the solutions design effort into a separate phase of work. And while the solutions (the how) might seem obvious in certain cases, treating the solution design effort as a separate task also allows us to separately test our proposed solutions against our target audience, and maybe even open up the possibility of considering innovative approaches that solve some of the problems in ways that haven't previously been considered.