Best Practices in
Gathering Requirements for
SharePoint Projects
Dux Raymond Sy, PMP
August 27, 2009
7.00pm (GMT)

Presentation Objectives
 In this presentation, you will learn the best practices in
gathering requirements for SharePoint Projects
 In addition, you will be able to identify:
 Why having a well defined business case is necessary to
effectively initiate requirements gathering
 The key components of requirements gathering process
 Why requirements traceability is paramount in defining
ROI in SharePoint projects

What Does This Mean?
8 5 4 9 1 7 6 3 2 0

What Does This Mean?
SharePoint

Dux Raymond Sy, PMP
 Managing Partner, Innovative-E, Inc.
 Author, “SharePoint for Project
Management” by O’Reilly Media
 Contract Author & Instructor,
Learning Tree International
 For more information, connect with Dux
 E-Mail: dux.sy@innovative-e.com
 LinkedIn: meetdux.com/li
 Blog: meetdux.com
 Twitter: twitter.com/meetdux

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

Why are Requirements So Difficult?

What is a Requirement?
 A requirement is something wanted or needed
 Formally documented and written statements
 Capabilities needed to solve a problem
 Conditions of a delivered system, services, product, or
process
 Constraints on the system, service, product, or process
 Requirements are not
 Verbal, informal statements or conversations in the hallways
 Solutions that state how to solve the problem or meet the
objectives
 Characteristics of other systems, services, products, or
processes
 Project budgets, plans, or implementation details

What’s So Special About SharePoint?

Requirements Focus

Example: Defining SharePoint Requirements
 Business requirements
 SharePoint shall increase user productivity by 15 percent
 User requirements
 The user shall be able to retrieve search results within five
seconds of submitting a search request that can support
a maximum of 10,000 simultaneous search requests
 System requirements
 SharePoint Search shall be able to perform 10,000
simultaneous search requests

Key Components of Requirements Gathering
1. Requirements Elicitation
2. Analyzing Requirements
3. Validating Requirements
4. Documenting Requirements

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

How Many Squares Do You See?

What is Requirements Elicitation?
 Elicitation: gathering and understanding what
stakeholders and users need
 Done at both an organizational (business) and a more
detailed user level
 Elicitation is a human-based activity
 Determine requirements sources
 Decide how to gather information
 Involves research, reading, talking, and observing
 Business-level context and framework
 How the end users do their jobs
 What would help them do their jobs better
 Within the scope of our system, product, or process

Elicitation Process
1. What do I need to know?
2. Where do I get this information?
3. Get the information
4. Organize what you know
5. Do I have enough information?

Goal is to Build a SharePoint Solution
 How would you like to drive a Lamborghini Diablo?
 BTW, you just learned how to ride a bike yesterday

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

What is Requirements Analysis?
 Requirements analysis takes elicited information and
makes sense of it

Analysis Process
1. Profile Users
2. Model stated requirements
3. Gap analysis
4. Identify the real requirements

Example: Process Flow Diagram

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

What is Requirements Validation?
 Requirements validation allows the user(s) to confirm and
prioritize the real requirements
 Essential to identify what it will take to deploy SharePoint
 Resources
 Time
 Skillsets

Example: SharePoint Project Schedule

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

Generate a Requirements Document
 Formally communicates
 Overall quantitative and qualitative characteristics
 Functionality of the desired end result or outcome
 Should include
 Requirement Statements
 Process Diagrams
 Traceability Matrix

What Makes a Great Requirement?
Content + Structure = Readability

Writing Requirement Statements
 <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

Example: Defining SharePoint Requirements
 Business requirements
 SharePoint shall increase user productivity by 15 percent
 User requirements
 The user shall be able to retrieve search results within five
seconds of submitting a search request that can support
a maximum of 10,000 simultaneous search requests
 System requirements
 SharePoint Search shall be able to perform 10,000
simultaneous search requests

Example: Requirements Document

Agenda
 What are Requirements?
 Eliciting is Not the Same as Gathering
 Analysis Doesn’t Lead to Paralysis
 Too Legit to Quit?
 Put it on Paper
 Summary

Questions?
E-Mail: dux.sy@innovative-e.com
LinkedIn: meetdux.com/li
Blog: meetdux.com
Twitter: twitter.com/meetdux
How did you like the presentation?
http://sp.meetdux.com/post_feedback.aspx

Summary
 You have learned the best practices in gathering
requirements for SharePoint Projects
 In addition, you are able to identify:
 Why having a well defined business case is necessary to
effectively initiate requirements gathering
 The key components of requirements gathering process
 Why requirements traceability is paramount in defining
ROI in SharePoint projects

Thank You!