Many new business analysts are confident in their communication and problem-solving skills but feel held back because they’ve only ever created informal documentation to serve a specific audience or project need.
Are you confident in your ability to create formal requirements specifications just like a tried and true business analyst would?
Let’s look at how business analysts approach requirements specifications, what a hiring manager is looking for when they ask for experience with specific templates, and how to determine what your real capabilities are in creating requirements specifications.
How BAs Approach Requirements Specifications
If you begin to look at formal templates and BA methodologies, this can quickly become overwhelming. Sure, there are some big templates out there and you can find formal work samples well in excess of 50 pages, but the reality is that the best business analysts, in my not-so-humble opinion, create documentation that meets the need at hand, even if that means it doesn’t look very formal.
Yes, they might leverage their own repository of templates as a starting point or a checklist of questions to ensure the document is of high quality, but they realize the structure itself is not as important as the usefulness of the document in the context of the project and the stakeholder group. At their best, templates and checklists provide a structure that give you a starting point and can help improve your analysis processes.
Let’s look at some interesting examples that blend a user focus with just enough structure to be useful.
- Tony Heap gives us an example of a graphical functional specification that combines anything-goes diagrams with context diagrams and graphical use cases.
- I share my experience creating a user interface specification to document visual requirements as well as the various ways I’ve used use cases, even if it meant combining the “what” and the “how”.
- And here, Adriana Beal shares how she has used a wiki to manage requirements.
In each of these cases above, the business analyst has leveraged pieces of what you might find in a formal template and presented the information in such a way that it is easier for their stakeholder audience to consume, approve, and use.
What Are Hiring Managers Looking For?
While all of this can be true, what do you make of the job qualifications that speak to BRDs (Business Requirements Documents), SRSs (Software Requirements Specifications), Scope Documents, Vision Documents, Product Backlogs, User Stories, Business Process Models, etc.?
Well, before providing an answer, let’s do a little analysis of what a hiring manager might be looking for when they add such a qualification to their job description.
- They need someone who can package the requirements in a usable way (and their understanding of usable might mean by using a specific template).
- They need someone who can write requirements clearly and using unambiguous language.
- They need someone who can elicit the information and analyze the requirements so that the specification can be created in the first place.
Your skills in creating informal documentation, if it’s clear documentation that was usable by stakeholders and served a project need, satisfies the lion share of these requirements. Your skills eliciting and analyzing requirements at the level required by the requested requirements specification (business or process-related requirements for a BRD, scope document, or business process model, and functional requirements for an SRS, Use Case, or functional work-flow), will also be critical. The template or package is secondary.
But how do I convince a hiring manager of this, you ask? Well, let’s get to that next.
How Do I Determine My Requirements Specifications Capabilities?
You still need to be able to speak authoritatively as to how your documentation experience relates to what you will do in a business analyst role and specifically to the business analyst skills required by a job you might be interviewing for. Luckily, there is a simple way to cultivate this understanding so you can present yourself as capable of doing similar specifications.
Here’s my suggestion.
- Download some “standard” templates. (My Business Analyst Template Toolkit is a good starting place.)
- Go back to your old documentation. Remember what problem you were trying to solve in the first place and the context in which this deliverable fit into the project.
- Rework your documentation using a more standard template. Make sure you leverage the new template to solve that same problem – this might mean consciously removing a specific section or adding a new one. You’ll be working here as a BA would do, not mindlessly copying and pasting information into a template, but making conscious decisions about how to best present information to your stakeholder group.
After completing this exercise, you should be confident that you could create a new deliverable in the standard format if required. You will also have a work sample you can present in a business analyst job interview. If you are not completely confident after going through this process, ask a senior BA to review your work and provide concrete feedback for how to leverage the template and communicate information to your stakeholder audience. And don’t forget to update your resume. Use that BA terminology to describe what you did on that past project. Because, hey, you just proved you could do it.
Build Your Documentation Skills
For help applying the standard structures to make your documentation more formal or, just as important, improving the language you use in specifications so that it’s clear and unambiguous and solves the problem at hand, we do have some courses that can help. Business Process Analysis and Use Cases and Wireframes would be good choices. Each provides templates you can use to structure your documentation, work samples you can review, and include instructor feedback on your deliverables.