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:
Learning Opportunities
Webinar
Mar
21
Ready to Level Up Your Learning? Discover Your Learning Maturity Score
Learn how to level up your learning program in this free, interactive workshop
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Conference
May
10
CMSWire CONNECT Customer Experience Conference - Austin 2023
Don't miss the top customer experience and digital experience conference of the year — live in Austin, Texas May 10-12.
Conference
May
10
Reworked CONNECT Employee Experience & Digital Workplace Conference Austin 2023
North America's best employee experience and digital workplace conference of the year — live in Austin May 10-12, 2023.
- 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.