LESSON 14 UNDERSTANDING REQUIREMENTS, BUSINESS ANALYSIS KNOWLEDGE AREAS

Requirement

A statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user.

It describes what is wanted and what it will do.

Requirement Specification

Can define the direction of work and control the features of the system.

Requirements Analysis

An effective analysis of your requirements will allow you to understand what you need and what you want in order for your project to be a success.

1. Poor definition of requirements

2. Ineffective communication

3. Lack of handover process

4. Lack of sponsor involvement

5. Poor strategic alignment

6. Poor risk management

7. Poor planning

8. Long time to delivery

9. Scope creep

The 9 top reasons for project failures

• 60%-80% of project failure can be attributed directly to poor requirements gathering and analysis.

1. Know the context in which the business operates

2. Understand the business problem or opportunity

3. Identify gaps to be bridged

Knowledge Needed For Quality Requirements

Know the context in which the business operates

The external context where market forces define how the business operates and maintains its susainability. This includes regulatory requirements, competitors and partners; the business operates in two contexts.

Understand the business problem or opportunity

This is the actual driver for the project. Without knowing the real business need, you won’t be able to find the solution that solves that problem.

Identify gaps to be bridged

Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Ambiguity

Does the requirement actually say what is required or is it all fluff and no substance?

Overlap

Are there requirements that might cross over with one another?

Realism

Is the requirement realistic, or is it just one person's pipe dream that could never be possible?

Testability

Can the requirement be tested?

• Ambiguity

• Overlap

• Realism

• Testability

Here are some useful words to use when documenting your requirements

Beware of:

MoSCoW

A standard business analyst format for prioritizing requirements is through this technique.

M UST HAVE

A requirement that is fundamental and must be met by the solution.

The most vital things you can’t live without.

S HOULD HAVE

A requirement for which, if not directly met by the solution, there is a workaround that is acceptable to the business.

Things you consider as important, but not vital

C OULD HAVE

A requirement that can more easily be left out of the increment under development.

The “nice-to-haves”.

W ON’T HAVE

A requirement that stakeholders have agreed will not be implemented in a given release but may be considered for the future.

Things that provide little to no value you can give up on.