How to Define Measurable and Traceable Requirements for SharePoint Projects

By Dux Raymond Sy (@meetdux) Aug 2, 2010

2 comments

A key contributor in successful SharePoint projects is having requirements properly developed and well-defined. In this 3-part series, Dux Raymond Sy will discuss how you effectively develop requirements for SharePoint Projects:

Part 1: How to Define Measurable and Traceable Requirements
Part 2: 4 Key Steps in Developing Requirements
Part 3: Practical Techniques in Writing Requirements

Being On The Same Page

What Does This Mean?

8 5 4 9 1 7 6 3 2 0

Bank account number? Random numbers? Telephone number?

Ok, what does this mean?

SharePoint

Collaboration? Document Management? Reporting? Records Management?

A common problem with SharePoint projects is not clearly defining what it’s intended for SPECIFICALLY to an organization. That’s why when you ask 10 people what SharePoint is, you’ll get 100 answers and all of them are correct. To be successful, it is important that SharePoint project stakeholders should be on the same page from the get go.

What if I were to tell you that the numbers above are arranged in an alphabetical order? Now we’re on the same page. In a similar fashion, prior to deploying SharePoint, a clear definition and understanding of the business value SharePoint brings to your organization is necessary – this can be achieved by properly developing requirements.

What’s So Special About SharePoint Projects?

Does the picture look familiar? A clueless project manager takes on the responsibility of slamming in SharePoint for the organization without clearly defining what business solutions it will deliver. Halfway through the implementation, the PM realizes SharePoint is such a multi-faceted platform that it can do everything, anything and nothing.

Realize that by definition, requirements are:

Formally documented and written statements
Capabilities needed to solve a problem
Conditions of a delivered system, services, product or process
Constraints on the system, service, product or process

It’s critical to clearly define what the requirements are because you want to make sure SharePoint is implemented so that it will address YOUR business needs effectively.

Focus on the Business First

Being a techie, I get drawn away by the whiz bang capabilities of the latest and greatest technology from time to time. A lot of people are guilty of this too when it comes to SharePoint project requirements. If you don’t believe me, try asking a SharePoint project team for their project requirements. What do you think you’ll get? In my experience, most likely you’ll end up with a document specifying the technical architecture of the implementation, number of front end servers, etc.

Having the technical requirements defined for a SharePoint project is great, however, it should not be the first step in your requirements development process. There are three related focus areas of requirements development for every project you engage in:

Business requirements describe and justify the high-level business functionality that is needed. Sometimes this is also known as a business case.
User requirements identify what is needed from the user’s perspective. These can be things that the system or product must do.
System requirements define desired characteristics of the system and properties that the system or product must have.

A common situation that I encounter is that requirements gathering for SharePoint deployments is focused at the system requirements or technical level. In the diagram above, notice that the three categories of requirements map to each other. System requirements should address the user requirements, which address the business requirements identified.