The document provides an overview of a presentation on how to write functional analysis documents for SharePoint projects. It discusses defining requirements, prioritizing requirements, and a 9-step methodology for functional analysis when using SharePoint. The methodology includes steps like visualizing requirements, describing information types, defining relationships between data, determining data storage and flows, and defining data access points and behaviors. The presentation provides examples and tips for effectively analyzing requirements and functionality for SharePoint solutions.

1. November 23rd, 2013
How to Write Amazing
Functional Analysis Documents
for your SharePoint Projects
•
•
•
•
Nathalie Jard
Franck Cornu
SharePoint specialists
GSoft

2. Thank you to all of our Sponsors!!

3. Who
ARE WE?
Nathalie Jard
Franck Cornu
•
Scrum Master
•
SharePoint Analyst
•
SharePoint Analyst &
Developer
nathalie.jard@gsoft.com
franck.cornu@gsoft.com
@najard
@franckcornu
http://www.gsoft.com/fr/blogue?categorie=sharepoint
|3

4. SESSION
Plan
A Requirements definition
1 - Define requirements
2 - Prioritize requirements
B Functional analysis
1 - Prerequisite
2 – 9 steps method
1.
Visualize the requirement
2.
Describe information
3.
Define relationships between data types
4.
Effectively storing information
5.
Determine the data flow directions
6.
Define data access point
7.
Define criteria for data recovery
8.
Define relational behaviors
9.
Define the information display
SharePoint Functionnal Analysis | 4

5. Part A
Requirements definition
Focus first on the ''What''?
“The value of an idea lies in the using of it.”
- Thomas A. Edison
SharePoint Functionnal Analysis | 5

6. 1
Define requirements
Do you know the difference between?
Business analyst
Understand business process
Read documentation if exists
And
Functional analyst
Understand SharePoint mechanisms
Knows possibilities with SharePoint
and transcribe them to functional
questions.
Identify super users or product
owners
Link between IT and business
Identify actual problems on process
or current solution
Product owner(s) best friend
Animate workshops
SharePoint Functionnal Analysis | 6

7. 1
Define requirements
By writing a backlog
Very first document
Identify what will be done in your project
Don’t neglect it
Used with agile methodologies
Sprintable and releasable (ex SCRUM)
Prioritized
Flexible
Requirements as stories
• Independent analysis on each
This document can be
A simple flat list
• Avoid TFS…
A map (?!?)
SharePoint Functionnal Analysis | 7

8. 1
Define requirements – Tools & Techniques
User Story Mapping
Definition
Organize and prioritize user stories in a backlog(*)
make visible the workflow or value chain
show the relationships of larger stories to their child
stories
help confirm the completeness of your backlog
provide a useful context for prioritization
plan releases in complete and valuable slices of
functionality.
Workshops (maximum 4 peoples)
Identity product owners per functional domains
Tools
• Coloured post-it and whiteboard
• Electronic format (SpecLog $)
SharePoint Functionnal Analysis | 8
*http://www.agileproductdesign.com

9. 1
Define requirements – Tools & Techniques
User Story Mapping
Concept
Impacts
Business goals
Why you do it?
Is there any constraints (IT,
functional, human..) on?
Actors/Profiles
Who will use it?
Activities
User stories
User workflow
What are their responsibilities on it?
What are their tasks within those
responsibilities?
SharePoint Functionnal Analysis | 9

10. 1
Define requirements – Tools & Techniques
User Story Mapping
Example
Improve employee
performance
Improve collaboration
Web accessibility
standards required
External access required
Big amount of data
Abstract profile
IT Department
Lambda user
Critical information
Novice with IT
IT Director
Share IT projects
Manage user requests
Submit requests
Search for information
Add a project
Process an IT equipment
request
See available IT equipment
Search corporative
documents
Search for a project
Add an item to IT
equipment catalog
Ask for an IT equipment
Information workflow
SharePoint Functionnal Analysis | 10

11. 1
Define requirements – Tools & Techniques
User Story Mapping
Example in real life
PS: Not mandatory to use a full wall 
SharePoint Functionnal Analysis | 11

12. 1
Define requirements – Tools & Techniques
User Story Mapping
Summary
 Live in a dream, don’t talk about SharePoint capabilities
Everything is possible here !
 Focus on roles and responsabilites
Who can do what in the system? This, is governance.
 Focus on requirements, not solutions
No more: « I want a search engine » or « I want a SharePoint list with five columns »
 Reveal information flows
That they will help you in the future to design your information architecture
 Super effective but sometimes hard to assimilate
Practice, practice and practice. Dont be afraid to try. All you need is listening and rigor.
SharePoint Functionnal Analysis | 12

13. 1
Define requirements – Tools & Techniques
Keep/Don’t keep
Definition
Identify what users like or don’t like in their
actual system or process
particularly suitable for a system
upgrade/revision project
result as impacts in your map (all levels)
Overall design
Reservation
system
User alerts
Not intuitive
Tools
pencils and whiteboard
post-it
focus groups by functional domain
Source: http://innovationgames.com
SharePoint Functionnal Analysis | 13

14. 1
Define requirements – Tools & Techniques
Speed boat
Definition
Identify what slows down user efficiency
Most problems lie deeper
Helps you to identify impact priorities
Ugly design
Tools
pencils and whiteboard
post-it
focus groups by functional domain
Not user friendly
Low performance
Source: http://innovationgames.com
SharePoint Functionnal Analysis | 14

15. 2
Prioritize requirements
Why prioritize?
You have to start with something
« I want it all » is not a valid response
Agile development guideline
First deliver features that give you the most
value
Source: http://innovationgames.com
SharePoint Functionnal Analysis | 15

16. 2
Prioritize requirements – Tools & Techniques
Buy a feature
Definition
Distribute your fake money on available
requirements
Identify priorities
Tools
fake money
product backlog
timebox
Source: http://innovationgames.com
SharePoint Functionnal Analysis | 16

17. 5
Prioritize requirements – Tools & Techniques
Summary
Prioritized business requirements list (MoSCoW)
Priority
User Story
Priority 0 – Must have
Add a project
Search a project
Search corporative documents
Priority 1 – Should have
Process an IT equipment process
See available IT equipment
Ask for an IT equipment
Priority 2 – Nice to have
Add an item to IT equipment catalog
SharePoint Functionnal Analysis | 17

18. Part B
Functional analysis
Focus next on the ‘How''?
“If you can't explain it simply, you don't understand it well enough.”
- Albert Einstein
SharePoint Functionnal Analysis | 18

19. B
Functional analysis
With SharePoint
Methodology
1
9 simple steps
2
3
4
Applies on a single story
5
6
7
9
8
Based on functional questions
SharePoint OOTB oriented
Building little autonomous subsystem with its own
functional analysis
All steps are not mandatory
Depends on your user story
• « Read » oriented VS « Write » oriented
SharePoint Functionnal Analysis | 19

20. B
Functional analysis
With SharePoint
Top SharePoint analysis facts
1 Analy…what??
SharePoint is like Legos®, you can do anything, for better for worse.
It’s up to you to choose the right brick for the right use
2 The SharePoint trap: when the means
condition the needs
Tell me what SharePoint can do, I will tell you what you need…
3 Solutions are not close enough to users day
to day needs
IT department is not often the best resource to determine whole
user requirements…
SharePoint Functionnal Analysis | 20

21. B
Methodology summary
Your functional analysis with SharePoint
1 Visualize the requirement
2 Describe information
3 Define relationships between data types
4 Effectively storing information
5 Determine the data flow directions
6 Define data access point
7 Define criteria for data recovery
8 Define relational behaviors
9 Define the information display
SharePoint Functionnal Analysis | 21

22. 0
Prerequisite
How to access data in SharePoint ?
Structured Query Language
Benefits
VS
Search language
Benefits
 Represent the SharePoint database
reality at the moment of the query.
 No need to know the field names in
which to look for.
 Retrieves linked items quite easily.
 Easy query building
Disadvantages
 Requires defining each field involved
in the query.
Suitable for
 Access to targeted metadata
 Access to content subject to
continuous changes
Disadvantages
 Represents the search index reality
and not the SharePoint content
database one.
Suitable for
 Keywords based search in "Free
Text" mode
 Access to relatively static content.
SharePoint Functionnal Analysis | 22

23. 1
Visualizing the requirement
What does the requirement look like?
Wireframe(s)
SharePoint Functionnal Analysis | 23

24. 2
Describe information
What are the information types present in the
requirement?
Static or dynamic information?
Reusability concerns
Types hierarchy?
Subtypes, specializations
Metadata?
Visible and hidden
SharePoint Functionnal Analysis | 24

25. 2
Describe information
With SharePoint
Content Types and Columns
Pr oject Member
Name
Shar ePoint
Cont ext
B usines
Cont ext
Commer cia l Pr oject
Inter na l Pr oject
Tit le
Dat e
Tit le
Volunteer Pr oject
Nature of
information
(Root types)
Document
Tit le
Subtypes
Pr oject
Item
Metadata
Pr oject Document
Typ e
Tit le
Type
SharePoint Functionnal Analysis | 25

26. 3
Define relationships between data types
What are the relationships between these data
items?
Relationships possibilities
One to one
1
1
1
Pr oject
1
Pr oject Checklist
One to many
0
1
N
Pr oject
N
Pr oject Document
Many to many
Pr oject
1
1
N
N
Pr oject Member
SharePoint Functionnal Analysis | 26

27. 3
Define relationships between data types
With SharePoint
Possibilities
Lookup Fields



Managed Metadata



Documents Sets


Folders


SharePoint Functionnal Analysis | 27

28. 4
Effectively storing information
How should data be stored within a requirement?
Data distribution criteria
Volume
• What is the amount of data?
Information security
• Who need to access these data?
Business context
• Does the structure have to follow a
business hierarchy?
SharePoint Functionnal Analysis | 28

29. 4
Effectively storing information
With SharePoint
htt p : / / colla bor a tion
Example
 Each type has its own library or list
Web applications
Sites collections
/
 Internal projects have their own permission
level
/ p r oject management
Cont ent t yp es
Sites
Commer cia l p r oject
/ commer cia l p r oject s
Volunteer p r oject
Lists and libraries
/ volunteer p r ojects
/ inter nal p r ojects
List items
Inter na l p r oject
/ p r oject documents
Pr oject d ocument
/ p r oject member s
Pr oject member
SharePoint Functionnal Analysis | 29

30. 5
Determining the data flow directions
Within my SharePoint data structure, how does the
data flow?
Output flow (data read)
The system displays information to the user
Input flow (data write)
Users add or edit data through the system
components
SharePoint Functionnal Analysis | 30

31. 5
Determining the data flow directions
With SharePoint
3 cases
htt p : / / intr anet
Case #1
/ sites/ p r ojects
 Storage in a SharePoint site.
/
Rea ding str ea m
Wr it ing and up d at e
str eam
 Access from the same site.
/ p r oject - management . asp x
List View Web Part
Content Query Web Part
Search Core Results Web Part
 
 
 
RSS Viewer
 
Content Search Web Part
 
/ commer cia l p r oject s
/ volunteer p r ojects
/ inter nal p r ojects
/ p r oject documents
/ p r oject member s
SharePoint Functionnal Analysis | 31

32. 5
Determining the data flow directions
With SharePoint
3 cases
htt p : / / intr anet
Case #2
/ sites/ p r ojects
 Storage in a SharePoint site.
 Access from another site in
the same site collection.
List View Web Part
Content Query Web Part
Search Core Results Web Part
RSS Viewer
Content Search Web Part
 
 
 
 
 
/
/ r ep or ts
/ commer cia l p r oject s
/ p r oject - management . asp x
/ volunteer p r ojects
/ inter nal p r ojects
/ p r oject documents
/ p r oject member s
SharePoint Functionnal Analysis | 32

33. 5
Determining the data flow directions
With SharePoint
3 cases
htt p : / / intr anet
Case #3
 Storage in a SharePoint site.
 Access from another site in a
different site collection.
/ sites/ p r ojects
/
/ sites/ p ublishing
/
/ p r oject - management . asp x
Search Core Results Web Part
 
 
 
/ commer cia l p r oject s
RSS Viewer
 
/ p r oject member s
Content Search Web Part
 
List View Web Part
Content Query Web Part
/ volunteer p r ojects
/ inter nal p r ojects
/ p r oject documents
SharePoint Functionnal Analysis | 33

34. 5
Determining the data flow directions
With SharePoint
Components
SharePoint 2007
SharePoint 2010
SharePoint 2013
Maximum range
Language used
ListView Web Part
Lists & Libraries
CAML
Content Query Web Part
Site collection
CAML
Search Core Results Web Part
Web Application
KQL
RSS Viewer
Site collection
-
Web Application
KQL
Lists & Libraries
CAML
Content Search
Web Part
ListView Web Part
SharePoint Functionnal Analysis | 34

35. 6
Define data access point
According to the data storage distribution and flow,
where are the data access points and what types
are exposed?
Raw data
Plain text not related to any specific type
• Ex: A welcome text
Data aggregation
Compilation of data from different data
sources
• Ex: Dashboards
Typed information
Single Item metadata view
Visualization of data corresponding to a
specific type
• Ex: A project sheet
SharePoint Functionnal Analysis | 35

36. 6
Define data access point
With SharePoint
htt p : / / intr anet
/ sites/ p r ojects
Raw data
/
Wiki Pages
Data aggregation
/ p r oject - management . asp x
Web Parts Pages
Typed information
List Forms
Publishing Pages
/ commer cia l p r oject s
/ volunteer p r ojects
/ inter nal p r ojects
/ p r oject documents
/ p r oject member s
SharePoint Functionnal Analysis | 36

37. 6
Define data access point
With SharePoint
Typed information
List Forms
Pr oject
Item
Tit le
Tit le
Dat e
Descr ip t ion
SharePoint Functionnal Analysis | 37

38. 6
Define data access point
With SharePoint
Typed information
Publishing page
Page
Tit le
Pr oject sheet
Tit le
Document
Tit le
SharePoint Functionnal Analysis | 38

39. 7
Define the conditions for information recovery
Under which conditions should information should
appear in the page?
Are the recovered items have to correspond to reality at time T in
SharePoint?
Is there a sort needed on the elements?
Are there any hierarchical constraints between elements?
Are there any relationships between entities?
Are these items must be targeted to a specific audience?
Are there multilingual constraints?
Must queries be reused?
Are there conditional constraints on queries?
What is the Information life cycle?
SharePoint Functionnal Analysis | 39

40. 8
Define relational behaviors
What are the relational constraints on the
information?
Notions of filtering and connections in
response to actions
Ex: An user select an item in a list  an
other value is selected in a other
component.
Ex: Language on the page has changed
SharePoint Functionnal Analysis | 40

41. 8
Define relational behaviors
What are the relational constraints on the
information?
Member s and documents
by p r oject
Pr oject filter
SharePoint Functionnal Analysis | 41

42. 9
Define the information display
How is information displayed?
What are the display details
Metadata
Style
• Colours, fonts, etc…
Should they appear grouped or alone
Mixed types inside one container with visual
distinction
SharePoint Functionnal Analysis | 42

43. 9
Define the information display
With SharePoint
Display management
XSL
Dynamic elements
Static elements
Welcome text
 Limitations due to
compiler version
 Standard before
SharePoint 2013 (but
still present)
Title
Fir st Name and
Last Name
Title
Pr oject member s
JavaScript/HTML
 Display templates
with result sources
(search)
Date and
descr ip tion
Author and date
Commer cial p r ojects, volunteer
p r ojects, inter nal p r ojects
 More powerfull but
more complex
Pr oject documents
 Standard with 2013
SharePoint Functionnal Analysis | 43

44. B
Methodology summary
Your functional analysis with SharePoint
1
What does the requirement look like?
2
What are the information types?
3
What are the relationships?
4
Where data is stored?
5
What are the data flows?
6
What are the page types?
7
What are the display constraints?
8
What are the behaviors on pages?
9
How information are displayed?
SharePoint Functionnal Analysis | 44

45. B
Methodology summary
Tools
If you
We
Want to
Recommend to you
Draw pretty schemas
Microsoft Visio
Define your backlog as a map
Speclog http://www.speclog.net/
Define your backlog as a list
Excel, TFS
Draw wireframes
Balsamiq http://balsamiq.com/
Brainstorm about taxonomy
Xmind http://www.xmind.net/
Get more details about this
method
GSoft website www.gsoft.com
(detailed ebook coming soon!)
SharePoint Functionnal Analysis | 45

46. Conclusion
Merci!
Templates & Examples on SkyDrive
SharePoint Functionnal Analysis | 46

47. Remember to fill out your evaluation forms to win some great prizes!
&
Join us for SharePint today!
Date & Time:
Location:
Address:
Parking:
Site:
Nov 23rd, 2013 @6:00 pm
The Observatory Pub,
Algonquin Student’s Association
A-170 on Algonquin Campus
No need to move your car!*
http://www.algonquinsa.com/ob.aspx
*Please drive responsibly! We are happy to call you a cab 