Once you've established what the business requires, translate that into what SharePoint can do to fulfil those requirements.
- [Instructor] After establishing the user and business requirement, you have enough information to start to flesh out the functional and non-functional requirements for your design. Functional requirements map to what SharePoint functions relate to the user and business requirements. So let's take a step back for a second, and take a quick look at what SharePoint capabilities relate to our current requirements. Remember that in most implementations, you do not need to enable every single service application that SharePoint has available.
Part of your job as a designer, is you need to discern what is necessary and what is not. Every Service Application requires resources. In order to conserve resources, you need to only use the applications that you require. So in this scenario the kind of Service Applications that we will require are: Search because inevitably the users in this environment will need to be able to search for the documents that they are using, working on, or need to find, particularly if you're a New Hire, or if you're looking for information from Human Resources.
In terms of Managed Metadata the sales department wants to have their own terms to use in terms of metadata for their documents and files, and in order to be able to search against those terms. They are going to need Managed Metadata. In addition, the entire organization as a whole may want to create their own terms. User Profile Service. This allows synchronization with Active Directory for user profile information. In addition, it enables the My Sites that the users want so much.
They want to have their own site collections, each individual gets one, and they want to be able to use that serve as news feeds, to serve as social tools, like news feeds. Business Connectivity allows SharePoint to access external databases. And it could allow users to add, delete, modify data, if configured to do so. In this case, we do not necessarily need Business Connectivity right now because most of the data is going to be stored in SharePoint.
But in the future it is possible that we may need to put access to manufacturing's databases, and their vendor and inventory information in SharePoint. Since manufacturing is not necessarily going to want to let go of the databases they have, it may be a better idea to use Business Connectivity to access it as an external resource. In order to be able to use authentication and pass through of authentication for SharePoint to the external resource for business connectivity, we should also enable Secure Store, which manages authentication for SharePoint.
We might also want to look at Office Online Server, in order to be able to view Office files in the browser. Also part of the functional requirements for a SharePoint implementation, would be the logical locations for content, such as as Sites, Site Collections, and Web Applications. Web Applications contain site collections. They're what define the URL address for the site collections contained within, so they define the namespace. They're also a security boundary because they're an IIS website essentially on the back-end.
They can define the SSL Certificate and other security features. In addition, you can apply separate service application instances to different web applications. Site Collections are a collection of sites that share the same users, security, settings, and features, and they're a user boundary. So if you have departments or business units that essentially have the same needs in terms of URL addressing or security, and the only real difference is user access, settings and features.
You may want to separate the department or business unit's resources into different site collections in the same web application. And then finally you have separate sites. So if you have departments or users or groups that need to have their own separate address to go to for their resources, but otherwise can use the same settings as a site collection, you simply place a subsite for them in one site collection. These Sites are what contain lists and libraries, which help define the team that needs to use a site, is the team that needs to use certain lists and libraries.
For example, here are the Functional Requirements based on our user and business interviews. For Service Applications, we're going to need user profile service, particularly for AD Sync, active directiory synchronization, of the user profile information and the MySite. We're going to need Managed Metadata, both for the company at large and for sales on its own, and we're going to need Search. For Web Applications, because Accounting and Human Resources are going to have data that they need to work with, but it needs to be very secure.
They're going to need their own Web Applications for that information. Sales is going to need its own Web Application so it can have its own Managed Metadata. We need a Web Application that is essentially a portal for the entire company, and then one for MySites. That this is going to host the MySites for the users. In terms of separate Site collections, inside the Portal itself, the main company Web Application, we're going to need the main Portal website for everyone to use as soon as they come in, and Marketing could have its own Site collection because it doesn't have any of its own specific security concerns.
At the Site level, all users are going to need to use a Shared Calendar in the Portal Site collection. Marketing is going to need their Calendar for events in their Site Collection. All users will need Expense Reports and Vacation Requests in the Portal, and they're going to need access to the Portal for HR surveys. Marketing, within their Site, will need document and picture libraries with versioning, approval, and check in enabled. Sales is going to need a Customer list for their Site. HR will have an employee list, as well as a Manual Library, and a New Hire library on the Portal, and then finally we're going to need to install Office Online Server on a separate server on the network, in order to serve as the capability of opening Office files within the browser.
So this is an example of some of the functional requirements you might need when you're planning for implementing SharePoint. It may not be quite as simple as this. Your design may even be more simple. Something to keep in mind when looking at Functional Requirements for an implementation, is items at this level may change several times during the evaluation process. When you're piloting and exploring with the user's beta testing these requirements, don't be surprised if they change.
- What is SharePoint?
- Establishing SharePoint hardware and software requirements
- Collecting user and business requirements
- Designing the SharePoint architecture
- Planning for governance