Taking a deeper, richer examination at developing requirements is key to further refine and improve the quality of your requirement outcomes and deliver more value to your customers.
In this course, Best Practices for Effective Requirements Gathering, you will learn how to enhance your business analysis skills, approaches, and techniques to advance your essential requirement gathering capabilities and practices.
First, you will delve into a holistic view of requirements, exploring just how your role of gathering, documenting, prioritizing, and communication requirements can make or break a project or even a company. Then, you will discover how the context type of a requirement can influence your approach to success.
Next, you will explore the secret to developing quality requirements through nurturing and cultivating relationships with your colleagues.
Finally, you will learn how business analysts can advance your career regarding requirements activities normally focused on an individual system and take the next step in professional growth with requirements analysis at the business unit level or across an enterprise. When you are finished with this course, you will have the necessary skills and knowledge of how to deliver a higher quality of requirement outcomes in order to add more value for your customers.
Michael is General Manager at Fairway Technologies, a San Diego based technology consulting company. Prior to that, he was Vice President of Development at PDSA, Inc. and has many years of management, technology, and leadership experience.
Course Overview Hello, I'm Michael Kosowski, and welcome to my course, Best Practices for Effective Requirements Gathering. In this course, you will learn how to enhance your business analysis skills, approaches, and techniques to advance your essential requirement gathering capabilities and best practices. As you know, uncertainty is inherent and inevitable in systems development. Let me help you to embrace uncertainty and adapt your analysis skills for success. First, you will delve into a holistic view of requirements exploring just how your role of gathering, documenting, prioritizing, and communicating requirements can make or break a project or even a company. Then you will discover how the business context type of a requirement can influence your approach to success. Next, you will explore the secret to developing quality requirements through nurturing and cultivating relationships with your colleagues by leveraging communication and interpersonal skills. Finally, you will learn how business analysts can advance their careers by embracing the next step in professional growth with requirements analysis at the business unit level and across the entire enterprise. Here we will explore the requirement development process for themes, epics, features, and user stories across three business contexts all through the lens of agile and lean. Come journey with me in taking a deeper, richer examination at developing requirements to further refine and improve the quality of your requirements development outcomes and deliver more value to your customers.
The Value of Requirements In search of the perfect requirement. How much analysis is enough? Well, when you think the requirements are clear, stable, and the users agree. Well that sounds simple enough, doesn't it? Do requirements need to be perfect? No, they don't. But as you've realized, they just need to be clear enough and stable enough, and the users pretty much agree. So we can see that this is not a perfect process, but if you strive for perfect requirements, you will likely never succeed. Life isn't perfect. Are soft and high‑level requirements okay? Well, yes and no. If you have soft and high‑level requirements and they are intended for a report to your manager or stakeholder, then you did a great job. If they are high‑level and soft requirements and you plan to hand those over to a development team to implement, then you likely did not do your job, and that may cost time, money, or even your career. Now conversely, if your requirements outcome is too detailed, then it might be a waste of time for two reasons. One, because requirements are a moving target and they can rapidly change, and therefore, be a waste of your time. And two, if you're only going to provide decision data to your manager or stakeholder, why go into so much detail? In this case, a soft and high‑level outcome maybe would be just fine. So what is the right amount? Well, there is no clear answer for this, but I will try and take a stab at it on the next slide. Here is my guidance for the right amount of analysis. It is basic and straightforward, and should help you if you struggle in this area. You are not alone. I have certainly struggled in my career on this topic. So this is what I would do. Always know your outcome before you start. Whomever is giving you the assignment, be sure you understand what is expected of you and your team. Ask questions, and get a good holistic feel on what they need. Document their expectations, and send it back to the person, not for approval per se, but for affirmation. Okay, now you have a firm assignment and you're ready to start. I can't believe how many people work on assignments, not really knowing their assignment. How productive is that? Not very. Perform all analysis in increments and iterations, just like I've described in this module. Remember, doing work in short increments with regular reviews enables us to make course correction. Life is dynamic. Things change. List your backlog of tasks, just simply jot down a list of tasks you need to do, and if you have your framework, pull out a template, lay out your iterations, maybe three days if you're by yourself, or 1‑2 weeks, or whatever works for you. Provide incremental feedback during standups, you will be amazed that incremental feedback to your stakeholder has so many benefits.