Search This Blog

Loading...

17 May 2011

What do we mean by the words Requirements and Scope

[Start at the beginning]


Something I keep learning is that there is no one type of business analyst and no one way of doing things. So rather than come here and tell you how you should be doing your work I want to try to simply share some techniques I and others have used and leave it to you to work out whether and when it can be of use.

So, what am I going to share with you?  Today, I want to explain the relationship between requirements management and project scope management.

Let me start with some simple definitions to get us all understanding each other. Possibly you all know this, but bear with me for a moment or two. It’s useful to see how the ideas are related.

Requirements
What is a requirement? It’s something we all intuitively know. It’s what is required by the customer right? Mandatory, must have it. It’s required because the client needs it to achieve some amazing business goal.
Good requirements management always starts with understanding the context and the purpose.

When asking people about their Business Requirements I like to start with understanding a client’s fundamental business model, or at least how the project fits into their strategy. It can be awkward sometimes, especially when the client doesn’t know themselves, but usually it yields more than it costs. So it’s a common practice of mine.

Understand the context.

And you all know about the various context levels of requirements; from business to system to the details within the system, like data requirements. So, there is no need to dwell on this too much.

Here are two industry definitions of what a requirement is:
IIBA/BABOK
  • When reading the BABOK Guide it is vital that ‘requirements’ be understood in the broadest possible sense. 
  • Requirements include but are not limited to past, present and future conditions or capabilities in an enterprise and descriptions of organisational structures, roles, processes, policies, rules and information systems (are all types of requirements.)
IEEE
  • A condition or capability needed by a user to solve a problem or achieve an objective
  • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  • A documented representation of a condition or capability as in (1) or (2)
That’s what we mean by requirement. The synonym is capability.

Scope
Now a definition of Scope. Scope is often defined up front in projects in a document, possibly with the title “Project Scope Document.”

Scope may also be addressed in other places like a “Project Charter”, a “Product Vision Statement” or other similar documents that get created in the opening stages of a project.

In some instances they may not be written down, but potentially captured in other media such as diagrams, video recordings and so on.

Here are the PMI Definitions for you;
Scope: The sum of the products, services, or results to be provided as a project.
Project scope: The work that must be performed to deliver a product, service or result with the specified features and functions
Product scope: The features and functions that characterise the product, service or result.
Scope creep: Adding features and functionality (project scope) without addressing the effects of time, costs and resources, or without customer approval
Thinking through this a little deeper, the main tool the PMI recommends to us to define scope is the WBS. We use this tool to break down the work - the requirements -  into organised components. Advanced instructions on developing a WBS talk about focusing on valuable deliverables at the top levels, and only breaking it down to activities and tasks only at lower levels of the structure.

Good WBS practice mens focusing on target capabilities, and then using this model to define the work.

And in case you are a Prince 2 Person; The OGC way addresses the issues of work planning slightly differently in technique and acronym, but in essence the same way. Prince2 instructs us to develop a Product Description (and elaborating it to a PBS) with a focus on the overall purpose of the project – how it will be used, or how it will contribute value, the components and features in the products, customer expectations on what done looks like, and the associated quality attributes.

Again, work is derived from what needs to be done to deliver target capabilities.

Fundamentally these project management approaches say that if you understand the requirements and you lead the way in understanding the project scope.

I'll break this down into a simple diagram tomorrow and share some examples of things that make the planning of work more complicated than simply saying the Requirements Specification = the Project Budget + Schedule.