Managing requirements is critical for the success of any project and custom master data solution deployment is no exception in this regard. Very often, deployment of master data is kind of transformation project for client as they are moving for traditional / manual way of master data creation to process driven master data management. In above context, managing requirements and expectations becomes key criteria for solution delivery and meeting transformation objectives.The typical landscape of these solutions comprises of Portal as front end, Guided Procedure for workflows, and ECC system for data validations, MDM for storing master data and SAP PI for distributing data to SAP ECC systems. The complete requirements for such solutions come from different sources in the organization and therefore pose challenges in gathering and finalizing the same. With this blog, I would like to discuss information required to kick-start development of such solutions and importance of each these types of requirement for the success of the project. I will appreciate if others can share their project experiences in the comments section and enrich the blog. The requirements for such solutions can be categorized as given below:
Process Requirements: Defining master data processes in optimal way is critical for the success of project. These requirements are driven by process experts from the customer. These processes capture business process flow and provide information about high level behavior of application and workflow. For example, master data creation process talks about creation of master data in the system through certain steps such as user selecting the option to create -> entering the master data in the form -> on submission deciding the approver --> on approve saving the data (or on reject stopping the creation process) in the MDM and syndicating it to ECC via SAP PI. These processes not only help in understanding the application but also help in designing the application flow. The work flow design and developments are entirely dependent on these processes. From my experience, it is very much required that these processes are discussed, documented and signed off during the requirement gathering phase of the project. The impact of changing the process in later phases of the project could be very expensive and could deliver a blow to the agreed delivery timelines.
Data Model Requirements: Data model requirements are driven by current usage in the downstream systems by the customer. Firming up data model is very crucial in the beginning of project. Any changes in the data model design could lead to re-work of the solution. Project team should spend quality time in finalizing the data model early in the project. Your data model design should encompass everything related to data such as MDM table design, Field lengths in Portal User Interface, Mandatory/Optional fields,Data sources for look ups, data mapping between MDM and downstream systems.
Functional Requirements: These requirements depict end user interactions with the solution. Functional requirements are driven by partly by process requirements and partly by functionalities required by end users. Each of these interactions requires specific development both from user interface & logic perspective and consume major portion of effort in the build phase of the project. Search capabilities such as Text search & Duplicate Search, Saving / edit / display of Master Data and Approval of master data etc could be examples of functional requirements.
Data Validation Requirements: Data quality is one of the important reasons for Master Data based projects. Data validation source needs to be defined for each validation. If the source is SAP ECC system, you may require custom function modules for carrying out validations. If it is MDM, you will need to design / develop MDM based validation which application needs to handle.
User Interface Requirements: End user experience is also important factor for overall solution to be accepted. Project team should aim to create mock up user interfaces and share it with end user community for feedback. To be very effective, it should be consistent and similar across different process steps in the look and feel and functional behavior. Changes in the user interface part may not as expensive as process / data model / functional changes if they are only related to placement of tabs/ field groups / buttons. If the changes are linked to application behavior, then it might pose a risk to implement them in later phases of the project.
All in all, the project team should aim / strive for firming up the requirements early in the project to minimize the risk on the project. However, as the project phase progresses, changes do come. There are no straightforward tips and tricks to handle these changes. Each change should be evaluated for criteria such as importance of these changes / impact on time lines / impact on solution design and should be acted upon accordingly. Normally change management post deployment of solutions is defined process in any company but during the project phase it is handled in ad hoc manner depending on the criticality of the change. It will be good practice to define change management process post requirement sign off in the project. Another suggestion will be have regular deep dive sessions in the beginning of the project with client on all above mentioned requirements to eliminate any surprises in the project.Few more recommendations around managing requirement document are:
- Do not create very large one document as FRS. If needed, you divide the document as per specific target audience. You can also use master document concept where you can prepare one master FRS document referring to other documents as links. This way document will be manageable and changes can be tracked effectively.
- Attaching a document within one document is strict no-no. You lose track of changes.
- If possible, create a repository of all functional requirements at atomic level. This will help you in building test cases of the solution.
- Do not repeat same information in different sections of the document. If you are repeating a requirement in the same document across different section, you run into risk when there is a change in that particular requirement. You may change it at one place and leave others as it is, making the document inconsistent. Please use references within the document if there is need to repeat the information.
