Preparing the Requirements Work Plan gives you a chance to take a step back, analyze the scope of work, and determine the best techniques and approach to facilitating the requirements work.
Preparing the Requirements Work Plan gives you a chance to take a step back, analyze the scope of work, and determine the best techniques and approach to facilitating the requirements work.
I love playing games of all kinds, but I particularly like Diner Dash® (and the entire genre of similar games) for a lot of reasons. What I didn’t think about was that the skills I was honing while playing hours of this game actually would benefit me as a Business Analyst.
So, we’ve had the Project Kick Off and now it’s time to start digging in to those requirements, right? Not quite yet. While the Project Kick Off sets the overarching framework of what to expect, the Requirements Kick Off prepares stakeholders for what is happening right now.
Weekly Wrap Up: Building Trusting Relationships, Soft Skill Traits, and Having Varied Experiences
In the previous post of this series, I talked about performing stakeholder analysis and identifying who needs to be involved and when. And for those key stakeholders, the ones you’re going to be working with during most of the requirements, you’ll want to set the foundation right from the Project Kick Off.
Wrap Up of some of my favorite posts from around the web this week.

It doesn’t matter how well you engage your stakeholders if you don’t know who they are. Taking the time to ensure you have all the right stakeholders involved at the right level of participation is what Stakeholder Analysis is all about.
Weekly Wrap Up: Becoming a Better BA, Why Usability Studies Save Money, and What It’s Like in an End User’s Shoes
Do you ever feel like you’re working harder than you have to? Like you’re struggling to get a good rhythm on a project and you can’t figure out why requirements aren’t just flowing from your stakeholders? One key to efficiently moving through the process is finding a way to get and keep project stakeholders engaged so they are not only informed but also on-board with the tasks that lay ahead of you.

You might hear the entire package of deliverables that a business analyst is expected to deliver to be called “requirements”. However, I believe there are two distinct types of information that the business analyst is primarily responsible for delivering: requirements and specifications. And yes, while related, these are very different things.