Best Practices in Gathering Requirements for SharePoint Projects
Upcoming SlideShare
Loading in...5
×
 

Best Practices in Gathering Requirements for SharePoint Projects

on

  • 28,151 views

Baltimore SharePoint User Group 2nd Anniversary Presentation

Baltimore SharePoint User Group 2nd Anniversary Presentation
June 18, 2009
Dux Raymond Sy, PMP

Watch Screencast: http://vimeo.com/5237148

Statistics

Views

Total Views
28,151
Views on SlideShare
27,980
Embed Views
171

Actions

Likes
9
Downloads
1,020
Comments
0

5 Embeds 171

http://www.slideshare.net 98
http://122.166.42.158 38
http://192.168.0.2 27
http://duxquax.com 6
http://sharepoint 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Best Practices in Gathering Requirements for SharePoint Projects Best Practices in Gathering Requirements for SharePoint Projects Presentation Transcript

  • Best Practices in Gathering Requirements for SharePoint Projects Dux Raymond Sy, PMP UMBC Training Center June 18, 2009 7.00pm
  • What Does This Mean? 8 5 4 9 1 7 6 3 2 0
  • What Does This Mean? SharePoint
  • 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
  • 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?
  • Write the Requirements for
  • 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   System requirements   SharePoint search shall support a maximum of 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   System requirements   SharePoint search shall support a maximum of 10,000 simultaneous search requests
  • 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
  • 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!