In this blog, we would try to put up some points to work as guide lines that help in requirement gathering. This is based upon our experience in few implementation projects at customer site, in retail banking scenario.
In SDLC model the first stage is requirement gathering. Normally there are 2 scenarios:
- Customer is completely ready with the requirements and wants the automated solution to be implemented.
- Customer needs to define the requirements first and then wants the automation to be done.
In the first scenario there is little problem as the requirements just need to be made clear to the developer team to atomize it.
Second scenario is where most of the IT teams land up in project plan slippages. Teams normally take up the tasks of project without really addressing the requirement definition and scoping. A draft requirement without scope limiting and future plan analysis leads to ad-hoc development.
The requirement phase can be divided into multiple sub-phases as below:
- Requirement gathering
- Requirement definition
- Requirement estimation
- Requirement scoping
- Requirement staging
Each of which addresses different scenarios, operations, analytics and outputs. Here I mention about the requirement gathering part.
1. Requirement gathering:
In theory, solution architects are supposed to work in these activities and come out with final solution. Most of the time it is not possible for the solution designer to interact with the end user for proposed solution. In case of split teams where the teams are formed out of mixed skillet and there is no specific requirement gathering and/or solution scoping team responsible identified; some new techniques can be implemented as below.
- Different people in team can talk to multiple stake holders associated with project like board of directors, line managers, end users for the application, functional managers, administrative people and technical teams from dependent departments and collect their inputs and develop respective perspectives. The team members can then come together and put all these perspectives together. This will certainly help in listing requirements that the final software-solution needs to address. In the first stage the functional draft can be made and then technical draft can be proposed which is specific work of the team. This exercise will certainly help in scoping requirements at very primary level of the project planning.
- A single person can observe and understand the actual business process and after analyzing, propose a complete working solution for the given department. The suggestion can be a new process sequence, with restructuring / redistribution of the functionalities and operations. These proposed solutions would then be compared with the efforts and feasibility estimation.
In case you need assistance on SAP project management and best practices, please contact us. Please send us your questions, comments or assistance requests, and our team would be glad to assist you.
Please send us your questions, comments or assistance, and our team would be glad to assist you.
By Sareeka Bangar¬†(on behalf of SAP Consulting Team)
SAP :: Streamlined
We¬†offer¬†variety¬†of¬†services¬†including¬†SAP¬†ECC¬†,SAP¬†HR,SAP¬†BW,SAP¬†CRM,¬†SAP¬†SCM,SAP¬†BPM, Business¬†Objects,¬†SAP¬†ABAP¬†Development,¬†SAP¬†BASIS¬†and¬†SAP¬†NetWeaver¬†consulting.¬†We¬†have expertise¬†in¬†providing¬†implementation,development,¬†SAP¬†Migration¬†and¬†SAP¬†support¬†services¬†to SAP¬†customers¬†across¬†diverse¬†industries¬†at¬†a¬†global¬†level.
Have a question on SAP? Write to our SAP Architect.
(We promise a no-obligation consulting reply)