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:

  • Emphasize the performer of the action
  • Express the sentence content with greater impact

Conversely, requirements can be written with a passive voice where the subject of the sentence receives the action of the verb. The performer of the action often disappears in this structure. For example: “Current billing and shipping addresses shall be provided by the customer as part of their customer records.” It is used to:

  • Emphasize the receiver of the action
  • Minimize the importance of the performer of the action

Which technique do you prefer?

5. The requirement does not use ambiguous wording

Can a requirement be interpreted in more than one way? If so, it is ambiguous. Choosing the right word is not always easy; For example, the word “bug” can mean:

  • Any small insect
  • A concealed microphone
  • A faulty piece of software

Where terms have multiple meanings, make sure you define each word based on document audience, scenario and purpose. A glossary in your requirements document is a standard way of including these definitions.

Clearly defining key words used in SharePoint requirements is very important. Terms such as lists, content types, terms store, site collection, web application are often misunderstood.

6. The requirement does not contain grammar or spelling errors

It’s All About Getting on the Same Page

With SharePoint being such a flexible and powerful platform, it is far more important to get stakeholders on the same page. Investing in a pragmatic approach to requirements development for SharePoint projects minimizes inconsistent expectations early on.

Hopefully you found this series beneficial to delivering relevant SharePoint solutions to your organization.