To turn the tide and enable more successful projects and business outcomes, this study finds that organizations must focus much more attention on three critical areas that can greatly improve the effectiveness of their requirements management capabilities: people, processes and culture.

I. People — organizations must put the necessary resources in place to properly apply requirements management for recommending solutions for projects and programs. At the same time, they must also recognize and develop the skills needed to perform these functions.
II. Processes — organizations must standardize and formalize their processes at the project and program levels, to ensure they are consistently applying good requirements management practices for all their initiatives.
III. Culture — organizations must create a sense of urgency at the top, so that executive management and sponsors fully value the practice as a critical competency of projects and programs, and provide the appropriate support and commitment needed to excel throughout the organization.

Source: PMI’s Pulse of the Profession In-Depth Report on Requirements Management

The most important skills for requirements management:

I. Active listening,
II. Interpreting and clearly articulating requirements,
III. And aligning requirements to the strategic vision for the project

Source: PMI’s Pulse of the Profession In-Depth Report on Requirements Management

Interrelationship diagrams is the special type of cause-and-effect diagram and helpful for visualizing complex problems that’s had seemingly unwieldy relationships among multiple variables. The interrelationship diagram can help stakeholders understand the relationships between causes and effects and can identify which of the causes are the primary one producing the problem

Consider prioritizing need assessments to address the strongest cause first

Source: Business Analysis for Practitioners – Practice Guide, Page Number: 22 and 23

A Business Analysts focus on learning enough about the problem or opportunity to adequately understand the situation, a first qualitative investigation technique like an interview, observation can be used to uncover a broad understanding of the situation.

Situation Statement is an objective statement of a problem or opportunity that includes the statement itself, the situation’s effect on the organization, and the ultimate impact.

Project Charter: A document issued by the project initiator sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

Business Need: The impetus for a change in an organization, based on an existing problem or opportunity. The business need provides the rationale for initiating a project or program

Business Case: A documented economic feasibility study used to establish the validity of the benefits of a selected component lacking sufficient definition and used as a basis for the authorisation of further project management activities.

When no internal data exist or when it cannot be feasibly collected, in that case benchmarking may be performed. Benchmarking is a comparison of the metrics or processes from one organization against a similar organization in the industry that is reporting or finding similar industry averages. Benchmarking may also involve comparing internal organizational unit or processes against each other.

Document Analysis, Questionnaire and sampling are the tools which can be used in data collection and business analyst identified that collecting data is not feasible.

Pareto Chart: Pareto chart is a special form of vertical bar chart and are used to identify the vital few sources that are responsible for causing most of a problem’s effects.

Requirement Traceability Matrix: A grid that links product requirements from their origin to the deliverables that satisfy them.

SWOT Analysis: SWOT Analysis. Analysis of strengths, weaknesses, opportunities, and threats of an organization, project, or options.

Interviews: A formal or informal approach to elicit information from a group of stakeholders by asking questions and documenting the responses provided by the interviewees.

The format of a situation statement is as follows:

• Problem (or opportunity) of “a”
• Has the effect of “b”
• With the impact of “c”

In this example problem is: “The queue length at sale checkout counters of supermarket is increasing steadily over a few months”
The effect is: “which has the effect of increasing the significant servicing delay for each customer”
But financial impacts in the situation statement are lacking, financial impacts in situation statement later help in cost benefit analysis.

While establishing and maintaining relationship with stakeholders are important for a business analyst, stakeholders need to be informed and consulted that were identified and categorized in RACI matrix, however agreement is needed from all of identified stakeholder groups for Need Assessment to ensure the essence of the current situation is captured. This agreement is needed as right situation statement correctly define the situation and help subsequent work in assessing business need. Therefore, negotiation and facilitation skills become crucial for the agreement to ensure the situation is not reflecting only part of business need.

Business Analyst performed a root cause analysis for agreeing problems which are in the context of organizational goals and objectives and provides criteria about which problem need to be solved.

Organizational goals and objectives are not required to write if they are already available for review.

Problems needs to selected to solve which are in the context of organizational goals and objectives, therefore business analyst is required to set the direction for further needs assessment after review of strategy documents or formal business strategic plans. If these plans are not available in that case you may choose to write goals and objective or alternatively you can perform SWOT analysis to have high level aspect of the organization, especially pertain to the situation. It helps to translate organizational strategy into business need.

A Business analysis planning, how it conducted is heavily dependent on the selected project life cycle; therefore a planning activity is performed differently across life cycles or not performed at all.

There is no one approach to business analysis planning that will work for every project, so ultimately the business analyst should understand the context and project characteristics enough to ensure the planning activities are sufficiently sized for the situation.

Relevant Stakeholders involvement is needed for successful business analysis planning, however review of project goals and objectives are needed in order to provide context for business analysis activities. Development of project goals and objectives performed prior to business analysis planning.

Too much planning can be counterproductive, therefore the business analyst needs to plan a sufficient level of detail to address the specific needs of the project such as the size, complexity, and risk level.

Here, business analyst started performing elicitation just after review of business case, and did not perform sufficiently sized business analysis planning as per the identified context and characteristics of the project, if it could have happened, that would have helped to make sure that stakeholders are aware about elicitation techniques, their schedule related conflicts are minimised, and a method could be devised to handle conflicting stakeholders requirements as business analysis plan is built in collaboration with stakeholders. If plan is performed in collaboration with stakeholders, then during elicitation, information backed with goals (or business need) could help in negotiation and influencing of stakeholders therefore easy alignment with business need could happen.

Business analysis planning and scheduling is not performed independently of project management scheduling activities. It is a best practice to have the project manager and business analyst working closely together while the business analysis approach and plan is formulated. Business analysts will develop a work plan to cover the activities they are responsible for performing; however, the work plan should be integrated into the overall project management plan managed by the project manager.

Business Analysis work plan also help to provide direction on how to engage stakeholders, however it is not the only objective.

When using a predictive life cycle, planning is performed up-front prior to elicitation. In adaptive life cycles, some planning is performed up-front and plans are adapted or evolve over the course of the program or project. Formal change management procedures are not included in adaptive life cycle, it is taken care of in methodology itself. or organically managed.

Too much planning can be counterproductive, therefore the business analyst needs to plan a sufficient level of detail to address the specific needs of the project such as the size, complexity, and risk level.

Business analyst determines the business analysis schedule along with collaboration with stakeholders and Project Manager is the main collaboration point. Team and other stakeholders provide input. Project Manager is responsible to determine resource needs and constraints and business analyst help him/her with details of resources needed to perform business analysis activities.

Need Assessment Sponsor (belong to senior management) is responsible to approve the business case. Stakeholders do however help in determining constraints and deliverables.

Experienced stakeholder can understand the intent of the requirements, and that is most essential element to validate the requirements. A business analyst should consider the number of years of industry experience stakeholders have, whether they have worked with the organization for an extended length of time or whether an individual stakeholder is new to the organization. Thesefactors can influence how requirements are validated and approved as well as the number of stakeholders toengage from a stakeholder group.

Requirement Traceability Matrix: A grid that links product requirements from their origin to the deliverables that satisfies them.

Coverage matrix is also known as Requirement Traceability Matrix, there is no term ‘Requirement Trace Matrix’.

Requirement management plan is developed by identifying stakeholders, roles and responsibilities, communication protocols, and methods for eliciting, analysing, documenting, managing, and approving requirements in order to establish a roadmap for delivering the expected solution.

The requirements management plan covers planning decisions for both the product and project requirements, the business analysis plan works in conjunction with the requirements management plan.

The business analyst should work closely with the project manager to ensure content is not duplicated between the documents and that the planning decisions for both the project requirements and product requirements are covered.

This information is documented in communication management plan.

A communication approach describes how business analysis information will be structured and when communication to stakeholders will occur. The approach can be formally documented in the business analysis plan or in a separate business analysis communication plan if the project or organizational needs require this level of structure or formality.

This is an example of solution requirements. Solution requirements are further grouped into functional and non-functional requirements.
Non-functional Requirements: Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties.

Use Case models contain the graphical diagram and use case narrative

Use Case: An analysis model that describes a flow of actor-system interactions and boundaries for those interactions, including trigger, initiating and participating actors, and preconditions and post conditions.

Use Case Diagram: A business analysis model that shows all of the in-scope use cases for a project which actors have a part in those use cases.

WBS is the hierarchical decomposition of project and product scope to accomplish project objectives.

Progressive elaboration is the iterative process of increasing the level of detail in a project management plan as greater amount of information and more accurate estimates become available.

Context Diagram: A visual depiction of the product scope showing a business system (process, equipment, computer system, etc.) and how people and other systems (actors) interact with it.

Scope Diagram is distractor here.

As a facilitator, you are helping participants to reach to a desired outcome of the session; as a result you need to primarily focus on enforcing discipline and ground rules. If you start participation, or involve in making decision or providing information, it will be actually a roadblock in facilitation and objective of session may not be achieved.

These are all examples of solution requirements. Solution requirements are further grouped into functional and non-functional requirements.

Functional Requirements: Requirements that describe the behaviour of a product.

Non-functional Requirements: Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties.

Options other than B are related to behaviour of the product, and option B represents properties of product.

Business Case: A documented economic feasibility study used to establish the validity of the benefits of a selected component lacking sufficient definition and used as a basis for the authorisation of further project management activities.

Business Need: The impetus for a change in an organisation, based on an existing problem or opportunity. The business need provides the rationale for initiating a project or program

Business Case is majorly comprised with cost benefit analysis and business need.

This does not directly address the need for clarity of the scope and business need.

Details of why the project has been selected and complexity and idea of size can be taken from business case; here the stakeholders need an understanding of why the project was undertaken               and its benefit

Here, the traceability matrix has not been fully created yet as requirements is still being elicited. Also missing is what the requirements trace to–i.e., the business requirements.

Requirement workshop is a facilitated workshop and as it brings together stakeholders in order to achieve consensus, it is a technique to quickly elicit requirements. Interviews, document analysis, and surveys may not be able to quickly reach a consensus.

Facilitated Workshops: An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements. In business analysis, facilitated workshops use a structured meeting that is led by a skilled, neutral facilitator, in which a carefully selected group of stakeholders collaborate to explore and evaluate product requirements.

Interviews: A formal or informal approach to elicit information from a group of stakeholders by asking questions and documenting the responses provided by the interviewees.

Document Analysis: An elicitation technique that analyses existing documentation and identifies information relevant to the requirement

Questionnaire and Surveys: A written set of questions, designed to quickly accumulate information from a large number of respondents

Functional Requirements: Requirements that describe the behaviour of a product.

Non-functional Requirements: Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties.

Requirements workshop is a facilitated workshop.

Facilitated Workshops: An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements. In business analysis, facilitated workshops use a structured meeting that is led by a skilled, neutral facilitator, in which a carefully selected group of stakeholders collaborate to explore and evaluate product requirements.

In workshops, you can speak to more people in less time and save money.

Estimation and stakeholder analysis are not prioritization technique. Decision analysis and risk analysis also plays role in prioritisation. High risk items are sometimes prioritised high.

Decision analysis includes tools like delphi technique, multi-voting, consensus building, options analysis

Multi-Voting, MoSCoW analysis and time boxing all are prioritisation techniques.

Multi-voting Process: A technique used to facilitate decision making among a group of stakeholders. Participants are provided with a limited number of votes and are asked to apply those votes to a list of possible options. The option with the most votes is determined to be the most favorable option. Multi-voting processes can be used to prioritize requirements, determine the most favorable solution, or to identify the most favorable response to a problem.

MoSCoW: A technique used for establishing requirement priorities. In this technique, the participants divide the requirements into four categories of must haves, should haves, could haves, and won’t haves.

Time Boxing: The Timeboxing technique is based on the premise that it is better to have a working system with limited functionality than to wait for years to have a complete system. With this technique, the project team can guarantee the delivery of the most important requirements on specific dates, with other requirements scheduled for release on successive dates.

Traceability can be started as soon as the first requirement is defined and detailed, because therequirements are progressively elaborated, allowing for the incremental development of the requirements.

Beginning of Traceability building after all the requirements are defined and detailed, it would be too late and not in line with rolling wave planning of requirements

We are not required to wait for traceability till a requirement is having all the details from its origin to final deliverable, as a formal traceability matrix is usually built hierarchically, starting with high-level requirements and filling in the details as the requirement is progressively elaborated. This hierarchy is similar to an outline that is filled in as more detail is known.

As lower-level requirements are defined, these are evaluated against the higher-level requirements for alignment.

It is true that in building of traceability, business analyst needs to define the format, however for actual building at least detailing and defining of first requirement is needed.

Some organizations develop a traceability matrix template as a starting point.During business analysis planning, the business analyst collaborates with the project manager and business stakeholders to determine which components of the template are to be used during the project, which components complete the matrix, and at what point during business analysis is traceability considered to be complete.

Each project does not require the same amount of traceability and it is identified during business analysis planning.

Requirements are often related to other requirements; sometimes a requirement is not able to be satisfied in a solution without the other(s) being present, therefore grouping of dependent requirements is useful for effective traceability.

Dependency analysis is a technique used to discover these dependent relationships. Once analysed, the set of requirements on the traceability matrix is recorded by grouping dependent requirements together.

Some requirements management tools illustrate the dependencies visually by creating traceability trees.

Impact analysis is a technique that uses dependent requirements as input to analyse impacts after a change request recorded.

Value analysis and implementation analysis are a distractor here.

Organizations and projects vary in how requirements are approved.

Some organizations require a formal sign-off on a requirements package, such as a business requirement document.

In other organizations or for specific types of projects, the approval of requirements may be informal, requiring only a verbal approval.

The approval process is determined, documented, and approved up-front in business analysis planning. Determining the process early helps to avoid conflicts later when the approvals are being sought.

The business analyst, project manager, and sponsor determine requirement approval levels in business analysis planning. Tools such as a RACI are helpful in facilitating discussions and decisions about approval levels.

The work authorization system defines the process for authorizing work. It may include process steps, documents, tracking systems, and approval levels. The work authorization system is one of many organizational environmental factors that lie outside the control of the project team and therefore constrain the project team’s options.

Hence, work authorisation system is an enterprise environment factor, it not only includes process steps but also tracking system and approval levels.

There is often confusion between project managers and business analysts as to who manages scope. The project manager is responsible for managing project scope while the business analyst is responsible for managing product scope. The process of tracing requirements is a clear example of the involvement that the business analyst has in scope management at the product level.

Work products created across phases, such as design and test documents, are created for each approved requirement.

For example, in a software development project, approved requirements need to be designed, built, tested, implemented, and verified, so that appropriate work products, such as the physical database design and other design documents, programs, and test cases can be developed.

Using requirement traceability matrix, requirement relationships are monitored to their related work products to help ensure that gaps between the approved requirement and what has been built and tested are not missed.

Therefore, requirement traceability matrix is a valuable tool to understand the approved requirements that need to be tracked and as a result what are the related work-products for which business analyst need to be involved.

Impact Analysis: A technique for evaluating a change in relation and how it will affect other requirements, the product, the program, and the project.

Therefore impact analysis is a technique that is used to analyse impacts in related requirements when a change request comes.

Value analysis and dependent analysis are a distractor here.

Requirement relationships are monitored to their related work products to help ensure that gaps between the approved requirement and what has been built and tested are not missed. When gaps are identified, the business analyst should:

I. Cancel or defer the approved requirement, or
II. Create the missing work product.

However, decision should be based on business value, if cancelling is adding value to the overall business need, then business analyst needs to take action based on business analysis planning where it is mentioned about who has the authority to cancel the requirements.

It may be the case that work products need to be created even for the low business value approved requirements due to other dependencies, in that case business analyst needs to schedule the creation of work product and that would be according to newly identified priorities.

PMI defines scope creep as the uncontrolled expansion to product or project scope without adjustments to time, costs, and resources.

Key to prevent scope creep is to review each work product through the project to ensure it links back to an approved requirement

Ensuring each work product lies in requirement traceability matrix as a requirement attribute is an unrealistic approach. It will introduce risk of overuse. There is always a need to discover optimal amount of traceability and monitoring appropriate for work in the project.

Ensure stakeholders are involved in maintaining requirement traceability matrix is not the primary responsibility of stakeholders, it is responsibility of business analyst. Stakeholders are involved to use the traceability to get the benefit of it.

Ensuring impact analysis for a change request using requirement traceability is a good idea, however scope creep is controlled better by linking of work product to approved requirements.

Requirements are often related to other requirements; therefore, sometimes a requirement is not able to be satisfied in a solution without the other(s) being present.

Dependency analysis is a technique used to discover these dependent relationships. Once analysed, the set of requirements on the traceability matrix is recorded by grouping dependent requirements together.

Some examples of dependent relationships are as follows:

I. Subsets:A requirement may be a subset of another requirement
II. Implementation Dependency:Some requirements are dependent on the implementation of other requirements before they can be implemented.
III. Benefit or Value Dependency:Sometimes the benefit of a requirement is unable to be realized unless another requirement is implemented first.

There are many benefits of monitoring requirements throughout the life cycle using a traceability matrix and one key benefit is to ensure as more detailed requirements that surface are linked to the baselined requirements. As the requirements are progressively elaborated and additional details surface, the relationships are progressively elaborated.

Requirement relationships are important to monitor product scope not to measure the strength of development team.

The status or state of a requirement is a common attribute on the traceability matrix. The state of a requirement characterizes where it is in the requirements life cycle. The requirements life cycle, should not be confused with the project life cycle, represents the various phases that a requirement moves through as it is maintained across the project.

Formal traceability matrices provide verification that requirements support business goals and objectivesand that testing sufficiently covers the requirements.

Goals and objectives and the traces between them and therequirements that support them provide insight into candidate metrics for evaluation.

Additional collaboration with subject matter expert is also beneficial, though SMEs also need to see project specific details before providing any advice.

Recognising sufficient test coverage is needed to identify candidate metrics, however without linking with goals and objectives and trace between requirements, it is not sufficient.

Evaluation of a software solution is usually conducted against a system thatis either to be released or has already been released; therefore, testing during evaluation usuallyencompasses a larger body of data than the initial testing. As a result, new and different kinds of data anomalies may be uncovered by looking at the results of tests used to directly confirm the data, andthese anomalies will need to be analysed.

Option A: Solution evaluation is performed by business users, therefore testing need is to be repeated. During solution evaluation, testing is not repeated; testing with larger body of data is performed, results are evaluated and anomalies are uncovered instead. Here focus and method changes are used instead of repletion of testing.

Option B: Solution evaluation use different metrics to ensure alignment with Business Case, therefore results of tests need to be evaluated.It is true, however how is it done? Testing with a larger body of data, results are then evaluated and anomalies are uncovered.

Option C: Evaluation of test results is necessary to have the sign-off from the stakeholders using evaluation of test results as evidence. Sign-off is necessary, however first solution evaluation is necessary.

Factors to consider when planning for evaluation activities include:

I. What project or organizational goal, objective, or risk does evaluation activity monitor or track or confirm?
II. Who will cover costs for the time and effort needed to conduct evaluation?
III. Does the solution or its infrastructure have built-in measurement capabilities for the evaluation criteria? Additional data may need to be stored programmatically if lack of built in measurement capabilities does exists.
IV. Are there already ways to extract measurement data to use in the evaluation?
V. Is the chosen evaluation method effective and relatively inexpensive?
VI. Are there already existing ways to report and publish the results of an evaluation?

Sponsor preferences for the evaluation activities is important, however sponsor preferences itself comes from above mentioned factors.

Business goals and objectives and priorities enable a project to launch and hopefully result in a solution. The solution needs to be evaluated against those goals and objectives. Goals and objectives combination need to be SMART.

The measurements specified in the goals and objectives serve as good clues as to what needs to be measured during the evaluation of the solution.

Objectives are relevant to goals, and specific and achievable are good in identifying evaluation criteria, however general evaluation activities involve more precise, quantitative, explicit measurements.

Key performance indicators (KPIs) are metrics that are usually defined by an organization’s executives. These indicators can be used to evaluate an organization’s progress in achieving its objectives or goals.

Typical broad categories of KPIs are: finance, customer, sales and marketing, operational processes, employee, and environmental/corporate, and social responsibility/sustainability.

Sometimes information technology is rolled into the operational processes category and sometimes it is considered a separate KPI category.

No of changes in a project metric is related to a project, not with organisation progress.

Project Manager is accountable to achieve the project objectives.

Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them. Origin is generally defined by project goals and objectives and/or business need.

This origin makes the objective a key element of requirement traceability matrix.

Gap Analysis: A technique for understanding the gap between current capabilities and needed capabilities. Filling the gap is what comprises a solution recommendation.

Therefore the gaps between them will form the program or project objectives

Most project goals and objectives are associated with one or more KPIs. For organizations that already define and measure KPIs, one or more of these KPIs can be used to evaluate the solution, taking advantage of measurement capabilities for KPIs that have already been used in some way.

It is important to distinguish between those metrics that support evaluating the solution and those that focus on project execution.

Project execution metrics do not reflect theactual quality of the solution nor whether it provides value to the stakeholders or customers. These project execution metrics reflect the efficiency and progress of the project.

Project manager is responsible to perform Earn Value calculations for the financial evaluation of solution. Metrics derived from measurements of cost, effort, and duration, such as variances between estimated amounts and actual values are purview of project management rather than business analysis.

However, these metrics can contribute indirectly to evaluating a solution, like whether the solution was delivered to the business faster and whether delivering some functionality sooner provided the business with any benefits.

From a customer perspective, evaluation sometimes focuses on qualitative aspects, such as satisfaction, but even qualitative aspects can be measured semi quantitatively.

For example, what percentage of customers responding to the survey report indicates they are very pleased or extremely pleased?

Measuring quality of data collected in a survey report and measuring the return of investment for the survey activity has nothing to do with solution evaluation.

Number of customers who are responding is directly proportionate to solution acceptance- it is not always necessary. Analysis of this report communicates how well solution met the business need.

Team rate of progress does not indicate how well solution met the business need.

Customer Metrics, from a customer perspective, evaluation sometimes focuses on qualitative aspects, such as satisfaction, but even qualitative aspects can be measured semi quantitatively.

Sales and marketing may have ranges of measurable goals for the project (e.g., a range of expected values for overall increased market share or a range for percentage increase in the amount of business done with existingcustomers). The solution can be evaluated to determine whether or not these expectations have been met.

Operational metrics may be functional or non-functional and can be considered from a systems perspective, a human perspective, or both. For organizations that define and measure operational

KPIs, it may be possible to re-useone or more of the metrics to evaluate the solution.

Exploratory Testing: An unscripted, free-form validation or evaluation activity conducted by someone with in-depth business or testing knowledge to validate the product and discover product errors.
All other options are a distractor here.