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)

Communication from the pros

This post outlines key observations on the presentation techniques of two of the best known presenters, Steve Jobs and Bill Clinton. Without further ado...

Steve Jobs' Tips:

BusinessWeek has a great article, How to Wow 'Em Like Steve Jobs (by Carmine Gallo), that talks about Mr. Jobs legendary presentation skills. The key points are:

  • Sell the benefit - Talk about how this will make things better for people by enhancing their lives. What does it mean to them? Don't say things like, "We have redundant server clusters around the globe." Instead try this, "Our 'doors' are always open for business. When a server goes down, our consumers can still interact with us and purchase our products."
  • Practice (a lot) - If you want to come across naturally, you must be intimately familiar with your material. You are rehearsing your presentation. It's got to be an event people want to attend, not a chore they have to do.
  • Keep it visual - Use good, simple pictures and words instead of data driven slides. Eventually all the numbers will blur into something incomprehensible to your audience. Use too much data and you'll soon hear the sound of snoring.
  • Exude passion - If you don't show genuine interest & excitement in your subject why should anyone else?
  • "And one more thing..." - Close strong. Give them something else. This is the marketing WOW factor.

Bill Clinton's Tips:

On Ezine Articles there was a great write-up by Tomas Murrell on Bill Clinton's speechwriting ability. Mr. Clinton is widely regarded as one of the best speakers on the planet. One of the comments about Mr. Clinton's speeches is that he gives everyone something that resonates with them. This is a great article so please read it, Speech Writing Secrets of President Bill Clinton. I'm just going to bullet point the main parts so you'll need to read the article to get the full context.

  • The power of presence - Remember that non-verbal presentation is extremely important. Your expressiveness, gestures and the way you carry yourself make a huge difference. Refer to my post, The soft-side of presentations for more information.
  • Customizing the message - Tailor for your audience. People like the personal touch. Speak to them.
  • Repetition - Think reinforcement. Reinforcement.
  • Using metaphors - Use simple metaphors to help explain more complex topics.
  • Develop empathy with the audience
  • A call to action - Tell them your goal. What do you want them to do?

Other posts on presentations:

Summary:

By watching some of the better speakers display their mastery of communication you can pick up on things that can help you become better. I notice that as I watch other people give presentations, I can see what works and what doesn't work. These learnings I can incorporate into my own repertoire.

The single biggest problem in communication is the illusion that it has taken place. (George Bernard Shaw)

Agile versus business agility

When I hear the word agile, I think of the class of system development life cycle methodologies that are fairly people-oriented. Agile methodologies assume that change will occur and they are flexible enough to handle it. Characteristics include (you can also see my post called, Choose a methodology that suits your project):

  • Short iterative cycles.
  • Frequent, defined client feedback.
  • Changes (evolution) from one iteration to the next.
  • Modification of previous components to adapt.

As companies migrate their systems to more of a service-oriented architecture (SOA) approach, agile development methodologies are proliferating. These approaches are very useful for developing reusable components - a necessity for SOA.

What does "business agility" mean?

The ability to rapidly adapt and capitalize on opportunities or overcome problems. It does not necessarily imply that you are reactive or proactive. In truth, agility means you can adapt readily in preparation or response to stimuli. Obviously, having reusable components and an SOA framework support business agility. However, true business agility is more than just that.

I remember reading, The Regis Touch - New Marketing Strategies for Uncertain Times by Regis McKenna. In his book, Regis illustrated one of the best examples of business agility that I have come across. He recalled an experience he had when he was working as a consultant with Intel. Intel's sales teams had encountered a issue with their customers asking them about a pending competitive microprocessor product launch from Motorola, the 68000 processor. Customers were considering holding off purchases until they could assess Motorola's offering.

This message reached the ears of Intel's executives who organized a marketing response which included their product roadmap and vision. In addition, they setup seminars with clients where Intel could capitalize on the credibility of their executive staff (e.g., Gordon Moore & Andy Grove.) This marketing strategy was relayed back down to their sales staff who championed it.

Intel's actions avoided a significant competitive threat. The amazing part is that it only took 7 days for Intel to generate their positioning strategy and put it into place. That's business agility!

Thoughts on decision-making

According to new research on the Discovery Channel's website, cockroaches get together to make group decisions about things that affect them as a community. Even more astonishing, cockroaches do so without being able to make sounds. Perhaps, we can learn something about the science of decision-making from them.

Common myths about decision-making

  1. The more time I spend analyzing before making a decision, the better the decision I will make. Sometimes you can spend too much time making a decision. Your indecision could allow a competitor to seize the initiative.
  2. In retrospect, a decision that did not work out was a bad one. Because something did not work out does not mean a bad decision was made. There are many things that are beyond your control that can affect a situation and cause an undesirable outcome. This does not imply the decision was incorrect.

What's it worth?
Here are some basic questions that you should consider to understand the importance of a potential decision.

  • Does it contribute towards meeting your goals or objectives?
  • Does it contribute towards the goals and objectives of the company or greater good?
  • What is the risk associated with an inappropriate choice?
  • How much time are the key decision-makers and you willing to provide? If no one is willing to give time, then how important do they really view it? (I'm a little draconian here, I'll admit.)
  • What are the associated benefits and costs of making the decision?
  • What happens if I do nothing?

Some decision-making techniques

To help you with your decision-making needs I have listed off a few different techniques that may be useful.

  • Paired comparison analysis is very useful when there are defined alternatives. The basic premise is to use a grid to directly compare one alternative versus another. The alternative that wins out against the others the most will be chosen.
  • Use a SWOT analysis to evaluate different solutions to a problem or opportunity. This will give you an understanding of their overall appropriateness.
  • Grid analysis involves comparing alternatives against a defined set of important criteria. The winning alternative will be the one that scores the best.
  • When you have a few different issues to address and you are trying to determine which one to attack first, Pareto Analysis, can be very useful. It involves identifying the most pressing problems.
  • Decision-trees are very useful to help you visualize all of the possible outcomes. You need to be able to estimate the likelihood of a path being followed as well as the value of the path (e.g., outcome.)
  • One can use the 6 Thinking Hats methodology to examine the different aspects of a situation before settling on a solution. This methodology was developed by Edward de Bono and can be applied to innovative thinking as well as decision-making.
  • Force field analysis is extremely useful to understanding the different forces that affect an issue. The great benefit from this technique is that it will illustrate all of the areas that will be impacted and may require a change management process because of a pending decision.

Some other great resources

Stay committed to your decisions, but stay flexible in your approach. (Tom Robbins)