Bridging the Gap Between Business Need and Technology Solution | |
Implementing Requirements Traceability and a Requirements Matrix | |
Business requirements are essentially a list of targeted accomplishments that are articulated in a way that can be understood by all of the stakeholders. To really enhance the project’s chances of success, it is nice to articulate these targeted accomplishments in a way that can be measured. The targeted accomplishments that make up the goals of the project are known as requirements, and it is a best practice to write down requirements, agree upon them, and then get them done.
When you consider the development of business requirements for any software product, the process is essentially the same. That process is outlined in this chapter. Therefore, you might be tempted to think that this chapter is not about Microsoft Office SharePoint Server 2007 at all and should not have appeared in this book. Nothing could be farther from the truth. While this chapter will not mention Office SharePoint Server 2007 very often, it is important to note that we believe this is one of the most important chapters in the book because, in the absence of well-articulated business requirements, your SharePoint Server 2007 implementation will lack purpose and direction. Stated another way, the development of business requirements is essential to your SharePoint Server 2007 implementation. Those requirements define the business environment into which SharePoint Server 2007 is deployed. Hence, the development of business requirements is a best practice.
Note
Few SharePoint Server 2007 best practices will be presented in this chapter because we feel that the entire chapter represents a single best practice for your SharePoint Server 2007 deployment—to develop well-articulated business requirements that are technology agnostic.
In this chapter, you will learn how to do the following:
Understand the relationship between business and technical requirements
Recognize the characteristics of good requirements
Use requirements to solve problems
Define requirements for your implementation
We will discuss what good requirements look like and how SharePoint Server 2007 can make the requirements management process more effective and efficient. We will also discuss mapping relevant requirements to SharePoint Server 2007 product functionality.
A requirement is a concise written description of a function or capability that a software solution must have in order to solve a specific business problem. The requirement is considered valid if it can be clearly and objectively measured, if it describes a single function or aspect of the desired solution, and if it is understandable by the project’s stakeholders.
The software development process must always start with one or more business requirements. If the software project does not address a clear business need, then it should be rejected. A business requirement is a simple description of how the organization is to be improved or enhanced by the new technology solution. Sample business requirements include:
Lower order-entry costs
Speed up product time-to-market
Improve communications with regional offices
Improve order-to-ship times
Expand into overseas markets
The project team must work with the business stakeholder to break the larger business requirements down into a set of simple and measurable functional requirements. Functional requirements are measurable descriptions of the new features or functions that must be developed in order to meet the needs of the business requirements. For instance, the business requirement to lower order-entry costs could yield the following requirements:
Projects are also bound by constraints or nonfunctional requirements. These are requirements that do not add functional value to the software being developed, but must be included in order to meet regulatory, cost, or quality requirements imposed on the organization as a whole. Examples of these constraints can include:
Adherence to corporate document management policies
Corporate security policies
Requirements to integrate with other technologies
Conformity with corporate enterprise architecture standards
Remember that, by definition, requirements must be objectively testable. Therefore, the testing requirements are written before the solution is designed or developed! This occurs to ensure that the requirements being handed to the technology stakeholders are valid before the development team begins working on a solution. Therefore, a test requirement must be written for each of the business, functional, and nonfunctional requirements that the technical team is being asked to develop. This provides a "meeting of the minds" between the various stakeholders even though they speak different professional languages. The agreement is that the technology stakeholders will provide a solution to the business requirements that will objectively meet the testing requirements articulated in the requirements document.
After the project stakeholders have all agreed on the validity of the requirements outlined previously, the technical team must determine how it will provide a solution that meets the test requirements. This leads to the creation of technical requirements or specifications. These requirements spell out precisely what technologies will be used and how they will adhere to best practices. The technical specifications are validated by whether they fulfill the test requirements and whether a development team is able to take them and begin work on a solution.
Concise and measurable written requirements are the foundation of a successful project. Requirements keep the project team together and focused on the business needs that are driving the project. They also provide the key to the project team’s ability to validate and test the solutions it develops and are the organizing principle for user manuals, installation instructions, and technical support plans. Even though they understand how important requirements are, project teams often record inadequate requirements or skip the process entirely. The reason requirements are often skipped is simple: They are very difficult to develop without a dependable and robust document management and collaboration tool. SharePoint Server 2007 is just such a tool.
How SharePoint Server 2007 Helps the Requirements Process
All project documents, including requirements, are just that—documents. SharePoint Server 2007 is an excellent tool for organizing and managing documents in the context of a collaborative team. So, a SharePoint Server 2007 Team Site is an excellent tool for coordinating the collaborative efforts of a project’s stakeholders. Project documents can be stored in a common library, and the stakeholders can be kept informed of changes by using alerts within SharePoint. Also, the requirements can be placed in a SharePoint Server 2007 list to make it easier to review, filter, and manage each individual requirement. Filtering can also be used to isolate the genealogy of a given requirement without having to visually search through a large and confusing table of information.
Figure 4-1 illustrates what a basic team site looks like with a few calendar entries. Figure 4-2 illustrates the Gantt view of a calendar, which allows a project manager to better manage tasks over a given timeline. Project documents, tasks, and workflows can be utilized to help manage a project within SharePoint Server 2007. Obviously, for more robust project management functionality, you’ll want to use Microsoft Office Project Server 2007.
SharePoint also takes document management and collaboration functions that were formerly contained within individual applications and delegates them down to the level of an operating system service. Thus, each application in an environment doesn’t need to provide its own document version control, workflow capabilities, e-mail integration, Web presentation, and other document management capabilities. These are now shared services provided across applications by SharePoint. This means that these features and functions do not need to be re-defined with each software application the organization purchases or develops. SharePoint provides these services as a given. The requirements process can focus on the actual business need that the project seeks to address rather than getting bogged down in the "nuts-and-bolts" services in the operating system.