4 Key Steps in Developing Requirements for SharePoint Projects

By Dux Raymond Sy (@meetdux) Sep 1, 2010

As discussed in my previous post (How to Define Meas urable and Traceable Requirements for SharePoint Projects), focusing on the business requirements first, user requirements second and then system/technical requirements is necessary to effectively define measurable and traceable requirements for SharePoint projects.

In this post, I’ll show you and explain you the 4 key steps in developing requirements for SharePoint projects.

Requirements Development is Iterative

Whoever told you that requirements development in a SharePoint project is a one-time event is clearly a poser. Developing SharePoint solutions is an iterative process (especially during Business and User requirements development) where both the customer and the implementation team specify, prioritize, validate and document what the project requirements are.

In my experience, business, user and system/technical requirements development involves these 4 key steps:

Requirements Elicitation
Analyzing Requirements
Validating Requirements
Documenting Requirements

Editor's Note: You can read more articles by Dux on SharePoint, including 5 Tips on Effectively Planning for SharePoint 2010 Migration.

Step 1: Eliciting is Not the Same as Gathering

Requirements Elicitation is the process of gathering and understanding what stakeholders and users need. This is performed both at both an organizational (business) and a more detailed user-level. Elicitation is a human-based activity; it entails face time and interaction between the customer and a SharePoint analyst.

This individual is NOT just an order taker from the customer, the analyst would want to find out business pain points around operational collaboration (i.e. meeting management, sharing files), business processes (i.e. employee onboarding) and reporting (i.e. monthly sales report).

The goal is to find out not only what the customer wants/needs, but also to identify existing pain points that can be easily addressed with SharePoint which would help them do their jobs better.

During this process, the analyst is responsible for:

Determining requirements sources — specific people, focus groups, industry research
Decide how to gather information — surveys, interview, focus groups
Understanding business-level context and framework
Investigating how the end users do their jobs

Essentially, the analyst would have to address the following questions during requirements elicitation:

What do I need to know?
Where do I get this information?
Does the information make sense?
Do I have enough information?

Remember, the goal is to identify a business solution and not showcase SharePoint whiz-bang features. You also have to consider how to promote better adoption once the solution is in place. That’s why minimal disruption or change to their technical habit/routine is important.

You wouldn’t want to give your customer a Lamborghini Diablo if they’ve just learned how to ride a bike yesterday.

Step 2: Analysis Doesn’t Lead to Paralysis

Requirements analysis takes elicited information and makes sense of it. The goal is to identify the real requirements.

For example, we had a customer with the marketing department who is challenged with managing events they organize for their partners around the world. Traditionally, they’ve relied on emails, spreadsheets and web-based tools to organize, communicate and manage these events. Their pain point? It’s really hard to assess, track and report the value that these events brings back to the business. Analysis of data (i.e. how many people registered and attended the event? Did they attend multiple events? Did their company buy more products after the event? How many people from the same company attended these events in the last 4 years?) is manually put together.