Best Practices for Requirements Gathering
This is a continuation of the SAP BW Best Practice Series on SAP Project Management. In this article I review the key requirements gathering practices I recommend SAP project team members follow and maintain throughout the life of any SAP project.
If you are in the middle of development for your next Go-Live or doing an upgrade of an existing SAP BW or Business Objects dashboard system or working on any type of greenfield, brownfield or ongoing project, I recommend you try these requirements gathering methods because I have and I found them to actually work in the field.
Even if you are not following these requirements gathering techniques currently or when you join a project, implementing them soon after you join will make you look smart as well as help you turn around and regain control of any failing project.
In this Article, I discuss requirements gathering practices and how important that is to your project success.
What comes after the stakeholder management plan?
In the Stakeholder Management Plan, you identified and categorized stakeholders using the Stakeholder List and an Affinity Map.
The next step of the project management process is to capture stakeholder requirements by holding a Kick-off meeting with the stakeholders and then conducting follow up one-on-one interviews to further capture, refine and clarify each requirement.
Pen and Paper Mockup of an Initial End User Requirement
To clarify each requirement, in SAP Project Management you will interview the stakeholders multiple times across the project timeline.
Hold Stakeholders Hand Through the Process
Keep in mind interviewing stakeholders is one of many project management tools you and your team members have used hundreds if not thousands of times already; however, for each particular stakeholder, this may be their very first time to submit a requirement on an IT project so you may have to educate them as you go along.
User Requirements Gathering Template
You will capture their “vision” through notes, various user requirements gathering templates, such as SAP BI requirements template, hand drawings, mockups, simulations and any other suitable project management method that works.
The interview process will continue, and this may spread over several days or even a few weeks per requirement.
This continues until you can sit with the end user and fully simulate the final functionality of each requirement.
You should continue until you know how the final product is going to look and how it is going to function and why.
You must also answer all the developer’s questions during the requirements capturing process. This implies that in addition to meeting with the End-User you will also be consulting in parallel with the software developers who will also have questions for the End-User that perhaps you have overlooked or omitted.
SAP BI Technical Specification Document
Once fully documented, the requirement is ready for “submission” of the SAP BI Technical Specification Document to the Project Folder.
Use a Requirements Traceability Matrix
You should also log each requirement into the requirements traceability matrix, commonly referred to as the “tracking sheet”.
Give each individual requirement its own tracking number starting at number 1 and working up from there.
All requirements are managed following the methods outlined in the Scope Management Plan.
What are the inputs requirements elicitation?
Two of the main inputs needed for gathering requirements are the Project Charter and the Stakeholder Register List.
The project charter outlines the high level purpose known as the initial scope.
The stakeholder register list should identify all the people influenced by the project and everyone who is affected by or who can have an impact on the project.
What are the outputs of the requirements gathering process?
The major outputs of the Requirements Gathering Process are:
- Detailed Requirements Documentation
- Requirements Management Plan
- Requirements Traceability Matrix
Gathering requirements requires a certain consulting skill set.
To be most effective, you need to be a dual career path person who is not only an SAP BW developer, but also a business person who can understand the customer business processes and their business needs (ie. an MBA).The outputs of requirements gathering also are direct inputs into WBS time duration estimation, cost estimating, budgeting, scheduling timeline, overall project cost and answering the following questions:
- How long will this project take
- What will it cost and
- How many people does the project development need.
What is Requirements gathering?
Projects exist to meet stakeholder needs.
The project charter again outlines the overall need.
Collecting Requirements is the back and forth process of defining and documenting the detailed stakeholder needs to meet project objectives.
Gathering requirements is not an overnight task and is also a never ending ongoing process where new requirements are dreamed up, captured, submitted, evaluated, accepted or rejected, implemented, tested, fixed and released to the customer.
Who are you capturing requirements for?
End user requirements are captured to satisfy end user product needs.
When you capture requirements you are capturing an end-user need definition that is in sufficient detail to communicate to the software developer a complete description of the desired end user product (the Requirements) so that the software developer has all the information needed to go off and create that product on the system.
When you capture requirements, you are really capturing requirements for the software developer benefit not the end-user benefit.
The final product created is for the end-user benefit not the software developer benefit.
The end user already knows what they need but the software developer does not.
The software developer needs to know what product requirements the end user has in mind so that the developer can go away and create that final product for the end user.
Ultimately, all the work and effort involved in requirements gathering process is for the end user’s benefit.
How detailed should a requirement specification be?
Document requirements in such detail, using whatever methods work best for the project, such that the software developer will be capable of implementing the report or dashboard based only on your written documentation.
That’s how detailed it needs to be.
Final End-User Prototype Drawing
There are several tools and techniques you can use to gather customer requirements. Two of the most powerful tools you can use are: Pencil and Paper, and One-on-One interviews.
Business Requirement Analysis Tools and Techniques
Some other requirements elicitation techniques you can use to help you gather project requirements are:
- Delphi Technique
- Mind Mapping
- Fishbone Diagramming
- Affinity Mapping
- Conduct one-on-one interviews with the stakeholders
- Forming focus groups
- Using facilitated workshops
- Using some group creativity and decision making techniques
- Sending out questionnaires and surveys
- Personal observations
- Building prototypes
In Brainstorming, it is important to remember there are no right or wrong answers.
Don’t criticize other’s ideas.
The important thing is to get all ideas out there. The evaluation process can take place later on by the project manager, stakeholders and through voting also known as “Nominal Group Technique”.
Delphi Technique is a useful requirements gathering technique since it is an anonymous method.
In the Delphi Technique, a group of experts are asked for their opinions anonymously either through a survey or other question answer method.
The identities of the Experts are kept secret.
The important point is that the experts can provide their experience based opinions and feedback without worry about repercussion or blowback and it is hoped the experts are more honest and open with their responses.
This removes most biases and is a useful technique to evaluate ideas or to solicit feedback and ideas.
Drawing a Mindmap is a useful tool for uncovering relationships within systems.
These relationships become topics for further discussion to uncover new and unexpected requirements.
Drawing a Fishbone Diagram is a useful tool you can use to group related sequential topics for further analysis or discussion.
Fishbone diagrams are a useful little memory tool I often use to summarize long complex sequential processes or longwinded wordy technical descriptions of processes onto a single sheet of paper in graphical form.
I have probably extended the fishbone diagramming technique far beyond its original intention.
An Affinity Map is a useful tool you can use to categorize, group and rank order a large number of items into different quadrants on an Affinity Map.
Business Requirements Questionnaire
A questionnaire is a simple tool you can use to ask initial questions and collect responses from a wide audience. Data warehouse requirements gathering questions tend to work best when they align with the major SAP functional modules.
Questionnaires exist for specific functional areas, such as business intelligence KPI design requirements questionnaires, SAP FICO requirement gathering questionnaires, SAP CRM requirements gathering questionnaire or SAP MM requirement gathering questionnaires. Our CRM requirements gathering template helps to streamline requirements gathering, as do all of the rest of the specialized requirement templates we have develop and thus offer tremendous value to our clients.
Business Intelligence Requirements Gathering Template
We have developed proprietary business requirements questionnaires for every area of a typical business - and map them to typical SAP supported processes. There's a lot of valuable Intellectual Property contained within these which we use to help clients get to their solution quicker.
Prototypes and Mockups
Building Prototypes or Mockups are two of our field tested recommended best practices for gathering stakeholder requirements.
Building prototypes is a useful technique that works on several different levels.
Feedback on each prototype is solicited from the end user.
End users get to work with a simulation of the final product and they get to give feedback on what they like or don’t like about the prototype.
This is a particularly effective method for clarifying and finalizing requirements because many times when dealing with new technology, the stakeholder is not familiar with the technology and does not know what to expect.
By building mockups and prototypes that simulates how the final product will look and feel, showing these to the stakeholder, getting their feedback and then going back and revising the prototype, and repeating this process to the point the stakeholder does not ask for any further changes, this is an excellent way to clarify and nail down the final stakeholder requirements.
A mockup is also a good input to the testing phase. Using pen and paper to build prototypes at an end user’s desk is orders of magnitude cheaper to do than it is to build prototypes on a live system.
What is project success?
Project success is all based on customer satisfaction. Customer satisfaction is all based on whether or not you have met all stakeholder project needs, deliverables, quality levels, and expectations at the end of the project. Only when you have met all of the agreed upon requirements (the project scope), will the project finish with a happy and satisfied customer.
Project Requirements are a Major input to the Project Scope Management Plan which is the topic of the next article.
Just Remember: “Better Planning, Better Results”. We've boiled all these tools and techniques down into our Top 5 Software Requirements Gathering Best Practice Checklist. Get your copy by clicking the button.
People Who This Also Read:
What Is Shopify & How Do You Use It to Boost Your Business?
1 Key Tip When Upgrading from SAP BW 3.X to BW 7.X [Checklist]
10 Advanced SAP BW Project Estimation Techniques [Online Tool]
3 Ways to Design KPIs Using SAP Solution Map Composer
Top 10 Benefits for Financial Analysis in the Latest SAP EP4
Learn What Tools To Use To Investigate IS-Mill Functionality
BusinessObjects Explorer Best Practices