Improving Requirements Quality with Use Cases

People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Sample ATM system usage use case diagram

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases: Read more »

Good Requirements vs. Rework – Part 2

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” Remember how we discussed that in my previous article and closed out with the good news that “better, cheap, and faster” is actually possible?

Now the bad news: You have to change your approach to project and product development or procurement in order to realize “better, cheaper, and faster.” Repeating the mantra is not enough. Nor is it enough to tell your requirement definition team to simply “write better requirements.” If that was all it took, we all would have done that long ago. You, as the project manager, must identify the areas needing improvement and empower your people to change. Only a manager can eliminate many of the causes of bad requirements. The seeds of schedule and cost overruns as well as operational failures are planted early in projects, typically with pressure, often from management to procure or begin developing a product before fully defining it’s needs and use. Read more »

Good Requirements vs. Rework

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business. Read more »

A Case for Thorough Testing and Management Oversight

Today I was reading a synopsis of a fiasco that happened in the 1990s with Oxford Health Plans – a successful HMO at the time. If ever there was a case for thorough project management to be wrapped around a major system overhaul and detailed and planned testing to be utilized on a project…this one is surely it.

Here’s the story….

Oxford Health Plans is a successful health maintenance organization (HMO) in the New York area. The firm went public in 1991, and its stock price enjoyed steady growth. In 1997, however, problems with a new computer system. led to significant losses, $120 million in the fourth quarter on top of $78 million in the third quarter. When the company announced its second quarterly loss, its stock price was 75 percent lower than its previous high. It was unable to send out monthly bills for many of its customers, and the company could not track payments to hundreds of doctors and hospitals. During the year, uncollected payments from customers rose to $400 million, while Oxford’s unpaid bills to (caregivers) rose to over $650 million.

The problem began when Oxford started planning a system, based on the Oracle database management system, when it had a little over 200,000 members. By the time the system went live three years later, the HMO had 1.5 million members. The company tried to convert to the new system all at once. While the computer system labored under the load, Oxford management continued its aggressive drive to sign up new members. The new system was intolerant of errors that were accepted in the old one. As a result, an account with thousands of participants might have been rejected for an error in any member’s record.

Some customers refused to pay the HMO after not being billed for months so Oxford had to write off over $100 million in uncollectible bills. The HMO’s failure to pay its bills also angered care providers: At one point it owed Columbia University $16 million and Cornell $17 million for medical services. Oxford lost track of its actual medical costs-information a health care provider needs to set reserves and project liabilities.

While organizations have been implementing IT since the 1950s, we still seem to repeat many of the same problems. Oxford is a clear case of a management failure rather than a technology failure.

Summary

Have you ever heard of one of those projects where you ask yourself – or someone else – what were they thinking? Did they even put a project plan together? Did they even setup any test cases and perform any user acceptance testing at all? Who signed off on all of this? Or worse…have you ever heard this asked about one of your projects?!?

Solid project management practices won’t fix everything and make every project successful, but they often will and certainly will help avoid any frequent occurrence of project nightmares like the one mentioned above.

The Project Quality Assurance Role

Quality Assurance is often seen as an integral function that monitors and coordinates the quality used within the project management life cycle by evaluating the processes and procedures. Quality control, on the other hand, can be seen as a focused area (such as software testing) that compares the product to the specification or plan, with a focus of detecting and remediating errors or anomalies.

Therefore, the Quality Assurance role is a critical factor in the success of the overall project as it is focused on key quality functions throughout an engagement. In his book “Project Management Nation,” Jason Charvat identifies the following key duties for the role of quality assurance throughout the project management life cycle.

The Role of QA on the Project

The person who is responsible for QA has many duties and responsibilities. The following section lists many of the things that a QA person would be expected to do.

• Participate in the change management process to assess the risk of putting fixes into the environment during acceptance testing.
• Assist the test team in isolating the source of discrepancies between expected and actual test results. If the error is in software design, thoroughly analyze the ramifications of any design changes. Design diagrams and structure charts before proceeding with corrections to code.
• Complete preparations for acceptance testing, including the establishment of the acceptance test environment. Unlike system testing, acceptance testing always takes place in the targeted environment. It is therefore extremely important to schedule computer resources well in advance.
• Check the simulated data to ensure that required test data have been produced.
• Obtain expected results from the acceptance test plan and review them for completeness.
• Calculate any missing expected results.
• Be certain that the introduction of new load modules is according to test configuration management procedures. When a new, corrected load module is received, first rerun tests that previously failed because of software errors. If these tests succeed, proceed with regression testing.
• Analyze and report test results. Evaluate test results as soon as possible after execution. Wherever possible, use automated tools in the analysis process. Record analysis procedures and keep all relevant materials. Remember that records and reports should give complete accounts of the procedures followed. If a test cannot be evaluated, note the fact and report the reasons for it.
• Compare all test results with expected results and note that all defects are documented, regardless of how minor they appear or whether they will be corrected.