If post-project lessons learned repeatedly indicate that poor requirements are a cause for failing projects, then just fixing your business analysts isn’t enough. Quality business requirements and successful software projects are not the sole responsibility of the business analyst role; rather, quality requirements are the result of collaboration from multiple stakeholders. As a total-solution oriented approach, Requirements Quest developed role-based training to roll-out and support the implementation and execution of a requirements management process.
Quality requirements are the result of collaboration from four categories of stakeholders as shown in Figure A: producer, supplier, receiver, and supporter.
| Requirements Producer |
Requirements Supplier |
| Requirements Supporter |
Requirements Receiver |
Figure A – Requirements Management Roles
A requirements producer, commonly referred to as a business analyst, is an individual who elicits, analyzes, represents, and validates requirements for desired changes made to business policies, business processes, and supporting systems. The requirements producer is a liaison between the business area with a business need and the solution delivery team.
A requirements supplier is any individual with responsibility for defining the business needs. Some individuals provide the strategy and direction of the system, while others provide details that define the necessary system functions.
A requirements receiver is any individual who uses the specified business requirements to implement a feasible solution. A requirements receiver might be an individual who is responsible for designing and developing the solution, testing the requirements, training users, writing user procedure manuals, or managing the project.
Last, but certainly not least, a requirements supporter is any individual responsible for supporting the requirements management process and project effort. Supporters may be involved in looking at both the completed requirements specifications and the requirements processes that are followed to assess their effectiveness and offer suggestions for improvement on future projects.
Requirements Quest’s unique role-based training can help you not only implement better practices, but can help you to sustain those practices. While training “just in time” is often an excellent approach, we believe that “just enough” for all involved roles helps the team attain a consistent interpretation of the requirements and consequently deliver better systems.
Role-Based Requirements and Business Analysis Training
If post-project lessons learned repeatedly indicate that poor requirements are a cause for failing projects, then just fixing your business analysts isn’t enough. Quality business requirements and successful software projects are not the sole responsibility of the business analyst role; rather, quality requirements are the result of collaboration from multiple stakeholders. As a total-solution oriented approach, Requirements Quest developed role-based training to roll-out and support the implementation and execution of a requirements management process.
Quality requirements are the result of collaboration from four categories of stakeholders as shown in Figure A: producer, supplier, receiver, and supporter.
Figure A – Requirements Management Roles
A requirements producer, commonly referred to as a business analyst, is an individual who elicits, analyzes, represents, and validates requirements for desired changes made to business policies, business processes, and supporting systems. The requirements producer is a liaison between the business area with a business need and the solution delivery team.
A requirements supplier is any individual with responsibility for defining the business needs. Some individuals provide the strategy and direction of the system, while others provide details that define the necessary system functions.
A requirements receiver is any individual who uses the specified business requirements to implement a feasible solution. A requirements receiver might be an individual who is responsible for designing and developing the solution, testing the requirements, training users, writing user procedure manuals, or managing the project.
Last, but certainly not least, a requirements supporter is any individual responsible for supporting the requirements management process and project effort. Supporters may be involved in looking at both the completed requirements specifications and the requirements processes that are followed to assess their effectiveness and offer suggestions for improvement on future projects.
Requirements Quest’s unique role-based training can help you not only implement better practices, but can help you to sustain those practices. While training “just in time” is often an excellent approach, we believe that “just enough” for all involved roles helps the team attain a consistent interpretation of the requirements and consequently deliver better systems.