Once you have defined your stakeholders and received SharePoint Server 2007 education, you can move on to gathering requirements. One of the most common mistakes made with SharePoint Server 2007 implementations is the lack of clear requirements. We have seen many instances where nobody asked the end-users what they wanted! Gathering your requirements doesn’t have to be difficult; it just needs to be done. There are entire engineering sciences around requirements engineering (RE), but it isn’t necessary for most SharePoint Server 2007 installations. Many of the RE processes were designed for building spacecraft, airplanes, skyscrapers, and other very complex systems. Therefore, the following processes are derived from RE but show only the steps required for SharePoint Server 2007.
It can be very difficult to differentiate between a user’s need and a user’s want. You should attempt to draw a line and allow only legitimate requirements into your design. What is legitimate? If a user’s wants don’t incur exorbitant expense or slippage to the schedule, including those wants that will help your users adopt the product. However, human emotions often enter the picture and those with political influence often get their wants, even when they are expensive or cause delays. One of the keys to success when implementing SharePoint Server 2007 is your understanding of the political and cultural change it brings. Introduction of SharePoint Server 2007 affects the very way your users do their jobs, changes the power structure and communication paths in your organization, and may even change the original requirements your system was built for. Try to give stakeholders examples when using the following techniques for gathering requirements.
Merriam Webster defines elicitation as "1: to draw forth or bring out; 2: to call forth or draw out." Because not every stakeholder will communicate requirements the same way, several different methods of gathering requirements are covered in this section. Many of the following techniques were derived from the International Council of Systems Engineering document "Requirements Engineering: A Roadmap." They have been changed to meet the needs of SharePoint Server 2007, but the basic best practices are followed. Rarely will one technique be sufficient. A best practice is to use a combination of the following techniques:
Traditional elicitation techniques are the most common when building SharePoint Server 2007 solutions. The strengths of traditional techniques are the familiarity in the format, the ability to gather specific information about a problem, and a general forum to collect information. Traditional elicitation techniques include questionnaires, surveys, and discussion groups. Of course, you can use SharePoint Server 2007 to collect the surveys and information in discussion groups! Interviews can also be very useful when defining requirements for SharePoint Server 2007, but they are time consuming. Try to keep interviews to a minimum, and only with stakeholders such as managers, power users, and executives.
Existing systems should always be the starting point for a new system. While these are often overlooked, existing systems usually provide the basic functionality required in a new system. Additionally, the pain points of the legacy system should be addressed in the design of your SharePoint Server 2007 installation, if possible.
Pain points are essentially requirements unfulfilled by a current system, or problems within the business itself. Many of your stakeholders are uncomfortable discussing business and technical requirements but are willing to discuss pain points. They are essentially one in the same and allow you to fill in the gaps of your design. A design that isn’t accepted by the stakeholders is doomed to failure.
Group elicitation techniques include brainstorming sessions, focus groups, and consensus building workshops. Group elicitation is an effective requirements gathering technique because it allows stakeholders to bounce ideas off of one another. Many times, conversation about requirements prompts others to think of additional requirements that might otherwise have been overlooked.
Prototyping should almost always be used when defining SharePoint Server 2007 requirements. Prototyping helps clarify requirements when there is doubt about functionality, such as incoming e-mail, records management, or search services. While this prototype can be very elaborate, it doesn’t have to be. You could use the same system for gathering requirements as you would for prototyping. This simplifies and integrates both processes. Additionally, prototyping allows users to find new ways SharePoint Server 2007 can address their pain points and allow real-world testing during group requirements sessions. Be sure to get feedback from the stakeholders during these early prototype sessions.
Contextual requirements gathering includes the observation of the stakeholders and customers on the current system, or in their daily non-computerized business processes. Remember that you are not only addressing the weaknesses in the previous computerized system, you are also addressing their needs to automate processes that are currently manually performed. Contextual requirements gathering can be as simple as following and documenting a stakeholder’s job duties or as extreme as hiring psychologists to analyze and recommend better ways of doing business. The depth of your requirements analysis depends on the scope and complexity of your SharePoint Server 2007 installation, so don’t overcomplicate it.
Note
When leveraging the strengths of both the spiral and waterfall process models, you can build a prototype SharePoint Server 2007 installation in the very beginning. Using this system for your requirements gathering and other project activities gives the stakeholders an opportunity to see the system in action, and allows for "real-time" elicitation of requirements. You should use much of the native functionality in this prototype system, including Wikis, blogs, document libraries, tasks lists, contact lists, and search. If you plan on integrating Project Server 2007 with SharePoint Server 2007, this is also a perfect time to showcase the capabilities of that product.
As you gather requirements, model them in your prototype system. This allows you to see conflicts in requirements and provide real-time validation of requirements. Your model should include much of the advertised functionality of SharePoint Server 2007, allowing your stakeholders to select capabilities for their processes. A good example of a modeled requirement is search and indexing. You could crawl several file shares and Web servers to demonstrate the functionality of SharePoint Server 2007 Search. This demonstration could include search scopes, stemming, managed properties, and federated search results. Whatever the functionality you model, be sure it addresses the legacy system’s basic requirements, if applicable, and add new requirements as they are defined. The model should clearly address business requirements and map those to functional requirements. You could even identify the functional requirements that are met as the label for objects such as sites, document libraries, Wikis, blogs, portals, and searches.
Note
When defining your functional requirements, you can simply number them as 1, 2, 3, and so on. For example, if you had the requirement for a portal, you could assign the number 1 to the requirement. If you had the requirement for a Wiki, you could assign the number 2. You can then simply reference these requirements by a simple numbering scheme. If you have a complex SharePoint Server 2007 implementation, you can also provide minor requirements, as is usually the case with a Portal Site Directory. Using this example, if the portal’s requirement identification was 1, then the Portal Site Directory’s identification number might be 1.1.
Using requirements labels in your prototype clarifies where requirements are met. Figure 3-6 shows an example of functional requirements labeling for a portal site that contains minor requirements of a site directory, Wiki library, and blog site.
If you have many stakeholders, or stakeholders from multiple organizations, consensus on SharePoint Server 2007 requirements may be the hardest part of your design. First, you should create a communication plan so all stakeholders are updated with the design process. This can be as simple as an e-mail list, but SharePoint Server 2007 functionality such as discussion lists and blogs usually work much better than e-mail alone.
One idea that has served us well in the past is getting the stakeholders to agree on the problem before getting them to agree on the requirements. If your stakeholders cannot agree on why the solution is being installed, it is very unlikely they will agree on how it is to be installed. More fundamentally, your stakeholders must agree there is a problem. You must realize by now that stakeholders have many goals for your project, and some may conflict. A prime example of this is authentication mechanisms for your Web applications. One group might ask you for Kerberos authentication, while another wants two-factor smart card authentication. While you can accomplish this via multiple URLs, generally you cannot accomplish this on a single URL. In this example, you must work with both parties and identify some common ground, and maybe even a compromise. Many of your requirements must be proved to be technically feasible through requirements modeling, while others are more social in nature and can be validated only through actual use.
Requirements creep, also known as scope creep, occurs when the requirements never stop coming in. If you had an initial design, but stakeholders continued to add requirements to the design, that is requirements creep. If you use the spiral process model, it is easy to deal with continuing requirements because they are included in the next version of the project. This next version doesn’t have to coincide with the product version of SharePoint Server 2007: You could have two versions of your specific implementation while still being in SharePoint Server 2007! Requirements creep is usually thought of as a bad thing, but continuing requirements usually mean you have a project that has meaning and value in your organization. There are two groups that align with the scope creep—those who want your project to succeed and those who do not. The first are your allies, and the last thing you want to do is alienate them from your project. So the best way to deal with this type of requirements creep is to define functional requirements and don’t deviate throughout the project. When new requirements are added, simply refer those to the next version in your product life cycle, i.e., version two. Those who are against your project will also continue to add requirements, hoping to doom your project to failure. While you welcome those comments to help the stability and functionality of your SharePoint Server 2007 implementation, you should provide the functional requirements for the project and use the executive stakeholder support you have already gained to address your opponents’ issues in the next version.
Another way to deal with requirements creep is to develop a vision statement that defines the functional requirements for your project. In a perfect world, you should get all stakeholders to sign this vision statement with the understanding that additional requirements must be added in the next version of the project. Be careful, however, because some of your peers may try to make original requirements look like new ones, to reduce their risk or gain extra budget to meet their political goals. Likewise, additional requirements sometimes must be added to the current version for success. As your project progresses, always reference your functional requirements in design documents. If a design point is not backed by a functional requirement, you might be experiencing requirements creep.