An effective first step for designing a search
solution is to identify stakeholders, business unit representatives,
and sponsors who are responsible for providing guidance, resources, and
funding for the project. Organize some detailed questions for them and
then conduct interviews to facilitate the elicitation of business
requirements.
Ask the business representatives the following:
What types of content will be searched?
What is the content used for?
Where is the content stored?
How much effort has been spent in cataloging content?
What types of content can search help uncover?
What are some example search queries that you might run?
Business Analysis
It is important to maintain a holistic mindset to
requirements gathering because certain revealed information can ignite
and expand subsequent conversations. You will discover how search
impacts individuals and teams, as well as the enterprise as a whole.
This approach results in a more solid foundation for the initial
definition of search, which improves the search deliverables and limits
future rework. The consequence to poor planning with search is that
valuable information may be missed or not presented in an intuitive and
useful way.
To promote good planning, interview business
representatives and conduct focus group activities. The goal of
eliciting feedback is to gather as much useful information about
business needs as possible. This process should include free and open
discussions and not be constrained by assumptions about the scope of
the search implementation, the limitations of the software, or any
other reason why a particular idea may or may not be implemented. The
requirements analysis is not a scope definition exercise, and you are
not obligating the business to any particular feature or capability.
Instead, your goal is to completely understand what search capabilities
the business needs and wants. During the pursuit of this information,
it is acceptable and encouraged to explore the users’ day-to-day
processes and ask questions about how they do their jobs and what ways
they think search could improve their jobs or somebody else’s.
While gathering requirements, it is important to
keep in mind that useful information can be contained in various forms,
both structured and unstructured. The “right” answer to a question
might exist in a document, a discussion thread, or a wiki. Business
users expect a search engine to interrogate all possible sources in the
pursuit of the answer. By understanding what the sources of information
are and how to retrieve the right answers from the various content
formats, you can effectively define the functional requirements of
SharePoint search.
Creating a Business Requirements Document
The interviews and discussions can produce a
plethora of information about search. You will need to figure out a way
to consistently extrapolate and organize
the requirements, feedback, ideas, and explanations that are provided.
So before beginning the interviewing process, invest time in developing
document templates and surveys for collecting and organizing the search
requirements from the various facets of the organization. A benefit to
documenting consistently across groups is that you can more easily
merge the requirements from the disparate groups into a single document
at a later time, grouping related information. An easy way to get
started with building a search requirements document template is to add
a section that identifies the types of content that business users
might need to search for. This is a fundamental inquiry that will apply
to everybody you meet with about search. As an example, Table 1 lists various types of content and provides a column where you can indicate whether or not a need exists.
Table 1. Example of Information to Gather to Define Search Requirements
| Searching for ... | ... in This Location | Need Exists? (Y/N) | Description of Content |
|---|
| Documents | SharePoint sites | | |
| Fileshares | | |
| Exchange public folders | | |
| Lotus Notes databases | | |
| Local hard drives (C:\) | | |
| Web Content | SharePoint sites | | |
| Internal Web sites | | |
| Internet Web sites | | |
| SharePoint List Items
| SharePoint sites | | |
| Discussions | SharePoint sites | | |
| | Exchange Public Folders | | |
| | Notes Databases | | |
| People | SharePoint Profile Database | | |
| | Active Directory | | |
| | Exchange Address Book | | |
| | LDAP directory | | |
| | HR System | | |
| Structured Business Data | | | |
| ERP Database | | |
| CRM Database | | |
| | Project Management Database | | |
| | HR Management Database | | |
| | Learning Management Database | | |
| | Time and Billing Database | | |
| | Issue Tracking Database | | |
| | Accounting Database | | |
| | Custom Database | | |
The business capabilities that the SharePoint search
features provide can only realize maximum potential if the proper
analysis and planning efforts have been invested into the other facets
of SharePoint. To leverage metadata properties most effectively, the
business should have a common nomenclature and utilize consistent
Column naming throughout its SharePoint portals and sites. These
properties, in turn, can be configured as managed properties and then
can be used within search scopes, which can greatly enhance the
end-user experience.
