Corporate Education Group

The Quest for Good Requirements

CEG offers Corporate Training and Consulting, as well as traditional and virtual instructor-led courses in management and leadership, project management, business analysis, business process management, agile/scrum, and lean six sigma.

Issue link: https://info.corpedgroup.com/i/1209615

Contents of this Issue

Navigation

Page 4 of 8

The Quest for Good Requirements | 5 300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com Stakeholder Obligations For an IT project to be successful, the stakeholders have certain responsibilities: • Spend the time with the analyst and educate them about their business and help them understand their objectives • Allocate the time necessary to provide clear requirements and validate the requirements in a timely fashion. • Precisely describe their requirement; vaguely stated requirements are not implementable and documenting them is a waste of time. • Provide feedback when needed. • Provide additional information in a timely fashion. • Prioritize the requirements. • Respect the estimates for time and budget provided by the project team and resist the urge to "negotiate." • Inform the project team of changes to requirements as soon as they occur. The analyst must continually remind (in subtle ways, of course) the stakeholders of their responsibilities. If the stakeholders don't live up to them, then that introduces project risks which must be made known to the projects manager and included in the project's risk catalog. Requirements Elicitation and Discovery To discover requirements, the analyst applies a variety of techniques. The steps in requirements elicitation are generally as follows: • Plan the requirements elicitation process and how the team will document and validate the requirements. This plan is referred to as the requirements management plan (RMP) and is considered a key document for project planning. • Write a project charter or project mission statement containing the business requirements and the overall scope of the project. Often, a context diagram is provided to clarify the scope of the system development effort. All stakeholders must agree to the vision for the project. Some organizations refer to this document as the business requirements document (BRD). Use brainstorming and interviewing to arrive at the key business requirements. • Identify the key users and their usage characteristics and select a proxy for each user that can present the requirements for that class of users. These "user representatives" will be consulted throughout the requirements elicitation effort. • Collaborate with the user representatives to identify use cases and then analyze those use cases to derive the detailed functional requirements for the product. • Analyze any events to which the system must respond, such as input from hardware devices or messages from other systems. • Identify any other stakeholders who might provide requirements or constraints. • Convene requirements workshops in which users work together for a few days to explore user needs and to agree on the requirements. Requirements workshops are a way to reduce the amount of time it takes to find all the requirements by getting everyone together at the same time. Joint Requirements Planning (JRP) and Joint Application Development (JAD) are examples

Articles in this issue

Links on this page

view archives of Corporate Education Group - The Quest for Good Requirements