Non-functional requirements: Logging

Understanding what activities are processed through a system is critical to knowing whether it is behaving as expected and central to diagnosing potential problems and issues. The key benefits of logging and tracking are:

1. Facilitates problem-solving. Should an unexpected result be produced, you can follow a transaction through the system to identify where a problem starts.
2. Provides transparency into the operations of a system. In turn, this proves reliability and predictability.
3. A log provides an audit trail. Logs can be used to detect patterns in behavior as well as find inappropriate user activities. For example, you may notice 5 different transactions for completely unrelated people, however, the delivery address is the same. This could indicate potential fraud. If the transactions were examined individually, this form of fraud may go unnoticed.

Considerations for determining the extent of logging for a system include:

• The length of time that you will need logs (see my post on Data Retention.)
• Capture appropriate information to support problem-solving and investigation into normal transactions as well as exceptions (see my post on Exception Handling.) To keep track of a purchase order without the details (such as the products and prices) may not provide enough information to support further problem-solving or generate insight.
• Are there legislative reasons why you need to track specific types of information? In the United States there are efforts underway to force ISP to log the activities of their clients.

As you can see, data retention, exception handling and logging are closely intertwined.

Non-functional requirements: Error Handling

How should a system handle the unexpected? This is a fundamental consideration of any solution.Key points to keep in mind are:

1. What are the consequences of not resolving errors? If you are working on a financial system, a missing transaction means that account reconciliations will be difficult, or in other words, you are misplacing money! In such cases, you should consider creating suspense accounts to hold the erroneous transactions. Operational staff can then balance the suspense accounts to zero and route the corrected transactions appropriately. Common types of errors include invalid accounts and invalid products. Keep in mind that you may encounter errors that you never considered.
2. Will you process batch or real-time transactions? Do you foresee needing to reverse out large numbers of transactions to remove erroneous transmissions? Should you submit reversing entries or delete all of the errors? When you load transactions, make sure you include the appropriate information to allow you to identify the record or group of records.
3. What will you do to prevent the loading of problematic transactions? Do you need to quality control (QC) the transactions and then reject them if they appear erroneous? For a batch, if more than a specific percentage have errors the batch may be rejected completely. Conducting a few simple QC tests will keep you from going through the pain of fixing transactions that have made it into your system.
4. Should you keep record of the original transactions that have been processed? Is error logging required?

For many systems, particularly financial ones, losing a transaction is a faux pas. If your system does this, its reliability may be questioned.

Non-functional requirements: Data Retention

Data retention refers to the storage of a system's information for a specified period of time. This information should be examined according to the different data domains (e.g., transactional, consumer, product, complaints, etc...) Each domain may have separate retention requirements. For example, information on products and transactions may be stored indefinitely, however, consumer records maybe be purged after 4 years of inactivity.

Considerations for data retention include:

• System - What are the uses of the information? Will you be doing long-term trend analyses or operational reporting only?
• Legislative Restrictions - Some information sets may have legislation concerning their mandatory disposal after a specified elapsed time. Other places have legislation mandating data retention for specific industries (e.g., Europe has legislation mandating data retention for telecommunications firms as part of their anti-terrorist activities.)
• Useful Life - How old can information get before it becomes dated? For example, marketing information that is 12 years old probably has little value to marketers. Because you were a student 12 years ago probably does not help a marketer that much now.
• Customer Service - How much historical information on a client is required to deliver appropriate levels of service?
• Data Aggregation - Should old information that is being disposed of be rolled-up so that long-term trend reporting can take place? Do you ever anticipate looking at the detailed information again?
• Data Disposal - Should old information be kept offline or removed permanently? What type of archiving is necessary?

Based on your needs, your data retention strategy may require additional capacity and storage facilities. All of this comes at a price. As such, you must be careful to balance your desire to retain data with the cost of its maintenance.

Non-functional requirements: Security

One of the most important non-functional requirements is security. Security requirements can come in many different forms:

1. Privacy - Requirements can dictate protection for sensitive information. Some types of privacy requirements include: data encryption for database tables, policies regarding the transmission of data to 3rd parties (e.g., scrambling user account numbers), etc... Sources for privacy requirements could be legislative or corporate.
2. Physical - These requirements relate to the the physical protection of the system. Other types of physical requirements include items such as elevated floors (for server cooling), fire prevention systems, etc...
3. Access - Access requirements define account types / groups and their access rights. An example of an access requirements could be to limit each account to one login at a time or to restrict where an application can be deployed or used.

While most clients can tell you what availability or capacity they expect to need, it is less likely they may know everything about the security aspects. As such, I suggest you ask security specialists for their advice and opinions. The Journal of Object Technology has a great article on Engineering Security Requirements by Donald G. Firesmith. I suggest you look there for a more complete look at security.

Extreme availability & reliability test

Earlier in the week, I wrote about Availability and Reliability. Yesterday on Digg.com there was an interesting post showing an HP StorageWorks XP12000 Disk Array performing under load during the process of having a bullet fired through it.
The test showed a high-caliber round being fired through the disk array and through a fish tank on the other side. The disk array was streaming video to many monitors in the room. The goal of the test was to see whether the video would be interrupted. The results? You can watch it here! Keep in mind that the video is a marketing promotion but the test itself is very interesting and clearly shows extreme availability and reliability testing.

Interesting thought: Is your company dead in the water if someone shoots your server?

Non-functional requirements: Data Currency & Internationalization

This is my third post on non-functional requirements. Let me reiterate that non-functional requirements describe characteristics of a system as opposed to how a system functions or operates.

Data Currency
Many systems collect data and provide data for users. Data currency, refers to how up-to-date this information is. Trading systems require access to real-time information or their business value is negligible. If you were a day-trader, would you be willing to use yesterday's prices to execute your trades?

Other types of systems do not have as stringent requirements (e.g., data warehouses.) Data currency can affect your choice of solutions to a business problem in that if real-time information access is required, specific procedures such as batch uploads cannot be utilized.

Internationalization
Implications could be the need to have multi-language descriptions of products as well as pricing schemes for different currencies. Web sites such as ebay have regionalized sites where prices are displayed in a user's native currency. In general, internationalization focuses on the countries, time-zones, currencies and languages that will be supported.

The proliferation of web applications is pushing us towards a more global view. Today you may only have to deal with 2 languages, but tomorrow it could be 3, 4, 5 or more!

Non-functional requirements: Disaster Recovery

One thing that was implied in my previous post, Availability & Capacity, was that higher levels of reliability are costly. Costly because it implies redundancy and ensuring there are no single points of failure.

Another, expensive non-functional requirement is disaster recovery or recoverability. Disaster recovery considerations should be made for every application. However, I'm not sure I could say they are taken into account appropriately. It's like the unwanted step-child from fairy tales of old that no one wants to have anything to do with...

Items that must be taken into consideration are:

1. System criticality - How important is a system to your company? Real-time trading systems are more important than intranet applications; at least for most companies.
2. System recoverability - How fast must you be able to restore full or partial service (in minutes, hours, days, weeks, etc...)? A system's criticality will help answer this question.
3. Magnitude - What is the scope and scale of outage that you are willing to deal with? Two of the companies I worked at in the past had disaster recovery facilities approximately 10 kilometers from their main facilities. This was great for testing the facilities and made it easy to transport designated workers to the alternate locations. Now suppose there was another blackout like the one in 2003 that hit the Eastern coast of North America. There would be no way that geographically close disaster recovery centers would be able to function. Notice the nice black area where Toronto, Canada and New York City are. Consumers inside that area would not be able to buy things from our e-commerce sites, however, what if the majority of our consumers are not in affected areas?
4. Disaster simulation - You'll need to practice how you would operate during a disaster. Simulate a disaster and then see what problems you encounter. This is how you find out silly things such as your servers are working fine but there is no internet access so you're offline and inaccessible.

Disaster recovery is really a business decision and it should be treated as one. What risk are you willing to accept and live with?

Non-functional requirements: Availability & Capacity

I've spent a bit of time writing on basic presentation, communication and innovation themes. Now I'm going to refocus and go into more detail on one of my earliest posts titled, What are requirements? SDLC? More specifically, I am going to expand my coverage of non-functional requirements and their implications.

Non-functional requirements govern characteristics of a system. Many non-functional requirements will have direct implications to a project in the form of cost implications, performance objectives and future growth potential.

Availability
Availability indicates when a system is operational as well as how reliable it is during operational periods.

1. Hours of operation - What are the hours that a given system will be available? What days will the system be operational? Not all systems operate on a 24/7 basis. Some internal facing systems may only be needed when there are people in place to operate them.
2. Reliability - During a system's hours of operation, what reliability (excluding planned outages) is needed? Reliability is usually measured as a percentage. The higher the number, the greater the cost. Many people ask for 99% reliability but do you actually need it? 37signals has a great post explaining this concept. The question to ask your clients is, "What level of reliability is justifiable from a business perspective?" Will the world end if your web site goes down unexpectedly for an hour? The answer will be different for different systems and companies.

Look at the picture below to see what are the allowable outages based on the level of reliability required.

Capacity
The ability to handle transactional volumes is a very important characteristic for a system. If you are building a high-volume e-commerce web site but you can only support 10 concurrent logins, you've got a major bottleneck. Here are a few considerations you will have to take into account:

• What are the different types of things (e.g., types of supported activities or transactions) that can happen?
• For each type of transaction, what volumes do you see on an hourly, daily, weekly, monthly etc... basis?
• What types of patterns exist for the transactions? Are volumes significantly higher during specific parts of the day (e.g., at lunch), week, month or year?
• What transaction volume growth are you expecting?
• Will additional systems make use of the services you are building? You may have taken into consideration your website's needs, but what happens when the point-of-sale systems start trying to use your services? Can you manage this additional volume?

Summary
Non-functional requirements such as availability and capacity can have substantial cost implications to a project. Almost everyone wants 24/7 hours of operation with 99.999% uptime and the ability to process thousands and thousands of transactions. However, does that meet the cost-benefit test?

Big and small

Innovations can come in all sizes: big or small. Look at the little innovation square from my post, Types of innovation. They don't have to be earth-shattering or the next big thing. Innovation can be as simple as trying to improve performance and improving the quality of one's life.

Where do you go for inspiration?
To the competition - What do your competitors do? How do they handle the problems you face? How can you improve upon their offerings? Look at the Apple Ipod. Prior to its introduction there were MP3 players already in the marketplace (e.g., the Eiger Labs MPMan F10.) What separated the Ipod from the others was it's ease-of-use, design and quality.

From unrelated companies - Companies in different industries can face similar problems. Learn from their experiences and mistakes.

From within - Think about the unique capabilities of your company. How can you leverage them to obtain more benefit from your investments? Perhaps your organization is a pioneer and has knowledge others do not (unlikely but this can happen)?

By accident - Research scientist Dr. Spence Silver was trying to develop an adhesive. However, his work yielded an adhesive that could be peeled off over and over. Art Fry realized he could use this adhesive to keep his bookmarks from falling out of his books. Hence the 3M Post-it Note was born!

Use something in a different way - Thomas Savery designed a steam engine to pump water out of mine shafts. Charles Parsons later used the same concept for marine vehicle propulsion and as a means to generate electricity.

Inspiration can be found everywhere!

Questions lead to innovation

By nature, people do not like change. They develop comfort with routine, regardless of whether it makes sense or not. It's some sort of inertia.

As a business analyst you will encounter this inertia many times. Where you'll really notice it is when you are trying to redefine a process to be more efficient and realize that the new process is strikingly similar to the old one. When you ask them why the new process looks the same as the old one, you'll hear answers such as:

• "I don't know."
• "We've always done it that way."
• "I'm not sure why we do that; we just do."
• "Why would I do it anyway else?"

With any process, you should try to understand why you need to do any specific step. What are the key benefits, considerations, safeguards etc...? Are we simply asking for a step in the process because, "it's always been there?"

Be willing to inquire. Of course you'll need to be a little careful to avoid offending people (see my post Asking questions & getting answers.) However, you must understand your clients' wants in order to determine the best ways to achieve it. As a business analyst, you have a few objectives:

1. Understand your clients' desires.
2. Communicate the needs so that IT staff can understand them.
3. Analyze and innovate to make things better. This is where you add additional value to a project. I'm not talking about increasing scope with all of your ideas. I mean, add value to help your clients' maximize the benefits they can realize.

Is there a better way to do something? What can we learn from other industries? What can we learn from other companies? What can we leverage more?

A company's ability to innovate, improve, and learn ties directly to the company's value. (David P. Norton)