Requirements analysis kit for SharePoint 2010 collaboration site templates

In the course of my day job, I often find myself confronted with having to document things on paper that are easier to implement than document. One of these things is a SharePoint 2010 collaboration site template. As you know if you’re reading this, SharePoint has the ability to ‘wrap up’ the configuration settings, visual design and default content of any collaboration site into a site template which can be used to instantiate new sites. Most commonly, this is used to create blueprints for frequently repeated business processes, such as projects, committees or board meetings.

While creating a template is actually relatively easy to do in SharePoint, it’s not the easiest thing in the world to document, at least not to any acceptable degree of depth that a business analyst worth their salt would want to stand behind. And most organizations that I consult to have minimum expectations around what will be documented prior to implementation, regardless of how easy it is to implement.

The site template requirements analysis kit consists of two pieces:

• A mind map of a conceptual diagram, listing and linking key site template requirements to explore and capture
• A set of Balsamiq wire frames to create quick mockups for a requirements document (if might, on occasion, be cheaper/easier to use wire frames rather than create a prototype in SharePoint).

Let’s step through the mind map first, clockwise from the top right. I will outline what I would explore and capture for each major area captured in it:

Container objects: Capturing the ‘container objects’ for the site template means to define the libraries and lists that should be pre-instantiated in every site that will be created based on the template. For each library, we need to capture the configuration settings, metadata or content type requirements as well as define any views that will be created based on the metadata bound to the library. Configuration options need to include, at a minimum, whether versioning is turned on or not. For metadata, we need to decide whether we want ‘repeatable’ metadata based on globally available SharePoint content types, or whether simple, locally-managed columns are enough for our purposes. Either way, we need to capture the metadata columns that should be available in our libraries and lists. I have found the most effective way to be columns in a table/spreadsheet, with approximately the following headings:

• Column name
• Column type
• Mandatory or optional?
• Default value (if any)
• Notes.

Now that we understand the metadata we’d like to capture for each item in our libraries and lists, we’re ready to capture what views we need. Again, a table format will probably work:

• View name
• Default or not?
• Columns included
• Type of view
• Sorting/filtering/grouping/paging options required.

Home page: For the home page (and any other pages that we might need in our collaboration site), we need to define what web parts we’ll have, and where. It makes sense to finish a solid draft of the containers (see above) first, and then move on to web parts—mainly because thinking about web parts on the home page will give us additional ideas of what views into lists and libraries we might need. I would simply draw the home page using the Balsamiq wire frames included in this post (see below).

Permissions: For the vast majority of collaboration site templates in SharePoint, you could just leave the permissions as they are. Microsoft’s division into visitors, members and owners is actually very well thought out. Remember, you’re not gathering requirements for each individual site that will eventually be created based on your template; instead, you just need to get the basic setup right. Now, it’s possible that you need to create a special SharePoint permission group for your site template—an example might be “project managers” or “board members,” who might need elevated privileges in certain libraries or lists to perform their work. Your first course of action should always be to see if your business requirements can fit into Microsoft’s visitor—member—owner framework, as this will save you a lot of trouble.

Third party functionality: For certain specialized collaboration site templates, it may well make sense to just buy some functionality off the rack. To get a sense of what’s available out there, I recommend looking through sites like Bamboo Solutions or Hare Point. For the purposes of documenting our site template, it may be enough to simply state that the third party solution should be deployed by default. In addition, we may want to capture any default configuration options that are required.

Branding: To apply branding to our template, we need to document a branded master page. Since I’m not a graphic designer but have access to one in my day job, my typical course of action is to obtain my client’s brand requirements, colours, etc. and hand them off—together with a screen shot of a generic SharePoint 2010 collaboration site. It’s also always useful to mention that SharePoint collaboration sites are infinitely width-scalable, so the header needs to be designed in such a way that it’ll still look good on very large monitors. Often, this involves some kind of colour fade to the right. Once the designer gets back to me with a mockup, I include it in my requirements document.

Navigation: For collaboration site templates, we realistically only need to break down the initial configuration we want in the SharePoint quick launch navigation (left hand side). Since this is fully configurable, we may want to be pretty specific here: Do we want links to all of our container objects (see above)? Do we want the default group labels provided by SharePoint (“Libraries,” “Lists,” “Sites,” etc.), or do we want groupings that are more specific to our intended business purpose for this template? Do we want to include direct links to certain library or list views (since presumably we have defined a few above)? Did you define any pages other than the home page? If you did, you’d need to link to it from the navigation, otherwise your users won’t find it.

Governance: It makes sense to outline a little ‘governance’ for our new site template. This should be practical and minimally focused on the very specific business requirements we are capturing. For example, who can get such a site, under what circumstances, and how do they get one? Are there specific user roles defined in this site whose responsibilities we might have to document in some way? What can site owners change about their sites based on this template—can you break it down specifically, or do you not care (either approach is legitimate)?

User manual: If your site template contains custom metadata, views and/or web parts that you want the users to use in specific ways, it might make sense to briefly document them in a user manual. Users—as you probably know if you’ve worked in SharePoint before—need an explanation of the metadata fields you’re asking them to provide (it’s not self-explanatory). Similarly, you might want to draft a quick ‘acceptable use policy’ for your site template (if your organization is that kind of organization).

Here’s a download link to a ZIP file containing two Balsamiq wire frames to help document SharePoint 2010 collaboration site templates. The first one is just a ‘frame’ and has a blank canvas in the middle. The second one is “Team Site”—you could use it as a starting point for your own home page layouts.

[button link=”https://carstenknoch.com/wp-content/uploads/2012/10/SharePoint-2010-Collaboration-Site-in-Balsamiq.zip”]Download the requirements kit[/button]

The wireframes are provided “as is” and I make no warranties as to their accuracy or usefulness. I’m sure there is lots of room for improvement—for example, better grouping of elements that belong together, and someone should really show me how to put the header/navigation elements into a re-usable template/master so that I don’t have to copy everything every time I need a new wire frame :) Either way, I hope these are useful to you in some way.