There is no single requirements gathering technique which is the best. You have to know your stakeholders and the context of the project to pick an approach which will work well.
The key is that the control objectives governing the requirements should be met regardless of the approach taken to elicit, analyze and document them. These include criteria such as traceability and ensuring the right stakeholders have reviewed and accepted them.
When i'm gathering requirements, I tend to use workshops with the team/key stakeholders to gather the list of requirements. I also use the project artifacts available to me at that time.
What are you looking for? a speedier way to gather requirements? Knowing where to look for them? Saving Changes...
Eric IsomOwner| learn.pmguaranteed.comUt, United States
For gathering requirements, look into brainstorming sessions, the nominal group technique, focus groups, interviews, surveys, the Delphi technique, mind maps, workshops.
Decide which key stakeholders to involve. You should probably start with a small group to gather most of the requirements, and then talk to some others to identify and fill in any gaps.
Choose the techniques that best meet the preferences of your stakeholders.
Organizing requirements is another subject, but however you do it, make sure that you can communicate them effectively to the stakeholders, and that you have traceability (e.g., requirements traceability matrix). Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Something that is critical to understand: you will not gather requirements. You will elicit needs/wants/desires/etc that you will translate into requirements or well formed requirements. The second is: business analyst is accountable for product/service/result requirments while PM is accountable for project requirements. From the first ones you define the second ones. About the ways, my recommendation is take a closer look to PMI´s Practice guide for business analysis. Saving Changes...
Kimberly McCoyProject Manager| TekSystems - ContractorZanesville, Oh, United States
I like pulling the entire team together and discussion in a somewhat brainstorming session, but I have the environment that most teams work together extremely well. Not only does this help to ensure all the teams understand the requirements/goals for each department, but it also helps for them to hear of any constraints they might need to account for, and allows for clear understanding of the overall project goal, with little miscommunication. Saving Changes...
Gabrielle StoryProject Manager| AXA EquitableFabius, Ny, United States
Honestly, I got to the lowest man on the totem pole. When you talk to the Do-ers, you learn how things actually work and improvements than can be made. You don't want to base your requirements on current policy or process, you want to base it off whats actually happening. I always prefer to use the PRINCE2 technique of getting Senior Users on the team, people who represent the users/customers that can speak to the painpoints of the current system.
...
1 reply by Vincent Guerard
Jul 29, 2019 4:57 PM
Vincent Guerard
...
That is also the way I believe the IT system can be improved.
Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Define "requirement" very clearly. Is something "required" because it defines project success? Is it "required" because an external stakeholder or group mandates it (i.e. a regulatory agency)? Or is it "required" because the good idea fairy left it under a director's pillow?
Ask "why" often and repeatedly. It may turn out that some "requirements" are really just wishes. Some requirements may appear to address the problems your project attempts to solve, but they're really only attacking the symptoms rather than the root causes. Saving Changes...
There are many different types of requirements such as customer requirements, regulatory requirements, business requirements, and product requirements. Different teams may be focused on different types of requirements, using different approaches.
Requirements are often broken out into a tree or hierarchy and those categories can be your tier 1 branch of the tree. From there you can build a plan for how to address each branch individually, and how to integrate them as well. The integration is important because of "derived requirements", such as providing a function required by the customer, may involve regulatory or product requirements necessary to perform the function safely or effectively. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
I find telling a story is the best way to convey requirements. Alternatively, Gherkin can help you structure requirements as scenarios. Saving Changes...
There are so many methods and techniques are available to collect the requirements but you have to decide which one is the best suits for your project.
Also a lot of different stuff available on project management.com and lot many templates are available on this site for further reference. Saving Changes...
Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music
and Music is THE BEST
