Presentation on theme: "15 Tips for Bulletproof Requirements Analysis And Documentation SHAREPOINT REQUIREMENTS ANALYSIS."— Presentation transcript:
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
About Tom Castiglia… Principal at Hershey Technologies 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
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
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 TypeTypical 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 InfoPathHours to Weeks Generally requires SP Enterprise CAL Very powerful form design and integration tool Decent re-usability story SharePoint DesignerHours to Weeks Heavily customizable, but not infinitely Requires a developer or well trained IT Pro or business analyst. Not ideal for re-usability Custom CodeHours to Months Anything you can think of can be implemented 3 rd PartyHours 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 3 rd 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”end useruser of a system
Tip #4 – Start requirements with user stories Common format for a user story is: "As a, I want so that “ 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 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:
Tip #15 – Make sure your customer carefully reads the requirements document