Why Your SharePoint Project Should Start With Functional Requirements

Posted by Dan Sonneborn on 10.31.14
Dan Sonneborn
Find me on:

You've got a great idea. You know enough about SharePoint to know it's the right solution to a problem that's been lingering for months. In fact, you've been thinking about how to implement it and garner buy-in from other people to support your endeavor. The technical team is on board, and you're pretty sure department leads will be all for it. 

So let's create some sites and document libraries and run a prototype by stakeholders, right? Actually, let's not. Let's talk about what Functional Requirements are, and why they might just save your skin at the end of the day.

Functional Requirements outline 'The What' of your problem. Before jumping to the solution phase of a SharePoint project (which is a really common mistake), consider whether everyone would agree on a single problem statement. Create that problem statement and identify what the solution must incorporate in order to solve the problem. Getting stakeholders to agree on a problem statement before designing or building anything will foster greater buy-in over the long term.

Example Problem Statement: Storing our Policies and Procedures in a network share is cumbersome. Tracking document versions and the change management process for each document takes too much time leading up to audits.

Here's what the Table of Contents might look like for your functional requirements document



Create a requirements grid to identify all the features and functions that MUST be included in a successful solution. This will likely involve more than one person or role at your organization. Ensure everyone involved in the process communicates or includes their requirements for the project. In addition to what users list as requirements, address all the elements related to the project and identify the requirements for each. This may include information architecture, branding, security, governance or other feature categories. Use visualizations as needed to communicate different actions required by the system and its users.

Example Process Diagram:



 Starting with functional requirements ensures your whole team is in agreement on the project objectives, and that those objectives can be measured  and tested before the solution is used in production. The more thorough your functional requirements the more confidence you can have that your solution will meet users' expectations.

Topics: SharePoint, Information Architecture, SharePoint Intranets

Subscribe Here!

Recent Posts

Posts by Tag

See all