David DeWinter

This is part one of a series of two blog entries about non-functional requirements using PASS MADE.

By now we have probably all heard about something known as “non-functional” requirements. But sometimes in the projects we’ve had at Neumont, they’ve been fudged a bit because no one (in my experience, at least) took the time to thoroughly explain what categories of requirements should be covered. This blog will look at some of the requirements categories that can be included, depending on the constraints of the business.

Recently I’ve come across an acronym called PASS MADE; it looks like this:

Performance
Availability
Security
Scalability
Maintainability
Accessibility
Deployability
Extensibility

We’ll have a brief look at each of these and then look at a few other possibilities for requirements. Remember, though, that all of these potential requirements should be evaluated in a cost vs. potential benefits manner before including them in the specifications.

Performance requirements usually deal with a system’s response time, which is defined as the amount of time a user waits to receive a response after issuing some action. This is usually a more significant set of requirements on Web sites and enterprise applications than on Windows-desktop applications. Some of the major factors that affect response time include the following:

• Limited Bandwidth
• Server or network capacity
• Server traffic
• Application-processing constraints

Some of these factors are outside of your control, so the point is to reduce unnecessary overhead and performance bottlenecks as much as possible. You may also want to gauge how much time the application takes to respond using some automated tools. However, be careful not to mix up performance requirements with other operational requirements, such as availability and scalability.

Availability requirements deal with how often your application is online to do its specified work. In looking at availability, there is a bit of overlap with “Reliability” as well. Reliability is the capability of a component or service to perform its functions at a specific time or over a period of time. Essentially, availability = reliability + restore time (time required to bring a system back to normal after a failure).

In deciding whether to include availability requirements, evaluate how often customers need it online. What are the peak hours? Is time used for system backups acceptable? What is the schedule and budget? Remember, before you include a requirement, make sure it’s needed by the customer/client.

Sometimes, when availability requirements are not addressed, some of the following issues can result in a problematic solution for the end user:

• Inadequate testing
• Change management problems
• Lack of ongoing monitoring and analysis
• Operational errors
• Weak program code
• Interactions with external services or applications
• Different operating conditions (usage level changes, peak overloads)
• Hardware failures (disks, controllers, network devices, servers, power supplies, memory, CPU)
• Natural disasters

Obviously, you can’t account for all this, because some items are not under your control. However, identifying availability requirements from the get-go can help you avoid some of these problems down the road.

Security requirements are probably the most important requirements you’ll come across when developing a solution. The most important facet of developing these requirements is to understand what your application needs protection from. As a reminder, most security solutions are based on the following principles:

• Authentication – The process of identifying who someone is, using some form of credentials. In the .NET world, this is usually through Windows, Forms, Passport, or Custom authentication.
• Authorization – The process of identifying what resources someone has access to after being authenticated. For example, in the RevNet Portfolio project, the business rules demonstrate a variety of authorization constraints. For example, only a member of the Directors’ group can change the global access groups.
• Data Protection – The process of providing data confidentiality and integrity. Data needs to be secure both while in transit and while in storage. One method to accomplish this goal is to encrypt the data.
• Auditing – The process of monitoring and logging what goes on in a system that relates to security.

Some example requirements could include things like encouragement of strong password use, logon policies and auditing (passwords expire after a certain amount of time), intruder prevention processes like using a security question and email to offer change password services, ownership/responsibility for user accounts (suspending accounts that have abused the system), and encryption policies for data protection.

One acronym that Microsoft has coined for security is STRIDE, which stands for the following:

• Spoofing Identity – Includes anything done to compromise a trusted user’s authentication information, such as a username and password.
• Tampering with Data – Includes anything from ill-mannered modification of database data to defacement of the user interface. Another topic in this category is session hijacking.
• Repudiation – Involves users that deny that they have performed a certain action, and the other parties have no way of proving either case. This usually results from lax logging and auditing policies.
• Information Disclosure – Includes times when confidential information is exposed to individuals who should not have access to that information.
• Denial of Service – Includes directed attacks against a host or network to disallow other legitimate users from accessing the site. These kinds of attacks usually overload the host with too much traffic and can include multiple simultaneous attackers.
• Elevation of Privilege – Includes giving an unprivileged user privileges to compromise or destroy system data. Authorization is a very important mechanism for enforcing this.

For more thorough information about STRIDE, look here.

Finally, consider the business’s perspective in this. How sensitive is the data that the application will store? What is the effect if the data gets out to the wrong people? Also, consider how security policies can be improved even after deployment. You may want to consider a periodic security review that evaluates the risk of new threats on the system. Organizations will really have to remain vigilant in order to protect their data.

Scalability requirements involve the capability of a system to increase its capacity by upgrading system hardware and software. Scalability deals mostly with distributed/enterprise applications—standalone applications will not usually need to achieve much when it comes to scalability. Although implementation of these requirements come during the physical design and development phases, the requirements should be considered early because you need to be aware of what changes should be made to the current system’s hardware and/or that the software should be designed to fit for an increase of ____ (amount) over ____ (time). Also, keep in mind that trying to maximize performance may also contradict scalability; the two are not the same.

There are two buzzwords that you may’ve heard of before: scaling up and scaling out. Scaling up is the process of achieving scalability through the use of faster/better (and usually more expensive) hardware. One thing to keep in mind while scaling up is that there are limitations to how much you can improve. Also, it is problematic to spend money on having one computer support the operation because it enables the application to have a single point of failure.

Scaling out is the process of using many machines to work as one machine by increasing scalability through hardware improvements, decreasing dependency on one machine, and allows an application to stay up even if a server fails. When scaling out there are things to keep in mind, such as load-balancing and state management (for web sites). For example, you can’t use the HttpSessionState object (Session property of the Page class) to store state if you’re using multiple machines. Instead, you would have to use ASP.NET’s Server State or a DBMS (most likely SQL Server) to manage it. The application logic should not have to change depending on which server the code is running on. This is known as location transparency.

Next week we’ll look at the remaining four categories of requirements as well as some additional categories that deal with user and business requirements, not just operational requirements.

Adapted from: Randy Cornish, et. al, Analyzing Requirements and Defining .NET Solution Architectures (Exam 70-300). Indianapolis: Que Publishing, 2003.

This entry was posted on Saturday, October 21st, 2006 at 2:37 pm and is filed under Requirements Analysis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.