BPC: How to Best Gather Requirements for SharePoint Projects

SharePoint is like water. It can be anything and something and nothing. People want to box it one way, and other people want to box it another way, which is fine, except that nobody's on the same page.

—Dux Raymond Sy

Why do requirements and SharePoint implementations fail? According to Dux Raymond Sy, the answer is lack of relevant communication.

Speaking at the Best Practices Conference today on How to Best Gather Requirements for SharePoint Projects, Dux emphasized that communication is key in order for requirements to succeed.

"Why are requirements so difficult? They're not sissy work," he asked. The trick, he said, is understanding the word: Requirements are something wanted or needed. They're capabilities that are needed to solve a problem. They are formally written and documented; they identify constraints on a system, service, product or process. They are capabilities that are needed to solve a problem.

To begin developing the requirement, look at it from three angles:

1.    Business requirements: What is the business focus for this requirement? The organization's focus?
2.    User requirements: What's the user's focus?
3.    System requirements: What is the system focus? What are the hardware requirements, operating system requirements and so on?

Take what you've gleaned from the angles, Dux stated, and use that to define your business needs—this is a must.  

For example: Information workers spend 45 minutes each day searching for information. In a team of 20 people, that's 900 minutes lost each day. So what if search productivity can be increased by 15%? That's gaining back 7 minutes from the 45 minutes lost.

Then map those needs to SharePoint requirements, and be specific.

Business requirement: SharePoint shall increase user productivity by 15%.
User requirement: Users can retrieve search results within 5 seconds of submitting a search request that can support a max of 10,000 simultaneous search requests.
System requirement: The SharePoint server shall have at least 2 WFEs and a dedicated SQL Server that has at least dual processors.

A well-defined business need and a clearly mapped SharePoint requirement create a trail, Dux noted. If someone asks why IT is setting up two WFEs, you can point to the requirements for the explanation.

There are four key components to developing requirements, he shared:

1.    Eliciting requirements
2.    Analyzing requirements
3.    Validating requirements
4.    Documenting requirements

Requirements elicitation involves finding out what the stakeholders and users need, determining requirements sources, and deciding how to gather information. In other words, get your hands dirty—talk, observe, research.

Then make sense out of the information by analyzing the requirements. Profile the users and understand and determine what the real requirements are.

Validate the requirements by allowing the users to prioritize the requirements. Help them understand the true cost, resources, time and skills sets needed to succeed—and that they can't have it all. The scope needs to be limited and specific. Pick one process that you can solve, Dux stated, "and they'll get that this is a business platform."

Once you've confirmed the requirements, get them on paper by documenting the requirements. Dux points out that a requirements document doesn't have to be 20 pages, but it does need to include the requirements statement, process diagrams and a traceability matrix.

A requirements document should have specific content in a good structure, he said. "Specific content has to be measurable. You can't just say, 'It's very fast.'" Start with a subject, then the capability, then the criterion: SharePoint <subject> shall increase user productivity <capability> by 15% <criterion>.

In conclusion, Dux emphasized that every internal SharePoint implementation should be treated as a project, no matter how small. "Otherwise, no one takes responsibility," he said, and the implementation is unsuccessful.

For more on the Best Practices Conference, check out the agenda or follow the conference on Twitter using the #bpc10 hashtag. For more about Dux, visit his Web site or follow him on Twitter. To see his presentation on video, visit his slideshare.net page.

Check out our full coverage of the Best Practices Conference 2010:

All SharePoint Versions

The web parts are functional components that extend your SharePoint environment whether it’s hosted, on-premises, or part of Microsoft® Office 365.

SharePoint 2013, 2016, 2019, Online (Office 365)

On-Premises Only

These web parts extend SharePoint beyond its out-of-the-box capabilities by tailoring it to your requirements with Bamboo Solution’s growing portfolio of SharePoint Web Parts.

SharePoint 2013, 2016, 2019


Product Suites

Experience greater power and savings by bundling our SharePoint apps and web parts.

Essentials Suite

Essentials Plus Suite

Bamboo Premier Suite

Project Management Suite

Knowledge Management Suite

External User Manager


For more information on our product suites, contact us.

Featured Services

SharePoint Health Check

A SharePoint Health Check will identify the causes of issues and risks associated with your specific environment, and is custom tailored to provide you with the best recommendations to optimize your SharePoint environment.

SQL Health Check

Document recommendations relating to performance, stability, availability, or a specific focus you request of your SQL Server database instances.

My SharePointXperts

The truth is that each SharePoint skill may not be a full time job for many organizations, and it is nearly impossible for one person to do everything you need – so augment your team with SharePointXperts; providing the skill sets you need when you need them!