Skip to main content

Author: Poorti Mehta

Requirement Analysis for E-commerce Projects

E-Commerce – A platform that has revolutionized the way we shop.

From clothing merchandize to grocery items, almost all our daily requirements are now met by such platforms. Such an application plays a crucial role in many businesses these days. 

For an e-commerce project, the main business requirement is the same – A user comes to the platform and purchases products. The challenge for a business analyst is to visualize all the processes in between. The scope of an e-commerce application is large. At the micro level, the requirements can vary depending on the nature of the products being sold. At the macro level, a business analyst can make an outline of the following requirements – business and functional that hold true for a majority e-commerce platforms. A checklist can include the following pointers:

1. User actions on the website

What all actions can a user perform on the website besides making a purchase? These include:

  • Searching for products on the home page or throughout the website and on what basis. Products can be searched on the basis of product name, categories, brands etc.
  • Sorting products based on the filters provided. Which filters need to be placed? For clothes these can be colours, sizes and types. For grocery these can be fruits, vegetables, frozen foods and dairy products. For health insurance products these can be age group, premium limit, waiting period, maternity cover etc.
  • Adding products to a wish-list. If these products can indefinitely remain in the wish list till their respective stocks last or can remain for a definite period of time.
  • Making use of available promotional offers and discounts and the business logics behind them.
  • Creating an account. Is an account mandatory for making a purchase? Is buying as a guest user an option?

2. Admin Console

This is an important module of any e-commerce application. A business analyst should clearly determine the aspects that an admin can control from the backend. These include:

  • Product Management – All the metadata of the products – Product images, description, seller information, prices etc. Admin should be able to manage this data i.e. add, remove and edit a product.
  • Content management – The design aspect of the website i.e. the static pages a user sees at the front end. It’s important to create an attractive and effective website to attract and retain traffic. The answers that a business analyst should seek here are – How will these pages be maintained? Will these pages be uploaded or a provision has to be made for the admin user such that pages are created through the system?
  • Master Management – Besides the product data, there are other masters that need to be managed at the back end. Country, State and city masters, seller masters etc. are just a few examples. For instance pin code masters help in extracting a city when the user enters the pin code while adding the shipping address.
  • Admin should be able to carry out promotional activities. Admin user should be able to create promo codes and offers as per the business requirements. 

3. Inventory and logistics Management and Order Fulfilment

Remember how we add some products to our wish lists and when it’s time to buy them, some of the products go out of stock. Or the time when a sale is announced at mid-night but you log in early morning only to see that the products in sale were brought overnight. We have all been through such times. At the backend, this management is crucial to keep the website up to date with the latest numbers. Whether new products are added, products are returned or exchanged, dispatched, all the logistics and stock details should be maintained in a robust system. Additionally once the products are purchased, some businesses require fulfilment systems that can be used by the dispatch and customer services teams. A business analyst should capture all the business requirements around this piece.


Advertisement

4. User checkout and payment

  • Generally users can check out as registered users or as guest users. An option of creating a new account is also available. Some businesses require customers to make an account in order to place orders. The information required to create an account needs to be considered.
  • Payment options can vary – Cash on Delivery, E-Wallets, 3rd Party Payment Gateways. Vendors are selected as per the requirement of the business.
  • The shipping charges and methods. These can be either maintained at the backend or made static.

5. Promo code application

It’s important for a business analyst to clarify the application area of these codes. At what point of the user journey can a user apply a promo code?

6. Mailers

Automated mails are triggered to customers on a majority of actions – when an order is placed, when an order is returned or an exchange request is placed, when complaints are logged, when new accounts are created, etc. Besides the standard practices, promotional campaigns are also run. Requirements should capture the mails to be sent for every action and the content for each mailer.

7. Reports

Analytics is an integral part of e-commerce in today’s date. A lot of third party tools are used by businesses to curate reports that’ll help the businesses to make informed decisions and plan further actions. The type of reports should be added to the business requirements.

Virtual Collaboration

What are the major modules of any application development project?

  • Requirement Gathering (this one requires some rigorous re-iterations)
  • Approval from all stakeholders and drafting a BRD (Business requirement document)
  • Defining a Scope of Work for the project
  • Preparing other documents such as process flow diagrams, technical documentation, module trackers, reports etc.
  • Development activities
  • Performing tests on the UAT environment followed by bug reporting and bug fixing

And once all these activities are taken care of, there’s a production movement.

But it doesn’t stop here. There are change requests from stakeholders and thus begins the change management process which eventually ignites the version control process.

While we are on this journey, we face certain challenges. Some of those pictures look like this:

  • You get notified that there’s an external technical audit next week and you have to get all the relevant documentation sorted. Gosh where were the release notes saved? Are the documents in order? A change was requested on the home page 3 months back. Where are the details?
  • My system has become a warehouse of documents. I spend so much time organizing the repository that organizational skill should be included in my KRA.
  • Requirements for this project are changing at lightning fast speed. This wasn’t the case with my last project.
  • I don’t exactly remember the details of this feature. Wait let me check my e-mail from the stakeholder who had explained it to us. *About 150 emails later* Well, I will just ask him to forward that mail to me.

As a BA I have had my own share of experiences at every step of an SDLC. Over the years what I have realized is that organizations need to invest in appropriate tools and software for a smooth project execution and thus I can’t emphasise on the use of good project management tools just enough.

When I started out as a BA, I learnt the basic documentation that’s common for any software project. Just like many of us on this forum, I too didn’t completely understand the great necessity of documenting each and every step then. It wasn’t until after my first software project went live, that I could see the picture more clearly.

Change requests started pouring in quite frequently and we had some new developers absorbed to the project. And thus came more documentation, version controls, diagrams, trackers and so on. From just one folder, this project grew into 6 -7 folders on my system. Innumerable mails were exchanged to discuss even the smallest and yet an important aspect of the website (read – colour of a button on a webpage). When the new developers were to be briefed about the project, I spent a lot of time in figuring out the relevant documents to be shared with them. Documents that would give them clarity on the process and the progress of the assignment. Sometimes, the stakeholders would lose track of the progress or would misplace a document or go through an incorrect file. In this chaos I realized that a lot of effort was being wasted to maintain the Collaboration.


Advertisement

Collaboration – A significant aspect of any project and a key skill for a BA. Project management and collaboration tools and software are a great way to minimise this chaos and they do wonders for a project’s lifecycle. I learnt this the hard way.

For my next project, we made use of a leading collaboration software. Everything right from requirement gathering to scope of work to change requests, were captured in this application. There were a lot of advantages of using this software:

  • It could be accessed by all the stakeholders. Hence, whatever changes were made to the requirement or any other module, everything could be viewed by all.
  • All the relevant documentation was uploaded here. The changes were made online.
  • The project plan was chalked out smoothly with supported Gant charts.
  • Feedback notifications were received on real time basis and this helped in faster sign off of modules and requirements.
  • All the project essentials were stored at one place. Unlike the earlier project where everyone had to maintain a separate repository, the repository of this project was stored online. All the literature at one place – securely stored.
  • The developers were making notes hassle free.
  • The milestones of the project could be efficiently tracked.
  • Lesser emails were exchanged. I didn’t have to send that scope for sign off again or send the updated tracker over and over again.
  • I didn’t have to worry about the back up of documentation. Version controls were in place.
  • With a user friendly interface, it was fun working on the documentation and creating user stories. As I got to work on more documentation, I received some very constructive feedback form my immediate seniors and this helped me to improve my data capturing skills. It was here that I understood the importance capturing even the tiniest of detail related to a web page. As all my seniors were on the same project space (of the application) they could view the work I was doing and thus I had feedback from everyone.
  • Presentations to all the stakeholders became easy and necessary documents and reports could be extracted during audits.

With this change in the process, the first cut of the project was delivered in just 4 months (as compared to 6 months in the earlier project). This is how virtual collaboration helped us.

With such user friendly applications and so many of them in the market, organizations should not hesitate to invest in these applications for their projects. For small size companies, there are open sources available in the market too. Also with most of these applications offering a free trial period, one can explore the best fit for a project. Tools that ensure effective collaboration can make project execution easy. Making the best use of the cloud technology, these applications are a complete back up of a project’s records and documentation.

What tools / applications have you worked upon? Have you faced any similar challenges? Please share your organizational experiences and the challenges you faced that prompted your organization to implement a better architecture.

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!

Advertisement

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.

mehta 03012018

  • 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.

Assessing Requirements in Requirement Gathering Sessions

For a Business Analyst a project begins with requirement gathering or eliciting requirements (a popular term used to describe this task).

Workshops, interviews and brainstorming sessions – the more a Business Analyst conducts these methods of requirement gathering, the clearer a picture gets to him / her. Amidst these exercises, how important is it for a Business Analyst to simultaneously analyse a requirement or rather weigh a requirement? In other words how necessary is a requirement?

Although a thorough analysis is undertaken once all the requirements are gathered, it does help if certain requirements are assessed at the time of requirement gathering.

In one of my recent sessions certain high level requirements were discussed. These requirements were for an application that was requested to be developed for an internal sales team. Post the overview began the requirement gathering. I had my set of questions ready and took up one module at a time. A couple of minutes into the session, just as I was about to jot down one requirement, there came an opinion from one of the stakeholders. An experienced IT professional who has been associated with the organization for about 15 years and who is an SME on Financial Technology, begged to differ with this requirement. He posed some very important questions:

  • Is the requested feature really required?
  • What if there were an alternative? What if the purpose could be solved with a slightly different form of the feature?
  • The time effort and cost analysis if this requirement were worked upon and the time effort and cost analysis if an alternative were developed.

Now it took some solid ideas for the SME to convince the stakeholders to alter the requirement. All the stakeholders dug deeper into analysing the actual ‘requirement’ of this ‘requirement’.

To sum up an alternative was agreed upon. This alternative served the purpose of the business stakeholders, was economically feasible and could be developed in lesser time all without compromising on the quality of the application and the purpose of the feature.

Not all the requirements that are put across have the same nature. But there could be times when the business users are hell bent on having a complex feature in the application or they may want to implement a module on an existing application just because they happened to experience a fancy feature in the application of a competitor. While some requirements may be very helpful to the business, there may be certain requirements that can be optimally altered.

  • Requirement Gathering shouldn’t be about just jotting down requirements – Some requirements may not be needed at all or there may be better alternatives available. Such alternatives should be put on the table and discussed. The following questions can be asked:
    • How purposeful is the feature / requirement?
    • If the requirement is essential but it will take a lot of time to develop what can be done to deliver an alternative?
  • Stakeholders may come from either a technical background or a non-technical background – Some of them may be from a non-technical background but may possess a sound technical knowledge. However, if a stakeholder is from a non-technical background and doesn’t know the development process thoroughly, chances are high that a Business Analyst will have to discuss a requirement in more detail. They may not know the development process thoroughly. But you do. You know how much effort goes into developing the smallest of module of an application.

Advertisement

A stakeholder may not be completely aware of the time taken for development or the cost involved in undertaking the development of a module and making changes. In such cases, a Business Analyst has to dive deeper and ensure that the requirements serve the purpose of all.

  • In most projects, requirements undergo frequent changes – Stakeholders expect to go live with a product with almost all the requirements raised by them; even the changes. However given factors such as cost time analysis, project development time frame, priority of the project and availability of the resources deployed, it may not be possible to involve all the features during the launch. The requirements thus need to be prioritized keeping in mind the interests of all the stakeholders. While the major requirements can be taken in the first phase, the remaining can be put into the subsequent phases.
  • Requirement Gathering along with simultaneous analysis helps to save time during documentation and consequently project planning – If a doubtful requirement is discussed then and there and the alternatives are weighed, the stakeholders can reach on a consensus and consequently the requirement can be clearly documented and closed. This saves a Business Analyst from consequent follow ups required for requirement clarity or discussing changes.
  • A project may seem to be a simple at first however it’s only when these requirements are thoroughly analysed that the complexity of the development can be understood. Thus questioning a requirement in the interest of project development is important.

Weighing requirements is as essential an activity as requirement gathering. If done in the initial requirement gathering sittings, the subsequent processes – requirement documentation, sign off and planning can be smoothly accomplished.

Building Blocks of a Project Plan

In almost all business analyst job listing, we find the following tasks listed:

  • Work closely with the development team to create the final product.
  • Act as a liaison between the business team and developers.

While there are a number of tasks a business analyst has to do, these two are critical to any project and take up most of the time of the BA. However, there are other tasks that will require adequate time and should be included in a project plan.

Related Article: Planning is Not a Solo Activity

A project plan forms the crux of any project. Without it, a project has many loose ends and can go on for a long time. A well thought out project plan helps to track every module of development. The plan should include time frames for each module and should also include buffer time for aspects such as change requests, UAT window, etc. A business analyst should devise time frames by keeping the following modules in mind:

1. Communicating the requirements to the development team.

A development team is the creator of an application / product. But unless a developer understands all the aspects of a project, the final product may have some shortfalls. This is where a business analyst comes into the picture.

In one of my recent projects, a developer was asked to integrate a certain insurance plan on an existing web platform. Although he had worked on such assignments before, this product was different. He was handed some documentation, and the development commenced. A few hours into the development, he realized that there was more information than expected and hence he didn’t know how to place all the modules together.

Developers are technical people. It may not always be the case that they are completely familiar with the purpose of a product. Business analysts are well versed with the requirements and understand a product fairly well. With a project plan, a business analyst should include the time that’ll be required by the development team to study and understand the relevant development documents.

2. Ensure that testers have good product knowledge

Before a project goes live, it should be screened thoroughly by the testing team. Good test cases can be created if this team also has good product knowledge.

For instance, let’s say the team has to test a mobile application which lets a user compare different financial products. The testers may miss out on some aspects if they don’t know the nitty gritty of the product. They may not be completely aware of the products available on the application and may not be able to compare the products as required. Time should be devoted to this knowledge transition exercise.

3. Change requests

No project begins with a foolproof blueprint. A well-executed project is the one which can smoothly accommodate change requests. Here’s where some buffer needs to be added to a project timeline.

In one of my recent projects, we were ready to launch a product when a stakeholder placed some last minute requests. However, this did not impact our go-live date as we had made a provision of 5 extra days to our project timeline and that was sufficient to include these changes.

4. Complete testing window

Testing can be categorized into functional testing, user acceptance testing, quality testing, etc. Based on the requirement of the project, each testing phase should be given adequate time support.

5. Final sign off from all stakeholders

Although this final leg may seem like a cakewalk, there can be times when a project gets delayed due to unavailability of one or more stakeholders. It becomes important to ensure that all the stakeholders are present on the sign off day.

Finally, once a business analyst prepares the project timeline, the timeline should be shared with all the stakeholders, and there should be consensus on that timeline. This helps the business analyst be effective at tracking of any project.