2. Requirements not scrubbed

Symptoms: Organizations in particular within the federal government draft hundreds or thousands of requirements that are often phrased as “the system shall…”. Instead of focusing on what the requirement should do the requirements should focus on what the system will do.  

Frequently government organizations implementing ERP solutions draft requirements ahead of making a decision to acquire an ERP system and thus the requirements are incongruent with the capabilities of an ERP system.   

These government organizations implementing an ERP solution document requirements that are often maintained in web of spreadsheets that makes it difficult to: 1. Track a requirement, 2. Modify the requirement while communicating the changes to the affected parties, 3. assigning requirement ownership, 4. Create an RTM (requirements traceability matrix), and 5. Manage the lifecycle of the requirement. 

The ERP implementation partner is tasked with interpreting the requirements from spreadsheets and discerning how these requirements will be implemented during realization and verifying that the requirements have been met during testing. The ERP implementation partner for the sake of meeting deadlines rushes through the blueprint phase does not scrub the requirement and blindly attempts to implement the requirement even when the requirement is not feasible, necessary or consistent with the functionality of the ERP application.  

After testing is finalized and the ERP system is deployed much debate ensues as to the functionality of the ERP system because it fails to meet the requirements and the end users lose confidence on the deployed ERP application.  

Suggestions: For companies undergoing requirements based testing obtain a requirements management tool such as requisite pro or caliber-rm. Scrub all requirements, ensure thorough understanding of the requirement and evaluate the requirement based on these attributes: feasibility, necessity, consistency, completeness, priority, correctness, traceability, and unambiguousness.  

Illustrate understanding of the requirement with flow process diagrams and through peer review sessions. Requirements that cannot be implemented or not feasible should be waived or listed as exceptions. Requirements that fall out of scope need to be communicated to the design and functional team and evaluated for impact.  

It is unlikely that your requirements will ever reach a “perfect” state since that could trigger a paralysis for your project but requirements need to be clearly defined and understood to allow your team to proceed with an acceptable level of risk. Once an acceptable level of risk is established the functional team can proceed to configure the system and the technical team can develop custom programs.  

Requirements need to be drafted for all areas of the SAP implementation and not just surrounding functionality. Requirements categories include: security, workflow, reports, interfaces, forms, performance, archiving, usability (section 508), etc. Define all stakeholders for the requirements and assign ownership for the requirements for each area. For requirements that are automatically met from the out-of-the-box ERP solution and do not need test cases they need to be clearly demonstrated and presented to the client. Merely presenting how the ERP system meets the requirement out of the box is not sufficient and waivers should be signed off to indicate that the client accepts these requirements as being met “as is”.  

Draft an RTM (Requirements Traceability Matrix) that ensures that all requirements get coverage and get mapped to a test case. No requirement should be left orphan.