What is the first thing that comes to your mind when you listen to words like “Software as a service”? Software distribution or licensing model, application hosting platform, pay as you go, future of technology, no server installation worries, no infrastructure costs, scalable. Imagine interviewing the key stakeholders and getting hold of exact requirements in terms of software and hardware specifications. What will be the questions to ask? Keep reading to know more.
Requirement gathering is the keystone for the team positioned in office to understand the customer’s needs. I have written earlier why it is seen as a good enough challenge for the individuals. It is rather an interesting process to narrow down on points that mean the most to your team. A lot of to and fro of questions is really not seen as a good practice by the stakeholders. The reasons could vary from their availability for calls to time zones to expectation of a drafted document following up the last meeting.
As a Business Analyst, you can pay attention to a lot of pointers while interviewing the stakeholders. The challenge could pop up when you sit down to draft these requirements. As I have covered it before, today we shall focus on what questions to ask your stakeholders. You can never start asking questions without really listening to the stakeholder’s story and the idea behind getting it developed.
We shall focus on how to document requirements for your team. Note that this is the first documentation shared by you with your team.
Table of Contents
Purpose
Highlight the exact objective of this requirement in maximum two lines covering the whats and whys here. For your understanding, let me take an example where a module needs to be developed to search and view user records using the search field. The purpose can be defined here as, ” Display and edit user records by the rights granted to the Administration department team”.
Project Scope
This point should elaborate more client specification if given, a quick three-pointer on an expected deliverable for the module requirement followed by mention of references if any. Here, the client was particular
(Name, Reg. ID, email and Mobile Number), Expected deliverable –
Admin can view all fields, edit fields. The update about the changes will be notified to the users. References section can have the status of screens for reference if any.
Development Scope
The module could work independently or could require a need for APIs to be developed. In this section, you can explicitly document the technical needs. For example,
“We already have API to fetch data from ERP system for this module”.
Stakeholders and responsibilities
This section
Operational Environment
The devices on which the required module will be used by the stakeholders. Many a time, a module is expected to be used in office by the department members hence its environment will remain restricted to the website and not the apps like Android and iOS.
Hardware and Software requirement
There could be a need to specify hardware requirements like some modules developed for the warehouse can demand
Communication Requirements
Whenever there is an exchange of information between two systems or a need to develop APIs to pull or push relevant information between two systems, this requirement is captured stepwise highlighting the API mode of sharing the data.
Permissions
In case of permissions to acknowledge changes made in the user records, you can specify the user type “Admin” here to acknowledge the changes in the user record fields done by the user type “member”.
Team Roles
This section is to highlight your team names and designations who will be developing the module for the stakeholder. This also gives assurance to the stakeholder team while communicating with the team members in case of clarification and further questioning.
Hope to have elaborated the key areas above while documenting the requirements. Leave a comment with your queries in the comment section.
