Discovering a list of requirements and then not linking them to design, construction and testing often results in the delivery of a system that may not fully support the business process which it was intended to automate. Only through traceability can the project team ensure that all requirements are implemented. Traceability assures the business stakeholders that the developed system supports their original requirements.
Client Story: A Large Financial Institution
A large financial institution recognized that their IT projects were consistently not meeting the expectations of the project stakeholders. Delivery of systems with missing or incorrect business requirements resulted in modification of business process or expensive workarounds so that the system could be used. Consequently, many costly change requests were generated, often to implement requirements which were identified during the requirements phase of the project lifecycle.
|
Lessons Learned
|
Recipe for Success
In order to determine the root cause of the requirements deficiencies, IAG conducted a Requirements Management Maturity Assessment (RMMATM). The RMMA is used for the identification and improvement of an organization's business analysis, requirements definition and requirements management capabilities. The assessment evaluates not only organizational capabilities with respect to process, but also staff competency, practices and techniques, tools employed, organizational infrastructure and support, deliverables, and results which are currently being achieved.
IAG conducted a series of structured interviews with stakeholder groups including Business Analysts, Project Managers and key members from Lines of Business and IT. Additionally, IAG administered an assessment survey and a Business Analyst competency test to measure perceived and actual skill levels of the staff responsible for requirements management. Several common themes arose while conducting interviews with stakeholder groups, one of which was the lack of traceability after the requirements had been discovered. A number of key stakeholders went so far as to voice their skepticism about the success of any new requirements methodology since past projects had been implemented without incorporating all requirements discovered under previously-used practices. It was determined that the root cause of these past failures was that once business requirements were documented and handed over to the design and construction teams, they were not referenced going forward. In fact, test cases usually tested the design rather than the business requirements; if requirements did not make it into the design, testing would not catch the problem.
|
"For the first time, this approach provides us with a flexible and adaptable approach that takes us from our clients' true business requirements seamlessly through software design. We also generate our test cases right at the start and ensure traceability through our SDLC." J.S., AVP Individual Systems |
Advice for Project Managers
When managing your project's requirements consider what was needed in this client's case: a better process to create functional requirements for each business component to be automated, as well as, the ability to trace those requirements through design, construction and testing to ensure each business requirement is satisfied as intended.
The client's expectations are that the system performs functions to support their business process, as documented in their business requirements. Therefore, you have to reflect your client's business process in the functional requirements. Ultimately, you must deliver a system which allows the business to function in its desired state. You can achieve this by creating a functional requirement for each business component to be automated - but - don't forget to trace each requirement through the development lifecycle. Both are needed to ensure the system meets stakeholder expectations.
Duncan McDonald is a Senior Consultant at IAG Consulting (http://www.iag.biz/) with over 20 years of experience in bringing practical advice to clients across many industries. Duncan has completed dozens of large-scale requirements projects with IAG's clients as a lead requirements facilitator and requirements architect. As a requirements trainer and best practices advisor, Duncan has also supported a variety of large clients in becoming more efficient in requirements discovery and management practices. Duncan is a sought-after consultant, who brings pragmatic solutions to clients that want dramatic performance gains.

Click Here to login or create a free account.





Not ALL the requirements that get documented are actually business requirements. Some requirements just spring up from existing process/already existing hardware and limitations and ways of working of systems. e.g. what standards/processes to follow for file transfer from one system to another-on this no actual 'business' need to formulate a business requirement. In such cases the tarceability is actual to a person making a decision or an already set document being referred.
May be the above point is generally known and accepted but still wanted to put up my views.