Agility in SharePoint: Writing Functional Requirements

SharePoint brings more power than ever to the end user.  As usual, this is a double-edged sword.  Its utility as a development platform is unmatched, but since many of the development tools are accessible from the browser UI, the dividing lines can get blurred.

Requirements-gathering (and subsequent documentation) can be tricky, and it's easy for us technical types to get confused about functional versus technical.  Business users do not care about technical requirements and they should not have the opportunity to dictate them.  If you have to explain a term (for example, "list" or "metadata column") to an end user, then most likely it does not belong under the heading of "functional requirements".

Functional requirements are about what the end user needs to accomplish.  An excellent guide for this is the concept of the User Story, as employed in Agile project management (we're kind of big on that here at Improving).  The basic format is as follows:

As a _______ (what type of user),

I want _________

so that I can ___________

This kind of requirement requires (heh) that you also define acceptance criteria, by which you can determine that the requirement has been fulfilled. The end result is that nobody can claim confusion about what you're trying to do, since the team has already agreed on the definition of "done".