3 steps to requirement gathering.

Often, when  business analyst gather requirements, its natural that below questions to revolve and spin around their head.

Where do I start? Should I navigate through the process first or ask the process owners about their wish list or maybe jump to gather requirements of the TO BE system.  A great detail of confusion isn’t it? Over a couple of years and after few experiments and deliberations, I have arrived to a state that seems to be working for me. Before I share my experience let me inform you that Alec sharp has greatly influenced me to settle down with the current process of gathering requirement.

1. The process:

Process is the foundation to develop usable applications, especially when the request or transaction changes multiple hands. On the contrary if there are less activity owners then a jump to mock ups won’t really hurt. For instance requirement gathering for a facebook or instagram like app won’t require a process to be written.

2. Create Data relationships

Regardless of complexity, size or feature set, you can break down any web application into simple operational mechanics:

1. The web app takes in data from users

2. The web app processes and decides what to do with that data

3. The web app produces some output for the users

All web apps work like that, so at the start, it’s best to break down your web app’s core features into data relationships to see:

• How your web app should be built

• How your web app might deal with user data and presentation

• What features you need to prioritize

• What web services and web technologies you’ll need to enlist and get familiar with

For example, let’s take the primary feature of Instagram — posting a photo up on the photo-sharing service — and break it down into the fundamental operational mechanics above:

1. The web app takes in a photo from users

2. The web app processes the photo to scale it up or down to the layout of Instagram and also what photo effect the user wants to apply to the photo

3. The web app produces a modified image and displays it for the users

 Lets create a breakdown of the data relationships like this:

Users

Has 2 permission roles (User and Admin)

A User can upload Photos

A User can manipulate Photos

A User can like or dislike Photos of other Users

A User can comment on Photos

 

Photos

Photos are uploaded by a User

A Photo can get a Filter applied to it by the User who owns the Photo

A Photo can get liked/disliked

A Photo can get a Comment

A Photo can be deleted/edited/updated

A Photo can be private or public

 

Filter

A Filter can be applied to Photos

A Filter can be created by an Admin

 

Comment

A Comment belongs to a Photo

A Comment can be created, edited and deleted by the User who own the Comment

A Comment can be deleted by the User who owns the Photo where the Comment is on

 

3. Jump to mockups and prototypes:

Now that we have our process and data relationships in place, lets jump to creation of mockups. There are two types of mockups: Low fidelity and High Fidelity.

Low fidelity mockups are paper sketches that makes it easy to understand the requirement little bit more in detail. This kicks in the thinking process that aids in creation of high fidelity mockups and prototypes plus it saves a loads of time.

High Fidelity mockups are made using online tools that have interactive elements built in.

Prototype – Finally, at best prototype built on HTML5 and CSS3 serves as a virtual replica of your to be system. If you have loads of time before the development is to begin, prototyping is feasible solution. The second best candidate is high fidelity mockups in order to translate requirements to your developer.

Focus on Behavior and Less on Look-and-Feel-

Quite often, frustrations that people have with a web app come from the way it behaves, not the way it looks.

I’m not saying you should ignore how your web app looks altogether, but I think that this is something you can refine, polish, and invest in more once you confirm your solution is something users actually want.

What I’m suggesting is that you direct your time and resources into your web app’s value proposition — which for a web app is usually the fundamental problem it’s aiming to solve for its users.

If you like this article follow me on Twitter for more updates

PS: The article is written keeping in mind building applications for small to medium scale enterprises but the ideas are not restricted to building large scale applications.

Thanks Alec for instilling process based thinking and Marc Gayle for inspiring on Data relationship based thinking.