Poor requirements can be attributed to failed SharePoint implementations. The key to successful SharePoint implementation is properly developing requirements. A lot of people know that this is important, however, only a handful of folks truly understand what it takes to do this right. In this presentation participants will be able to identify: - The key components of requirements gathering process - Why requirements traceability is paramount in defining ROI in SharePoint projects - Why having a well defined business case is necessary to effectively initiate requirements gathering Presented at the Atlanta SharePoint Users Group Meeting on August 17, 2009

1. Best Practices in
Gathering Requirements for
SharePoint Projects
Dux Raymond Sy, PMP
Microsoft Alpharetta
August 17, 2009
6.30pm (EDT)

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

3. What Does This Mean?
SharePoint

4. 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

5. 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

6. 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

7. Why are Requirements So Difficult?

8. Write the Requirements for

9. 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

10. What’s So Special About SharePoint?

11. Requirements Focus

12. 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

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

14. 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

15. How Many Squares Do You See?

16. 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

17. 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?

18. 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

19. 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

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

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

22. Example: Process Flow Diagram

23. 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

24. 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

25. Example: SharePoint Project Schedule

26. 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

27. 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

28. What Makes a Great Requirement?
Content + Structure = Readability

29. 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

30. 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

31. Example: Requirements Document

32. 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

33. 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

34. 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

35. Thank You!