15 Tips for Bulletproof Requirements Analysis And Documentation SHAREPOINT REQUIREMENTS ANALYSIS.

15 Tips for Bulletproof Requirements Analysis And Documentation

SHAREPOINT REQUIREMENTS ANALYSIS

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: [email protected]

• 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

Analysis Design Implementation Testing Support0

10

20

30

40

50

60

Cost of Change of Project Life Cycle

Cost of Change

Axis Title

Axis

Tit

le

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 3rd Party solutions if …• You require re-use across multiple environments

• You require formal QA Procedures (DEVQASTAGINGPROD)

• 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 (DEVQASTAGINGPROD)

• 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

• 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 #3 – Just because you have a hammer, not everything is a nail

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)

AMBIGUOUS STATEMENT

“Update existing rows in the AP Invoice Lists with the check number, check date, and voucher ID”

UNAMBIGUOUS STATEMENT

“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 re-factored 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 sub-process

Tip #9 – Create workflow diagrams with detailed legends

• Expand each sub-process into its own separate flowchart

• Activity blocks are color coded:

Automated StepManual Step

Decision PointTermination

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