6 Requirements for Writing SharePoint Requirements

By Dux Raymond Sy (@meetdux) Dec 7, 2010 Comments

1 comment

Now that you’ve learned how to effectively define measurable requirements and what the 4 key steps are in developing requirements for SharePoint projects, let’s look at what the 6 requirements are for writing SharePoint requirements.

Good Requirements Are Key To SharePoint Project Success

Writing requirements for SharePoint projects is every SharePoint consultants’ favorite activity, right? (Are you being sarcastic, Dux?)

It breaks my heart to learn that a common cause of failed SharePoint projects (failure not necessarily from a technical sense; it can be lack of adoption, business value of SharePoint not realized, etc.) is poor requirements or even worse, no requirements defined.

As I’ve described in Part 1 of my requirements for SharePoint projects post, requirements development should always begin from understanding the business requirement, mapping it to user requirements, then finally specifying technical SharePoint requirements based on the business and user needs. To effectively do this, there are 4 key steps in developing requirements, which I shared in Part 2 of my post.

To close this SharePoint requirements series, I’d like to share a pragmatic approach to documenting requirements with the 6 requirements for writing SharePoint requirements:

1. The requirement specifies a subject, a single capability and a criterion

Every requirement has three key parts:

Subject is the person, place or thing who performs the action
Capability is a single verb that describes an action taken by the subject
Criterion is an optional quantitative or qualitative limit, range or boundary condition

For example, a user requirement for the search results capability can be written as:

The user (subject) shall be able to retrieve search results (capability) within five seconds of submitting a search request that can support a maximum of 10,000 simultaneous search request/queries. (criterion)

2. The format of the requirement is standard

When writing business, user or technical requirements, having a standardized format/template can provide consistency and readability. The standard format can be as simple as:

<Subject> shall be able to <capability> within <criterion>
<Subject> shall be able to <capability> (Where criterion is assumed to be 100 percent of the stated capability)

Some examples:

The user (subject) shall be able to locate a specific SharePoint site (capability) within three clicks. (ctiterion)
Project managers (subject) can be able to synchronize their Microsoft Project schedule to a project task list in a SharePoint site (capability)
Executives (subject) can be able to take SharePoint site content offline (capability)
Financially-related information in spreadsheets (subject) must be accessible (capability) within seven years (criterion)

3. The requirement uses the appropriate focus word

Here are six common focus words:

Shall: Indicates a mandatory requirement to be met. Implies “is required to.”
Should: Indicates the preferred possibility of several recommended options. Implies “is recommended that."
May: Indicates a permissible course of action. Implies “is permitted”
Can: Used for statements of possibility and capability. Implies “is able to”
Must: Not to be used as an alternative to “shall”. Used only to describe unavoidable situations like legal compliance.
Will: Used in statements of fact. Not in the actual requirements

4. The requirement is written in active voice

With active voice, the subject of the sentence does the action of the verb. It focuses on the performer of the action within the sentence. For example: “The customer shall provide current billing and shipping addresses as part of their customer records.” It is used to: