David DeWinter

Since the new year I’ve been working on a project that attempts to solve the following problem:

How do I keep my generated entity classes in sync with the current database schema using LINQ to SQL?

For some people, this question is moot. It’s easy enough to utilize the current “resync” mechanism in LINQ to SQL by deleting all the entity classes and functions (the LINQ to SQL term for sprocs and UDFs) on the designer surface and then redragging and dropping the tables and functions of interest, thus updating the entity classes by regenerating from scratch. However, for others, this solution is not good enough for a few reasons:

(more…)

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

So after that extended week-long break, I think it’s time we have a look at the rest of the non-functional requirements in PASS MADE, and also some others that don’t appear in the acronym.

As a quick refresher, PASS MADE stands for…
Performance
Availability
Security
Scalability
Maintainability
Accessibility
Deployability
Extensibility

During this week we’ll look at the requirements between Maintainability and Extensibility as well as briefly mention a few others.
Maintainability requirements describe how easily a software system can be modified to correct bugs, add new functionality desired by a client, or to improve performance. In a nutshell, it is a measure of how easy it is to keep the solution functioning correctly. The requirements are usually characterized with some sort of number to describe how often or to what extent the system will be serviced or unavailable. Here are some examples of maintainability requirements:

• Maintenance work on the system will be limited to ten days throughout the year, and each of those work days will not exceed eight hours.
• Minor functionality updates to the system will take no more than five days.
• Any period of unexpected downtime will not exceed twenty minutes.

When looking at these requirements, it outlines the main objectives of maintainability requirements:

• Minimize maintenance costs and allow for programmers to work on other projects instead of doing maintenance work.
• Ensure that minor updates to the application don’t consume your resources.
• Ensure that defects and errors in your application don’t take long to correct.

Areas of concern with maintainability requirements usually revolve around the following areas:

• Breadth of the Application - Across how many locations will the solution be installed? If it’s installed in only one location, it (obviously) makes maintenance work a lot easier than it would be with a multi-site installation.
• Method of Distribution - If you are installing the solution across multiple sites, how are you going to make updates to your software universal? In essence, how are you going to keep your software properly maintained?
• Maintenance Expectations - It is important to discuss the maintenance work the client expects and come to a solution before writing anything in a formal document.
• Impact of Third-Party Agreements - If you are using third-party components to develop your application, you need to put a process in place to account for updates and bug fixes.

To summarize, maintainability requirements should focus on quantitative answers to problems such as modifications to improve functionality, corrections of minor defects (along with documentation updates). The areas these problems should revolve around include the time and expense needed to repair defects, account for system downtime, and staff locations with support teams.

Accessibility requirements focus on making your software as flexible as possible to accommodate for a wide range of users’ needs with regard to disabilities and impedances that would make their experience of your software less fruitful.

Before you get started with accessibility requirements, it is important to consider your user base. Talk with your client about how many of the potential users of this software will need assistive support from the software. Usually the potential users of your software are asked to fill out a needs assessment document, which outlines accessibility requirements from the employees’ perspective, the organization’s processes, and the current technology. From the results of this needs assessment, you and the client can start to think about purchase decisions to take accessibility needs into consideration. The chances are that you will need to incorporate accessibility into your final solution, so the rest of this section assumes that.

For some users, accessibility could simply mean being able to change font size, colors, sounds, and other display elements. For others with more serious impairments, assistive technology products are used to accommodate appropriately. Remember that a lot of these products are already built into the operating system, like Microsoft Narrator. Here are some areas in which to consider implementing accessibility:

• In areas that affect a large number of users.
• In areas that your users will use frequently.
• In areas that are integral and necessary for your application to work according to specification.
• Application-wide such that it is compatible with accessibility aids.

The final topic in this section looks at web-based solutions. It is estimated that about 8% of all web users are disabled, so making a website that is accessibility-enabled can reach many more users than a non-accessibility-enabled one. Consider users with slow connections or text-only browsers when designing your application.
Deployment requirements focus on your users. Who are they and how are they getting your application? How many sites are you deploying to? Which users require solutions in different languages?

Users can be broken down into three categories:

• Standalone Users - Users who are not connected to a LAN.
• Remote Access Users - Users who will gain access to the network through remote access modems.
• Local Network Users - Users who are directly connected to the network.

The important thing to remember is that you need to understand the needs of each of these users to have a successful deployment. Collect information from your project teams, staff, and user groups. Surveys and interviews are also good supplements to figuring out how best to deploy a solution.

Remember that even if an application runs correctly in the development environment that there is a still a chance for it to crash and burn in the production environment. End users might be missing critical components that the project team assumed was on all computers; the components may even be outdated as well. One way to avoid this is assume that your target computers don’t have any critical components on there, meaning that you have to install them with your software. But this doesn’t stop the DLL Hell “phenomenon” most of us are familiar with, as all of those components could later become corrupted.

The last thing to mention is about distributing your application. How will it make its way to your end users? This will mostly depend on the location and number of your users as well as what category they fit into (see above). Here are some common deployment scenarios:

• For a large number of users in diverse and remote locations you might want to consider deploying through CD-ROM.
• For a smaller number of users you should consider deploying through the Internet or over an intranet.
• For users that are located worldwide you should consider deploying over the Internet with different packages for different language accommodations.

Extensibility requirements look at the adaptability of a system and the degree to which that system can be enhanced in the future. There are two main tenets of extensibility that come up every time a new feature is requested for an application: cost and time.

When designing your application, you should think about the direction in which the application is likely to go after the initial deployment phase. Of course it is good to talk to stakeholders, your client, and members of your project group to create a clearer (though it would be impossible to make it crystal-clear) vision of where the project is going. Systems have to remain flexible to account for the changing nature of business, because if those systems become out-of-date, then it will be trashed. This is a constant problem that software developers have to face, and considering extensibility is a good first step toward alleviating the problem.

On a more concrete note, when developing extensibility requirements, think about the average time and the cost it will take to make updates in different areas of the application. After making these requirements, design defensively! It will save you a lot of time in the long run when the client requests an update to the application.

In looking at PASS MADE there are a slew of areas that you have may not have considered when designing your application, but these are just operational requirements. Other requirements exist like business requirements (how your application fits with the business’s organizational structure, performing gap analysis, and modeling data flow) and user requirements (use cases, globalization, and localization concerns) which should be performed before you even make it to the PASS MADE level. Also, you will need to use your analysis from PASS MADE to determine whether the production environment has the right hardware and infrastructure to support your application. If not, you and your client will need to reach an agreement on how their IT infrastructure will support the current application and any future releases of your application. A substantial amount of planning and communication should occur to reach the right conclusion on these issues, and they will surely save time later down the road.
Adapted from: Randy Cornish, et. al, Analyzing Requirements and Defining .NET Solution Architectures (Exam 70-300). Indianapolis: Que Publishing, 2003.

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.

Throughout the majority of Quarter 5 at Neumont University, a team of us here at RevNet worked on a project known as Virtual Employee/Kahn for DesertGate. The main impetus for this project was a simple exchange of favors: the Revolutionary Networks team does projects for DesertGate in exchange for server space and some other benefits (the details of which I am not aware). Over the course of the quarter we worked on solidifying a requirements document to define the scope of the project, and the eventual goal was to take these requirements and run with them to create a solution that would solve their business problem.

But because of stifled communication between DesertGate and RevNet, the project was cancelled by the Project Manager and the Technical Lead. Although at first I was surprised and taken aback at the concept of actually cancelling the project, I took a few days to reflect on why we did so. I came up with the following:

1. We started this project in mid-July. It was now late August and the business requirements were still not quite done.
2. Even if we had finished the business requirements, user requirements would’ve been an extreme hassle to go through. Not only were we a state away from their office, but we really couldn’t solicit responses from users on their own time. The downtime between our sending questions and their responses would waste a lot of time.
3. On top of that we needed to know system requirements, which would take another set of questions through email…it goes on.

Only after that mess could we actually begin to design a solution that we wanted to - that’s looking at another quarter just to gather requirements! And that includes all the ORM for business objects, the use cases, the business process descriptions, possible business rules, UI design, interaction design, component design, technical specifications all before the actual development process starts. Even if we are being compensated with server space, we cannot afford to spend so much time idling on a project!

I also talked with a professor who prides himself on project management about this situation. What I learned from the conversation was that at that point in the project, to call it quits was not necessarily a bad idea. However, may be in future what would be better is to solicit more direct feedback from the company. Because one of the members of the project has worked for the company, he was assigned to be the product manager (the one who interacts with the client and ensures that the business requirements meet the solution later down the line) - it’s only speculation, but that could’ve caused DesertGate to feel more relaxed about the project and thus not rank it as a high priority. If we were being paid to idle, that’s fine, but having DesertGate consume our resources like this was just not cost-effective to the team.

That being said, if DesertGate does decide to clean up its act, then I’m sure our team would have no problems working with them. But perhaps we need to effect a change in how we communicate with outside companies. I know another member of our team who was not working on this project has stressed that communication isn’t really there unless it’s in person or over the phone. Maybe that’s a tenet we should incorporate into future projects with outside clients.