Baltimore SharePoint User Group 2nd Anniversary Presentation June 18, 2009 Dux Raymond Sy, PMP Watch Screencast: http://vimeo.com/5237148

1. Best Practices in
Gathering Requirements for
SharePoint Projects
Dux Raymond Sy, PMP
UMBC Training Center
June 18, 2009
7.00pm

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
 System requirements
 SharePoint search shall support a maximum of 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
 System requirements
 SharePoint search shall support a maximum of 10,000
simultaneous search requests

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

32. Questions?
E-Mail: dux.sy@innovative-e.com
LinkedIn: meetdux.com/li
Blog: meetdux.com
Twitter: twitter.com/meetdux

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

34. Thank You!