You are expected to ace in one skill while aiming for a business analyst role. Good stakeholder management skills followed by documentation skills will take you places. Now that I have started actively preparing for the Business Analyst roles. I am paying attention to the job descriptions specified by all types of organizations. While scanning the job descriptions, one pointer which was common was “drafting requirements followed by writing user stories”.
“What are the different stages of the Software Development Life Cycle” is one of the simplest questions asked by the interviewer. The answer is pretty simple and if you are an engineer, you will name all the stages in no time. However, the skill will be tested further.
You can refer to the image below for the answer:
You will be expected to conduct stakeholder meetings as a Business Analyst. Your job is to capture client’s expected requirement specifications from the product. Big organizations use tools like TFS (Team Foundation Server) and JIRA tools to record the requirements. A Business Analyst working in small or medium size organizations make use of tools like GitHub, Google Docs and Excel to maintain the required records.
When I started working as a Consultant, I assisted the Senior Consultant in drafting the requirements of the customers. I trained in documenting user stories. I kept the points mentioned below in my head while working on it.
- User’s Perspective – The drafting is done by noting the behaviour of the user. If you were not
the part of the meeting with stakeholders then make sure you interact with the teammates who attended the meeting to get a better idea. - Identify Key stakeholders – It is your job as a Business Analyst to make note of the key stakeholders while capturing requirements from them. The more clarity you have here, the more are the chances of covering more use cases.
- Use Personas – If you work with a team, you can create personas by considering users and giving them names and personality traits to gauge their expected behaviour on the product.
- Simplicity – Simplicity is the best policy here. You can achieve it by keeping the user stories precise and clear enough for the developer to work on it.
- Refining – Your user stories will need refining till you are convinced with the output. It must not convey multiple meanings and it won’t end up creating chaos among the developers.
- Acceptance Criteria – It is best to mention the acceptance criterions along with the user stories. It gives the developers the test cases to develop the module. The team is empowered with the idea of the data to be pulled from the database.
You can find templates on google if you want to follow a format. The one mostly used in organizations consists of fields like:
Scope – You need to mention the objective of your User story here. For example, Searching for User details. The scope title can be followed by a brief description stating the User. The users with Admin access for this module to look for specific user details from all user records.
Pointers – Explain each expected user story and specify test cases along each point to keep things sorted from the beginning.
- As an “Admin”,
user wants to use the search field here to look for user records. - User Record for the searched user profile should display fields like Name, Department, Phone number, Official email ID.
- Name Field to display Full Name in the specified format – First Name/Middle Name/ Last Name.
- Department Field to display Name of Department and Name of School heading that department.
- Field displaying the Phone number to display Country Pin code followed by the contact number
- Field displaying email ID to mention only the Official email IDs with the extension of ABC@university.co.edu
A detailed document can save a lot of work and makes the process of implementation and testing simple. You
