SHAREPOINT
REQUIREMENTS ANALYSIS
15 Tips for Bulletproof
Requirements Analysis
And Documentation
About Hershey Technologies…
• Founded in 1991
• Microsoft Partner
• Specialists in
• Document Imaging / Scanning
• OCR (data and document capture)
• ECM
• BPM / workflow
• End to End SharePoint Consulting Services
• Follow us on Twitter: @HersheyTech
About Tom Castiglia…
• Principal at Hershey Technologies
• Twitter: @tomcastiglia
• Email: tcastiglia@hersheytech.com
• Joined Hershey Tech in 1998
• Director of Hershey’s professional services team since 2001
• Passionate about ECM and Workflow solutions for SharePoint
• Founding Member of San Diego SharePoint User Group (@sanspug)
Agenda
• Provide specific, field tested techniques to ensure
accurate and complete project requirements
• Geared more for “waterfall” lifecycle, rather than Agile
projects, however…
• Some techniques borrow from Agile
• Some techniques are useful in Agile projects
What types of projects does this apply to?
• Best for medium - large custom solutions, such as:
• Workflow projects
• Application integration
• Content Migration / Upgrades
• Projects…
• That are Mission Critical
• That require an ROI justification before they can be started
Why?
• To accurately estimate project costs, precise requirements are
needed.
• Even small changes in requirements can sometimes cause a large impact to
project costs
• A changes in requirements are more expensive the later they occur in the project
lifecycle
• Getting requirements right saves time, money and usually ensures a project’s
success
Cost of changes
Cost of Change of Project Life Cycle
60
50
Axis Title
40
30
Cost of Change
20
10
0
Analysis
Design
Implementation
Axis Title
Testing
Support
Before you start…
• The customer must establish baseline technology platform demanded by
the business
• Example 1 –
• Customer says, “We need to display some financial transaction data from SAP
within the Marketing Team site in SharePoint 2010.”
• In this case, use of SAP and SharePoint become business requirements (not technical
requirements)
• Example 2 –
• Customer says, “We need to share some financial data with some users that are
outside of the finance department.”
• In this case, the consultant can propose appropriate technologies (such as SAP and
SharePoint) but these become technical requirements, not business requirements.
Tip #1 – Decide upfront how flexible your
requirements can be…
Solution Type
Typical Time
Frame
Comments
Out of box (OOB)
Hours to
Days
• Features that can be implemented by well trained end users,
directly from the browser.
• Incredibly broad set of features, but not very deep
InfoPath
Hours to
Weeks
• Generally requires SP Enterprise CAL
• Very powerful form design and integration tool
• Decent re-usability story
SharePoint Designer
Hours to
Weeks
• Heavily customizable, but not infinitely
• Requires a developer or well trained IT Pro or business analyst.
• Not ideal for re-usability
Custom Code
Hours to
Months
Anything you can think of can be implemented
3rd Party
Hours to
Days
• Can be deployed by an IT Pro.
• If costs for product licensing + maintenance < custom
development costs, then this option should be considered.
Tip #1 – Consider Out of the Box Solutions
for…
• Users that have widely adopted SharePoint already
• Basic Document approval workflows
• List management (Excel replacement)
• Changing UI themes, colors and logos
• Ad-hoc taxonomy changes
• Projects with low ROI expectations
• Note – Does not support re-use or formal testing
Tip #1 – Consider InfoPath for …
• Customizing UI for OOB list forms
• Straight up Data Capture tasks, like a survey
• Custom approval forms for workflow projects
• Application integration via Data connections to SQL Server and web
services
• Rich user interfaces using configurable rules
Tip #1 – Consider SharePoint Designer for…
• Serial workflows process (reasonably simple)
• Branding / Custom Master Pages and Page Layouts
• Creating External Content Types with BCS
Tip #1 – Consider 3 rd Party solutions if …
• You require re-use across multiple environments
• You require formal QA Procedures (DEVQASTAGINGPROD)
• You have strict requirements that cannot be satisfied with OOB,
InfoPath or SPD
• You prefer to buy rather than build
• You identify a vendor/product that meets your needs at an
appropriate price.
Tip #1 – Consider Custom Code if…
• You require re-use across multiple environments
• You require formal QA Procedures
(DEVQASTAGINGPROD)
• You have strict requirements that cannot be
satisfied with OOB, InfoPath, SPD or a 3rd party
solution
• You prefer to build rather than buy
Tip #2 – Remember Project Management Triangle
Pick Any
Two
Tip #3 – Just because you have a hammer,
not everything is a nail
• Most software developers and SharePoint
consultants have their “favorite tools”.
• Do not make technology choices until the business
requirements are fairly well defined
• Most requirements can be implemented with 2-3
different types of solutions, you should know what
they are and be able to explain why one was
selected over the others.
Tip #4 – Start requirements with user stories
User stories are:
“One or more sentences in the everyday
or business language of the end
user or user of a system that captures
what a user does or needs to do as part of
his or her job function”
Tip #4 – Start requirements with user stories
• Common format for a user story is:
• "As a <role>, I want <goal/desire> so that <benefit>“
• Example:
• “As an AP Clerk, I want to get an invoice approved so that I can pay our vendor”
Tip #4 – Start requirements with user stories
• Add copius notes and details to each user story
• Notes should be as specific as possible.
• Notes may be included directly in the story or kept separate and linked
somehow.
Tip #5 – Use Unambiguous language
• Review every sentence in you requirements to determine whether it
could possibly be interpreted in more than one way.
• Re-state your customer’s requirements in your own words and verify
that your customer agrees that what you said means the same as what
they told you.
Tip #5 – Use Unambiguous language
(example)
A MB IG UO US S TAT E MENT
“Update existing
rows in the AP
Invoice Lists with
the check number,
check date, and
voucher ID”
U NA MB IGU OUS S TAT E MENT
“Update existing
rows in the AP Invoice
Lists with the check
number and check
date using the
voucher ID as a
unique identifier”
Tip #6 – Look for Low Hanging Fruit
• When budget is tight, classify
features by…
• Value to the client / ROI
• Development complexity (story points)
• Prioritize features that are high
value and low complexity first
• Focus on OOB features that can
add high value quickly and at low
cost
Tip #7 - Be sure to properly understand the
relationships in the data model
For example –
Your customer tells you
that invoices have a
single GL Code, so your
initial data model looks
like this…
Tip #7 - Be sure to properly understand the
relationships in the data model
You later find out that
one invoice may
occasionally contain
multiple GL codes,
and the data model
needs to be refactored like this
Tip #8 – Create UI Mockups for any
interfaces that are not OOB
• Many great tools available…
• Visio
• PowerPoint (Story Boarding feature)
• InfoPath
• Visual Studio
Tip #8 – Create UI Mockups for any interfaces that are not OOB
Tip #9 – Create workflow diagrams with
detailed legends
• Start with high
level over view
diagram
• One activity
block for each
major subprocess
Tip #9 – Create workflow
diagrams with detailed legends
• Expand each sub-process
into its own separate
flowchart
• Activity blocks are color
coded:
Automated Step
Manual Step
Decision Point
Termination
Tip #9 – Create workflow diagrams with detailed legends
Provide clear details
for every step
Tip #10 – Document Consolidation
• For larger projects, most IT organizations rely on at least two major
project documents:
• Business Requirements Document (BRD)
• Technical Design Document (TDD)
• For smaller to medium size projects, consider consolidating these into a
single “Solution Design Document” (SDD)
• Avoids duplication of info that is reflected in both BRD and TDD
• Less work
• Can offer greater clarity and context compared to separate BRD/TDD
Tip #11 – Be careful of Jargon
• If you are using SharePoint specific or other technical jargon, be sure to
explain it to your customer
• If your customer is using jargon that you are not clear on, don’t be afraid
to ask (and don’t guess/assume).
• If terms are ambiguous establish definitions up front. Document them
and use them consistently.
• (“client” vs. “customer”)
Tip #11 – Be careful of Jargon
• Common SharePoint Jargon:
• “ a Site”
• End-User thinks: “sub site within a SharePoint site collection”
• Developer thinks: “site collection”
• “a Web”
• End-User thinks: ???
• Developer thinks: “sub site within a SharePoint site collection”
• “Farm”
• End-User thinks: “huh?”
• IT Pros and Developers think: this refers to the collection of web servers, application
servers and database servers that power a single SharePoint environment
Tip #12 – You need to know what you don’t know
• You don’t need to know all the answers,
but you do need to know all the
questions that should be asked!
• Just because you have read or know
about a SharePoint feature, don’t
assume that feature works the way you
want it to unless you have specifically
used or tested that feature.
• If project is outside your expertise,
bring in an SME
Tip #13 – Clearly document Out-of-scope
requirements
• Your requirements document template should include a standard
section for “Out of Scope Requirements”
• Omitting a feature from the requirements document is not the same as
documenting that the feature is “not in scope”.
• If a feature was discussed even in passing, your client may assume it is
“in-scope” unless you clearly document it as out of scope.
Tip #14 – Don’t forget about
“Non-Functional Requirements
• Important Non-Functional Requirements that should be documented
• Scalability
• Performance
• Testability
• Robustness
• Maintainability
• Extensibility
• Many others documented at:
• http://en.wikipedia.org/wiki/Non-functional_requirements
Tip #15 – Make sure your customer carefully
reads the requirements document