Best Practices in Gathering Requirements for SharePoint Projects

  • 1,672 views
Uploaded on

Webcast for SharePoint Users Group UK …

Webcast for SharePoint Users Group UK
April 27, 2009

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,672
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
92
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Best Practices in Gathering Requirements for SharePoint Projects Dux Raymond Sy, PMP August 27, 2009 7.00pm (GMT)
  • 2. 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
  • 3. What Does This Mean? 8 5 4 9 1 7 6 3 2 0
  • 4. What Does This Mean? SharePoint
  • 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. 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
  • 9. What’s So Special About SharePoint?
  • 10. Requirements Focus
  • 11. 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
  • 12. Key Components of Requirements Gathering 1.  Requirements Elicitation 2.  Analyzing Requirements 3.  Validating Requirements 4.  Documenting Requirements
  • 13. 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
  • 14. How Many Squares Do You See?
  • 15. 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
  • 16. 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?
  • 17. 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
  • 18. 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
  • 19. What is Requirements Analysis?   Requirements analysis takes elicited information and makes sense of it
  • 20. Analysis Process 1.  Profile Users 2.  Model stated requirements 3.  Gap analysis 4.  Identify the real requirements
  • 21. Example: Process Flow Diagram
  • 22. 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
  • 23. 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
  • 24. Example: SharePoint Project Schedule
  • 25. 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
  • 26. 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
  • 27. What Makes a Great Requirement? Content + Structure = Readability
  • 28. 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
  • 29. 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
  • 30. Example: Requirements Document
  • 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 How did you like the presentation? http://sp.meetdux.com/post_feedback.aspx
  • 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!