LESSON 15 UNDERSTANDING REQUIREMENTS,BUSINESS ANALYSIS KNOWLEDGE AREAS

Requirements Elicitation

A key task in business analysis.

Because the requirements serve as the foundation for the solution to the business needs, it is essential that the requirements be complete, clear, correct, and consistent.

Leveraging proven means to elicit requirements will help meet these quality goals.

Elicit

To draw forth or bring out (something latent or potential)

To call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining requirements.

1. Input to Requirements Elicitation

2. Output of Requirements Elicitation

Relationships to Other Knowledge Areas

Input to Requirements Elicitation

The techniques included in this Requirements Elicitation KA can be used to effectively elicit many types of requirements

A variety of means may be used to elicit business requirements and are dependent on the type of study, e.g. Creating a business architecture or identifying a business opportunity.

Enterprise Analysis KA Activities

Define the overall scope of the problem and solution domain and the goals. The business analyst uses the scope definition and goals to provide the boundaries for all requirements elicitation.

Outputs of Requirements Elicitation

Unlike other knowledge areas, requirements analysis and documentation, the requirements elicitation KA does not have a prescribed set of deliverables

It is expected that the business analyst will reach a point during requirements elicitation when he/she feels that sufficient material has been elicited from the business experts to enable analysis and documentation to begin

The combined results of all the elicitation techniques used will serve as input to building the selected analytical models.

Missing, incomplete, or incorrect requirements will ideally be exposed during the analysis activities, thus requiring additional requirements elicitation.

Requirements [Prioritized]

Has an attribute that describes its relative importance to stakeholders and the organization. At the completion of this task, each requirement should have an assigned priority. The priorities may apply to a requirement or to a group or related requirements.

• Non-negotiable demands

• Unrealistic tradeoffs

• Too many stakeholders

• Poor preparation

Challenges in facilitating a requirements prioritization session include:

Non-negotiable demands

Stakeholders attempt to avoid difficult choices, fail to recognize the necessity for making tradeoffs, or desire to rank all requirements as high priority.

Unrealistic tradeoffs

The solution development team may intentionally or unintentionally try to influence the result of the prioritization process by overestimating the difficulty or complexity of implementing certain requirements.

Too many stakeholders

It is not uncommon that many business area resources demand to be in attendance at RP workshops (or even RD workshops). The larger groups can be harder to coordinate and individual agendas may not align with overall business objectives or future state processes.

Poor preparation

The BA may face scheduling, participation, and tool/approach challenges in the RP session without proper preparation of facilities, tools to be used, a focused approach and agenda, pre-organized RP inputs, and clear delineation of ground rules for participants.

• Business case

• Business need

• Requirements

• Requirements Management Plan

• Stakeholder list, roles, and responsibilities

Inputs to RP

Business Case

States the key goals and measures of success for a project or organization, and priorities should be aligned with those goals and objectives.

Business Need

Serves as an alternative to the business case if no business case has been defined.

Requirements

Any requirement may be prioritized, at any point in its lifecycle. Requires that requirements have been stated by stakeholders; however, the requirements may not have been fully analyzed or in their final form.

Requirements Management Plan

Defines the process that will be used to prioritize requirements.

Stakeholder List, Roles, and Responsibilities

The list of stakeholders, annotated with their levels of authority and influence, is used to determine which stakeholders need to participate in prioritization.

• Business Value

• Business or Technical Risk

• Implementation Difficulty

• Likelihood of Success

• Regulatory or Policy Compliance

• Relationship to Other Requirements

• Stakeholder Agreement

• Urgency

BABOK: Basis for Prioritization

Business Value

This approach prioritizes requirements based on cost-benefit analysis of their relative value to the organization.

The most valuable requirements will be targeted for development first.

This approach is common when enhancing an existing solution that already meets specified minimal requirements, or when delivering the solution incrementally.

Business or Technical Risk

This approach selects requirements that present the highest risk of project failure.

Those requirements are investigated and implemented first to ensure that if the project fails, it does so after as little expenditure as possible.

Implementation Difficulty

This approach selects requirements that are easiest to implement.

This approach is often selected during a pilot of a new development process or tools or when rolling out a packaged solution, as it allows the project team to gain familiarity with those things while working on lower-risk requirements.

Likelihood of Success

This approach focuses on the requirements that are likely to produce quick and relatively certain successes.

It is common when a project is controversial and early signs of progress are needed to gain support for the initiative.

Regulatory or Policy Compliance

This approach prioritizes requirements that must be implemented in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests.

Relationship to Other Requirements

A requirement may not be high value in and of itself but may support other high-priority requirements and, as such, may be a candidate for early implementation.

Stakeholder Agreement

This approach requires the stakeholders to reach a consensus on which requirements are most useful or valuable.

Urgency

This approach prioritizes requirements based on time sensitivity.

By the Book (BABOK)

The importance of requirements may be based on their relative value, risk, difficulty of implementation, or other criteria.

These priorities are used to determine which requirements should be targets for further analysis and to determine which requirements should be implemented first.

Karl E. Wiegers

He stated that:

“Left to their own devices, stakeholders will set 85% of the requirements at high priority, 10% at medium, and 5% at low priority. This doesn’t give the project team much to work with.”