What is nonfunctional specification?
A statement of how a system must behave; it is a constraints upon the system’s behavior.
It is more common for business users to emphasize functional rather than nonfunctional elements, but failure to include the latter can have a catastrophic effect on your final solution.
Although users and stakeholders assume that a system will always be available, you must plan for maximizing availability or performance. In your logical design, elements such as scalability, performance, and security may have a major impact on whether you deploy a single farm or multiple farms for an organization.
The most common nonfunctional requirements focus on system capability, availability, performance, and so on. These may have a greater impact on physical design, but you usually only have one period of requirements gathering, so you must make sure that you get all of the information that you require.
Key areas of nonfunctional planning include:
Performance: - Ensure that your design identifies performance issues such as the number of users who access the environment at peak times.
Capacity: - Your design must provide sufficient capacity over an effective hardware management period, which is normally two years. This means that you have to specify systems that provide adequate storage for this period. In addition to the base systems, you must analyze the goals of the business to enable capacity for forecast growth. You must also be conversant with requirements that are specific to SharePoint, such as software boundaries, to ensure that data volumes do not exceed your logical architecture. For capacity planning for SQL Server, you may want to enlist expertise from a Database Administrator.
Scalability: - Your design must ensure potential for growth through scalability. This may involve scaling up, by upgrading the initial systems, or scaling out, with the addition of systems to share workloads. Your logical design should also provide options for extensibility through scaling. It is rare for an environment as rich and varied as the environment that SharePoint 2010 offers to remain static. You will often find that you must add or extend functionality such as social computing, BI, or Search in an organization.
Availability: - Users assume that systems will always be available for them to use, so you have to build this resilience into your plan. No system can guarantee 100 percent availability, so any service-level agreement (SLA) should establish the percentage of downtime that is acceptable for business continuity. This relates closely to availability solutions such as database clustering and network load balancing. However, your logical design must ensure adequate availability through the division of logical components across Web applications.
Security: - Security is an overarching goal, so your design may have to integrate with organization-wide standards. Secure authentication may also affect your logical design. You must ensure that you accommodate secure authentication requirements by identifying the division of site collections and sites.
Manageability: - If your deployment requires self-service provisioning, you must ensure that both administrative staff and delegated users can manage your solution.
Interoperability: - SharePoint 2010 provides a user environment that can visualize external data sources, for example, through out-of-the-box Web Parts. Your design must accommodate these requirements.
Business continuity: - As an extension to availability, you must address business continuity, or disaster recovery, options. This is often an organization-wide strategy, but you should review the SharePoint 2010 requirements.
There is no default priority for these nonfunctional requirements. You must prioritize each one based on the business requirements of your organization. When you have established the requirements for each one, review your results with the key stakeholders to establish the priority.
