As a Business Analyst in software development and working as an outsourced contractor for clients in many global locations, experience has been the key to nail down extensive sets of requirements while juggling the dynamics of project management — namely agile methodologies.
To start, I want to point out that the breadth of what a Business Analyst has to do with requirements in a software project is huge and varies per project to say the least. Nonetheless, I want to give a general overview on the overall requirements definition process.
For me, this always is the most difficult part as it seems like a huge undertaking to get know what the business intention is behind product development. For that reason, I always start sussing out team dynamics and get a high level overview from stakeholders on what the product is all about. Nonetheless, there are two considerations:
1 — For existing projects: In what phase is the team developing? Where does my role on requirements definition fit in? Can implemented features be improved in any way? How will new requirements affect existing ones? In this case, you need to have clear boundaries on what needs to be defined and for when. Stakeholders should have a product roadmap of upcoming features and usually it’s not so important to consider technical requirements if they have already been implemented and are working as expected.
2 — For new projects: Is this a new start up project and I’m involved from the get go? Do stakeholders have a clear idea on their business flows and processes or do they need a proposal of solutions before defining requirements? Oftentimes, requirement discovery sessions are necessary in conjunction with a design team to weed out initial “draft” requirements.
In both cases it’s essential to know: How will stakeholders communicate their initial ideas or set of requirements? and who approves the final set of written up requirements before they are to be worked on? The boundary can get blurred here and result in a scramble to define the most urgent features without attaining proper sign off — this is why it’s good to establish before starting a project ,who, how and when requirements will be approved. Agile projects should flexibly accommodate to these needs and last minute changes. Nonetheless, having an agile mindset is important since you may start defining features, that later need to be put on the back burner.
Communication is tricky…
Here comes the soft skills part and trust me—it’s actually really hard to take ideas from a business team, try to envision a solution as per their expectations plus document it in a way that makes absolute lucid sense to all! Requirement specification part of product development is a granular task. However, key to being in a role that is in between business and the dev. team is to fully understand the business logic and needs, make sure it’s crystal clear between all parties, and yeah… communicate as needed.
On the battleground, it’s common that ideas are trickled down from management stakeholders you don’t have direct contact with. If I don’t have the experience or knowledge from a business perspective, I always ally myself with a strong business profile. It does take time to work in sync and get exactly what you need. I can’t count the times where I’ve asked a specific question and the answer comes back as something not related to my question. For that reason, once I get the know-how on a product, I like to have a quick sync up meeting to outline where everything fits in in general. Paint the broader picture you might say, address terminology so everyone is speaking the same language! As futile this may seem, it is extremely important since stakeholders will speak to you as if you know everything about the product and solution.
Requirements back and forth…
Now, writing requirements is a process in itself. Regardless of the project methodology, documentation is key. The how might change whether it’s scrum, waterfall or DevOps, but having someone to clearly document requirements can keep them organized is particularly useful for long term complex apps.
Key ways you can make finalizing requirements easier:
- Accept that back and forth between stakeholders and technical teams is inevitable, be open to last minute changes and adapt.
- Align with the Project Manager, Scrum Master or Product Owner on timing for features. Don’t invest time if something’s been moved to another phase in the project.
- Have a big picture understanding but also focus on immediate definition for the closest upcoming feature releases.
- Clearly index your requirements, keep them organized and updated — make sure that any changes are clearly labeled as something that’s changed from an already approved requirement.
- Don’t lose sight if you get into too technical discussions, the how something can be implemented can be discussed later on. The what it does should be the immediate focus.
- Simplify —this is my motto. Yes, complex requirements intertwine and overlap but always bring it back to a basic function then link alternative flows and exceptions around it.
What you gain with experience…
As a final note, I want to express that with time and tapping into a bit of intuition on how projects function and what the product is, you can foresee a best way on how to gather requirements and how to organize them. I always suggest to think from a “standing the test of time” viewpoint — how can a certain documented feature be found easily in two years time? Can QA easily find the initial requirement related to a specific bug? When defining, are there technical considerations to look out for? Without getting into the ins and outs of industry best practices, there are general trends for web applications and platforms. Leveraging these often help to organize product requirements in a clear way.
So next time when you have to grapple a project — just think — feature traceability is key and work from the big picture down. Goodluck!