Using prototypes to write requirements

When I started out as a Business Analyst, I worked on many small projects that dealt with internal application development.

Requirement elicitation was easy as the requirements were precise and the user navigation steps were simple. I didn’t have to think much from the design and spacing perspectives as all the stakeholders, and end users were from within the organization, and as long as the purpose of the application was being served, the design of the application would take a backseat.

But as I progressed and took up bigger projects – projects that were creating revenue for the organization and that were being used globally – I realized that I had to be very careful in writing the functional requirements. I had to be aware of each and every functionality on that screen to make the requirements more effective. The user management had to be explained in detailed, and I had to keep in mind the design of the application and be more though with the navigation flow.

Initially, I used to take the visualization approach in writing the functional requirements – Imagine the flow in my head and keep writing. However, when I reviewed these requirements, I observed that I did miss out on some aspect or the other. Eventually, I had to add more details to complete the requirements.

I then began to use prototypes to write the functional requirements. Remember how back in school we were told to use paper for rough work to do our mathematics calculations. In the same way, using prototypes to solidify the navigation flow can be a good approach.

As per many, a prototype or a mock-up is defined as the blueprint of screens or a visual guide that represents the skeletal framework of a website. A better version of a mock-up is a wireframe. Wireframes take into account the complete design aspect of the software. Mock-ups are rough drafts created in the beginning to put the elements of a website in place.

Take this for instance – you are required to spearhead a project in which an application has to be developed with which end users can buy fashion accessories. Some of the initial questions you may ask the stakeholders would be about:

• Customer base
• User journey
• How will the payments be processed? The payment gateway integrations
• If user can make a purchase as a guest user
• Where will the user apply the promo codes?
• Which filters can be used by a user?
• Are we maintaining any order history?

The answers to these questions will help in drafting the high-level requirements. But what about the following questions?

• What all can a user do in his / her account? – Change profile
• How will the navigation between pages be? This may seem simple, but the stakeholders may have a different opinion. For example, you may think that when a user is on the review order page, and when the user clicks on continue shopping, s/he should land on the product listing page. But the stakeholders have a different requirement – They want the user to land on the home page of the website. BAM there’s a gap now!

---

---

Case – Requirements without a prototype

Let’s say you are to capture requirements for the order history page in the user’s account. You imagine the page in your head. You first write about the basics – The page will have the following details:

• Order No
• Product details
• Total amount
• Promo Code discount
• Amount paid
• Status

Case – Requirements with a prototype

Now, what about the details at the granular level. You make a mock-up with the information above and analyze the order history page further.

• Can the user click on the product details and view the different products in list form? If yes, then can the user select each product to view its detailed page?
• Can the user view the amount breakup and the mode of payment?
• Will the status be a pictorial representation or just a text?
• Where will the images of the products be placed?
• Given the layout above, how will the space to the right be utilized? If the stakeholders request to add some banners how that will be done?
• Does the return and exchange of a product happen on this page?

This is just a small module. When it comes to the entire application, the complexity may increase, and the requirements may have to write in much detail.

Mock-ups are the binding agents of the requirements. They help in understanding the user journey which can eventually help in effectively drafting the use cases. These are easy to make and are effective in identifying gaps. While various tools are available in the market, mock ups can be done in the basic pen paper mode too. One doesn’t need to be adept with the design aspect. However, a BA should consider each aspect of a screen and make sure if there’s a requirement associated with it. The main purpose of a mock-up is to have a complete picture of the user journey. Moreover, the feasibility of the features can also be assessed.

Having a mock-up for reference can be helpful in the following ways:

• Functional requirements can be written in a modular way. As mock-ups deal with all the screens of the software, one can map the navigation amongst these pages and write details about the user journey.
• It helps in filling up the requirement analysis gap. For example, during requirement elicitation, the stakeholders may skip a feature. However, if a rough structure is in place in these sessions, the chances of missing a detail are minimal.
• One doesn’t miss out on a user story. For example, the order history is in place but as a user, can I sort/filter the records? If I click on an order, can I see the detailed page of a product purchased?
• Requirements when coupled with mock-ups give a clearer idea to the developer who can consequently code with confidence.