Case Study: The New Account Project at HBC

Directions

When reading this case study, focus on the activities related to establishing the requirements for a software project. Identify issues and decisions associated with selecting and involving stakeholders in these activities.

Case Summary

Description

• The Individuals Direct business unit of Hamilton Banking Corporation (HBC), a large financial institution, wants to increase customer usage of online banking services. In particular, managers have set a goal to increase the number of new accounts opened online by 50 percent within two years. To help do this, the business unit has requested the information technology (IT) group that services the unit to enhance the banking Web site for individuals. The case scenario involves the events that occur as the stakeholders try to establish the requirements for the software project and encounter an unexpected challenge to the project schedule and budget.

Case Study Objectives

• After reading the case study, you will be able to do the following:

• Understand the importance of the following decisions in establishing the requirements:

• Which stakeholders should be involved?

• How and when should the various stakeholders be involved?

• Identify the activities by which the organization established the requirements.

• Identify appropriate stakeholders in the case scenario who should participate in the activities to establish the requirements.

• Explain the problems that occurred in the case scenario, the causes of the problems, and the ways to reduce the likelihood that similar problems will occur in other software projects. Relate these to the decisions faced by project stakeholders.

Subjects Covered

• Decision making, establishing requirements, eliciting requirements, verifying and validating requirements, and stakeholder selection and involvement in establishing requirements

Setting

• The setting is Hamilton Banking Corporation, which is a large, publicly traded financial institution that provides commercial and institutional banking services. The company maintains its headquarters in the city of New York and has a campus for business development and IT support in White Plains, New York (Westchester County). Branch offices are located in New York, Connecticut, New Jersey, Pennsylvania, and Rhode Island.

Key Concepts

• Successful establishment of the requirements depends on the appropriate selection and involvement of the stakeholders.

• When establishing the requirements, it is important to involve people who:

• Understand the business goals of the client or customer

• Are potential users of the software or understand what users need

• Will approve the software requirements or software project

• Will determine the time and cost associated with providing a solution that satisfies the required (and negotiated) scope and quality

• Can verify the requirements with respect to clarity, compatibility, completeness, consistency, and correctness

• Can validate the requirements with respect to the business goals of the client or customer and needs of the users

• Have the knowledge and skills to negotiate a contract that satisfies the expectations of both clients or customers and solution providers

• Are knowledgeable about compliancy, legal, and other corporate issues that are important to the client or customer and to the solution provider

Terminology

CIO: Chief information officer.

HBC: Hamilton Banking Corporation.

IT: Information technology.

Use cases: A technique used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor and the software system. Actors exist outside the system being studied and take part in a sequence of activities in a dialogue with the system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events from the point of view of the actor. See Jacobson (1992) for the foundational definition of use cases. See Kulak and Guiney (2003) for a practical guide to use cases as a primary tool for eliciting requirements.

VP: Vice president.

The Case

Scenario

Susan Calloway and Georg Johansson are puzzled and irritated. They wonder why upper-level management would consider delaying the New Account Project one month to satisfy a request by the “newly minted” Corporate IT group at HBC. Robert Caldwell, who heads this new group, has asked for his Web Strategy Team to be given one month to review the project requirements with respect to corporate issues such as branding, compliancy, privacy, and security. (See Figure 2-1, which shows the HBC organizational chart.)

Figure 2-1: HBC organizational chart

Susan and Georg have managed the establishment of the requirements, including the initial sign-off on the project agreements by the stakeholders. They are anxious for the project to move forward into design. There are only ten months remaining for this tightly scheduled project. A slip of one month would incur not only the expense of the additional review but also other costs associated with the delay. Georg and Susan are worried that if the Web site enhancements (deliverables for the New Account Project) are not done on time, then the Individuals Direct business unit will not be able to meet its business goal to increase the number of new online accounts by 50 percent within two years. The market for Internet services to individuals is a high-priority business opportunity that would enable HBC to continue its record for steady growth.

As Georg and Susan reflect on the approach that they used to establish the requirements, Susan recalls, “Our approach worked well on previous Web-based IT projects. With a tight schedule, we barely had time to question the way we would establish the requirements. Besides, why should we have ‘reinvented a wheel’ that was successful in the past?”

Georg bemoans, “How were we to know that Corporate IT would be alive and ‘chomping at the bit’ to review business unit projects outside its immediate directive? I think that Robert Caldwell could do more good for HBC by reviewing and updating the corporate-level Web policies before becoming involved in unit-level projects.”

Susan replies angrily, “We received a clear mandate from Katrina, Charles, and Martha that we are responsible for managing the project from beginning to end. I am surprised that they would give Robert’s request consideration.”

Georg agrees and then adds, “When Karen Hathaway speaks, the CIOs listen. I suppose Karen wants to establish the importance of her new Corporate IT group. But what should we have done differently? Perhaps we could have made better use of the extra time allocated in the schedule for the critical path . . . .”

Flashback to the Beginning of the Project

As experienced managers, Georg and Susan understood the importance of establishing the requirements. They had seen too many projects that went awry because the stakeholders had not established a common understanding of and agreement on their expectations for the scope and quality of the deliverables as well as the associated schedule (time) and budget (cost). Almost immediately, they agreed that the requirements would need to be established within about two months for the New Account Project to be completed in one year. From experience, they realized the importance of selecting a minimal number of stakeholders who could effectively determine the requirements and project agreements without becoming bogged down by “analysis paralysis” or endless dissension. They laughingly dubbed these the “necessary and sufficient” stakeholders.

To help them select appropriate stakeholders, they outlined the following kinds of stakeholders whom they thought were essential to establishing the requirements:

• People who will approve or audit the software project and its budget

• Users or people who can represent the user point of view

• People who can represent the software service provider or software developer point of view

• People who will manage the software project

In the past, the business units worked independently on their own IT projects and collaborated only when the projects involved corporate-wide business issues or opportunities. Georg and Susan understood that financial support for the project was coming from unit-level management. Charles Vanderbol (VP of Individuals Direct) and Martha Schuller (CIO of Individuals Direct IT) had announced that Susan and Georg would be directly responsible for managing the New Account Project. Susan and Georg expected little to no corporate-level involvement on this project.

Susan and Georg confirmed that Katrina Olowski, Charles Vanderbol, and Martha Schuller wanted to be involved in establishing the requirements, though Charles would most likely delegate the technical details to Katrina. In particular, Charles would validate the requirements with respect to the business objectives and keep an eye on the schedule and budget. Martha planned to oversee the development of the project agreements as well as the staffing on the development side of the project. Georg and Susan would assist Martha in establishing the project agreements and, of course, continually would report the project status to Charles. Katrina wanted to validate the scope of the requirements and the required software qualities. For this project, she intended to be less involved in auditing the schedule and budget and more involved as a backup technical manager.

On previous IT projects, Susan and Georg had observed that the branch managers and their staff have an excellent understanding of the needs of the bank’s individual customers. The branches were also proactive in assessing and promoting the development of online banking services. Susan talked with Mikhail Orchov (VP of Branch Services) to determine whether his organization would be able and willing to represent the user’s point of view in establishing the requirements. Mikhail enthusiastically offered the services of one of his regional branch directors.

Among the three directors, John Pattersal had the most recent and extensive experience with online services. Georg and Susan reasoned that current and relevant experience was a good indicator of a stakeholder’s likely ability to contribute to their project. With this in mind, they decided that, of the three branch directors, John would probably be the most effective stakeholder. They planned to involve John in eliciting and verifying the requirements. Though his participation would be minimal, Susan and Georg thought that it was wise to keep Mikhail in the loop as a stakeholder. Mikhail would help “sell” the Web site to the branches in the future. He could also be involved in validating the requirements.

Likewise, Susan and Georg thought that marketing analysts who interface with customers would be best able to determine and validate the requirements. They scanned the resumes of senior marketing analysts within Individuals Direct and found Mary MacDonald, a senior analyst who headed up the requirements-gathering activity for a highly successful and visible Web project in the business unit. Susan was familiar with Mary’s requirements work with customers and felt comfortable that Mary would be an asset in eliciting and validating the requirements for this project.

Because of the tight schedule for the project, Susan and Georg realized that the scope of the requirements would need to be controlled. Unlike many of the other marketing analysts, Mary MacDonald reportedly did not try to overload the requirements for a software project. She realistically knew that smaller-scoped projects generally had a greater chance for success. This was another reason why she would be good for the project. Since Georg and Susan had decided to limit the number of stakeholders who would participate in establishing the requirements, they did not consider adding other stakeholders to represent the user.

Both Georg and Susan had worked in the past with Tim Weber, a project engineer with the Business Analysis group within Individuals Direct IT. Tim had significant experience in leading the development of Web-based services and would be an ideal software development lead. They considered another project engineer with success in leading Web-based projects but chose Tim because his background included more work in estimating the time and cost of developing Web-based solutions. Georg was especially confident that Tim would be an excellent asset during the negotiation of the requirements and project deliverables. Tim’s development team would create and verify the statement of software requirements.

To save time and money, Georg decided to serve as a stakeholder for both IT services/software development and project management. Susan would work with Georg on project management. Georg would lead the development of the time, staffing, and cost estimates associated with the scope of the requirements and the qualities that the project deliverables should satisfy.

In the end, Susan and Georg decided on the stakeholders shown in Table 2-9 to participate in establishing the software requirements for the New Account Project. Reflecting on their decision, they thought that they had some backup coverage for each stakeholder role in case a stakeholder had to leave the project for some unforeseen reason; but they knew that the coverage was not ideal. Susan and Georg consulted each “candidate” stakeholder individually to determine his or her interests and preferences for involvement in the project. Recognizing the excellent business opportunity that an improved Web site would offer and the visibility that the New Account Project would have within the Individuals Direct business unit and HBC, all the candidate stakeholders readily agreed to join the project.

Table 2-9: Stakeholders Selected for New Account Project

The stakeholders appreciated that Susan and Georg consulted their advice on how they should be involved, and even though they could not always attend all the scheduled meetings, the stakeholders provided the needed information in a timely manner and involved their own staffs in the requirements elicitation and validation processes. John Pattersal reported to his boss, Mikhail Orchov, “The new online features will make it much easier for our remote customers to open accounts. I appreciate the way that we have been involved in setting the requirements and am having fun with this project.”

Subsequently, Tim Weber’s Business Analysis project team produced a specification of the following aspects of the software system requirements:

• Business problem and purpose for the software to be developed

• The overall system context in which the new software features would be used

• Functional requirements including a set of use cases

• Requirements regarding nonfunctional software qualities including an evolution plan for future enhancement of the Web site

• Constraints and limitations associated with the use and development of the software

Meanwhile, Susan and Georg developed a software project plan that was reviewed and approved by the Business Technology and Business Analysis stakeholders. The stakeholders were aware of the tight, one-year schedule (which included establishing the requirements). They agreed that all the desired software features could not be developed in the first enhancement of the Web site, so they jointly developed a plan for releasing the features in successive versions of the Web site. The stakeholders thought the schedule for the first release of the Web site was doable but had minimal “extra” time allocated for the tasks on the critical path (a sequence of tasks in which the sum of the task completion times constitutes the time needed to complete a project). Georg and Susan had learned from experience to allocate some extra time, or padding, to the tasks on the critical path to allow for unexpected events that could impact the project schedule.

One week before the scheduled completion of the project agreements, Mary MacDonald had some questions regarding the way in which private information would be secured. In response to Mary’s questions, Tim Weber replied that he would need to check with Pang Hwuang, who was the resident expert on Web-based privacy and security issues. Tim learned that Pang had moved to the Web Strategy Team within Corporate IT, a new group that had recently been created. Pang was on vacation and would not be available for a week. Tim told Georg that he would not be able to answer Mary’s questions until Pang returned from vacation.

In addition, the stakeholders had found some errors while verifying and validating the requirements and, like Mary MacDonald, still had some unanswered questions. Therefore, Susan and Georg decided to use an additional week (from the extra time allocated for the critical path) to correct the errors and to find answers to the stakeholders’ questions. They considered the fact that the number of errors and questions was minimal. Though they realized that the outstanding issues could probably be resolved while the project agreements were being finalized, Georg and Susan did not want the resolution of these issues or any other related issues to negatively impact the project agreements. They rationalized that it was best to take an extra week to resolve the requirements issues before finalizing the project agreements. Therefore, they decided to push back the finalization of the project agreements by one week.

Meanwhile, Tim’s team diligently corrected the errors found in the requirements and had the corrections reviewed by the stakeholders. When Pang returned from vacation, he explained to Tim how privacy and security issues were typically handled for HBC Web sites. Hoping to impress his boss with his knowledge, Pang subsequently reported to Jonathan Lee that the New Account Project within the Individuals Direct business unit involved some interesting privacy and security issues that should be looked at across the company Web pages.

At the end of two months (which included one week of the extra time allocated in the project schedule), the software requirements and project agreements were finally complete. Susan and Georg were optimistic that the project could be finished within the next ten months. The upper-level managers Charles Vanderbol, Katrina Olowski, and Martha Schuller were pleased with the current project results.

Then Martha Schuller reported at a quarterly IT management meeting for the Corporate CIO and IT unit-level CIOs on the progress of the New Account Project. Robert Caldwell (IT strategist and head of the fledgling Corporate IT group) asked why he had not been consulted regarding this project, especially since his group had been chartered four months ago to oversee the development of HBC online services by the various business units and their IT support groups. He explained that he had hired Jonathan Lee to head up the Web Strategy Group that would provide the guidance and oversight needed to ensure that the company Web site satisfied standards being set by Corporate IT regarding branding, compliance, usability, and other corporate-wide business concerns.

Facing a wall of cold stares from the IT unit-level CIOs, Robert added defensively, “Six months ago you were eager to create a corporate-level group to establish and help implement IT policies to address issues that are important across the business units. The Web Strategy Group’s input to any major Web site enhancement project is critical. Jonathan Lee and I should have been involved in establishing the project requirements. In fact, one of Jonathan’s engineers was recently consulted regarding online privacy and security for the New Account Project.”

After a lengthy pause, Martha Schuller replied, “We also decided that each business unit would handle its own enhancements to its Web pages in the period before the next corporate upgrade to the Web site. The New Account Project has followed the corporate-wide Web site policies set for the last major enhancement of the HBC Web site. The changes to the Individuals Direct Web pages are specific to the services that we would like to provide individuals online.”

Martha continued, “I would be glad to provide Jonathan and you with copies of our requirements documents for your group to research ongoing Web site development issues. I do not want to delay the New Account Project to address any new corporate policies that are currently under development. The cost of the delay and additional work will likely result in a budget overrun.”

Considering that his group was still relatively new and that he wanted to be able to work productively with the IT unit-level CIOs, Robert said that he understood and had empathy for the budgetary and time constraints of the New Account Project. He requested that the Web Strategy Group be given just one month to review and make any needed changes to the requirements specification with respect to the development policies used for the last major release of the HBC Web site and to identify new issues that should be studied by his group. He looked to his boss, Karen Hathaway (the Corporate CIO), for support.

Everyone in the room took a deep breath and waited for Karen to speak.

Karen looked calmly around the group of CIOs and said, “Previously, we all agreed that it is important to look together at corporate-wide issues regarding the ongoing development of the company Web site. To implement this agreement, we decided to create a Corporate IT group that would study these issues and propose corporate policies and guidelines that we would review and approve via a majority vote.”

She continued, “The issue is whether to delay an important project to enable a corporate-level review of the project requirements before they are released for design and implementation. Martha Schuller, Charles Vanderbol, and I will need to discuss this request further and make a decision together.”

Karen then told Robert that she would need more information regarding the objectives to be achieved by the review as well as the estimated cost of the review. She asked her executive assistant, Jean, to set up a meeting with Martha and Charles as soon possible. Karen stated that Martha and Charles were welcome to invite any people whom they thought should be involved in the discussion, and then she moved onto the next item on her meeting agenda.

Case Problem

The New Account Project managers, Susan Calloway and Georg Johansson, were responsible for making a decision regarding the stakeholders for the project. They did not identify Robert Caldwell and Jonathan Lee, newcomers to the corporate-level management of IT Web development practices at HBC, as candidate stakeholders for their project. Later, Robert requested that the project be delayed by one month to allow his Web Strategy Team to review and possibly modify the requirements specification. The additional cost in resources and time needed for this review and the fact that one week of the project’s extra time had already been used would likely preclude the completion of the project on schedule and within budget. The schedule slippage would further delay the timely achievement of Charles Vanderbol’s goal for his business unit to increase the number of new online accounts. Charles Vanderbol, Karen Hathaway, and Martha Schuller must now make a decision regarding Robert’s request.

Case Analysis

Analysis Activity

Analysis Background

The case focuses on the following three problems and decisions:

• Which stakeholders should be involved in establishing the requirements for the New Account Project, and how should they be involved? (In the case, Susan and Georg made a decision regarding the solution to this problem.)

• What should be done when there are outstanding issues in establishing the requirements and only one week left to finalize the project agreements? (Georg and Susan decided upon a solution to this problem in the case.)

• How should Charles Vanderbol, Karen Hathaway, and Martha Schuller handle the request by Robert Caldwell to delay the New Account Project by one month to allow for a corporate-level review of the New Account Project requirements? (At the end of the case, no decision has yet been made.)

We’ll analyze the first decision that Susan and Georg made by looking at the related PEAK inputs, solutions considered, and assumed risks. Then you can analyze the other two decisions on your own. The analysis questions should help to focus your analysis.

Decision 1 (Made by Susan and Georg)

(P) Problem: Which stakeholders should be involved in establishing the requirements for the New Account Project, and how should they be involved?

(E) Experience:

• Susan and Georg are experienced managers. They realize that it is necessary to minimize the number of stakeholders who work on establishing the requirements in order to complete the project agreements within two months.

• In the past, they observed that the business units usually work independently on their own IT projects with little to no involvement at the corporate level (also a knowledge element).

• From experience, they know that the branch managers have an excellent understanding of the online banking needs of individual clients (also a knowledge element).

• From having worked with Tim Weber, they know that he is a competent leader of Web-based projects and has significant experience in developing time and cost estimates for these types of projects.

(A) Assumptions:

• Georg and Susan assume that there will be no involvement at the corporate level on the New Account Project.

• They assume that they have identified all the types of stakeholders who should be represented in establishing the requirements.

(K) Knowledge:

• Susan and Georg know that the project must be completed within one year and that it is imperative that the requirements be established in a timely manner.

• They understand that they are responsible for managing the project from beginning to end and must make the decision regarding the stakeholders who will establish the requirements.

• They have received confirmation that the upper-level managers Charles Vanderbol, Katrina Olowsky, and Martha Schuller would like to participate in establishing the requirements.

• Having reviewed the resumes of the branch managers, they know that John Pattersal has the most recent and extensive experience with online banking.

• Having reviewed the resumes of senior marketing analysts within the Individuals Direct business unit, they identified Mary MacDonald as having led the requirements-gathering activity for a highly successful and recent Web-based project. Susan is familiar with Mary’s work and is confident that Mary will be an asset in validating the requirements. In addition, Mary is known to be realistic about the scope for a software project.

Solution:

• Table 2-9 shows the candidate stakeholders that Susan and Georg selected. The table also indicates the point of view to be represented by each stakeholder. Based upon each stakeholder’s interests and expectations, they planned for the stakeholders to be involved in the following requirements activities:

• Charles Vanderbol: Validate the requirements with respect to the business goals. Oversee the schedule and budget.

• Martha Schuller: Oversee the project agreements and staffing associated with the development side of the project.

• Katrina Olowski: Validate the scope and quality requirements (focus on technical aspects of project).

• Mikhail Orchov: Validate the requirements, and sell the new Web site to the branches.

• John Pattersal: Elicit and validate the requirements.

• Mary MacDonald: Elicit and validate the requirements.

• Tim Weber: Lead the development team that would create and verify the requirements specification. Help in estimating the time, resources, and cost associated with the required scope and quality.

• Susan Calloway and Georg Johansson: Manage the establishment of the requirements and assist Martha Schuller in creating the project agreements.

• Georg Johansson: Lead the effort to estimate the time, resources, and cost associated with the required scope and quality.

• These are some alternative stakeholders that Susan and Georg considered:

• Two other branch managers. They decided upon John Pattersal because he had the most recent and extensive experience in online banking.

• The other senior marketing analysts in the Individuals Direct business unit. They decided upon Mary MacDonald because of her experience in leading the requirements elicitation for another Web-based project and because of Susan’s familiarity with Mary’s client work.

• Another project engineer in the Business Analysis group of Individuals Direct IT with success in leading Web-based development projects. They decided upon Tim because of his experience in developing time and cost estimates for Web-based development projects.

Assumed Risk:

• Since the number of stakeholders for each role is small, there is a risk that one or more stakeholders may drop out of the project with the consequence that the remaining stakeholders may not be able to establish the requirements on time. (Georg and Susan considered this risk and provided some backup coverage for each activity. But the coverage is minimal.)

• There is a risk that the stakeholders selected by Susan and Georg do not represent all the types of stakeholders who should be involved and that an unidentified stakeholder who wants or needs to be involved in establishing the requirements and who has the authority to do so may later delay or stop the project. (In particular, their assumption that there will be no corporate-level involvement in this project led them to ignore this potential type of stakeholder. Their assumption turned out to be wrong, and corporate-level stakeholders did appear later and want to be involved in the project. It is yet to be decided whether the project will be delayed. Are there any other types of stakeholders who they should have considered?)

• There is a risk that the selected stakeholders do not, in fact, have the necessary experience or skills to perform their roles appropriately and that the requirements will not be established on time or that the resulting requirements will not express what is actually needed to satisfy the business goals.

• Are there other risks associated with the decision made by Susan and Georg or with the alternative stakeholders that they considered?

Analysis Questions

1. What was the problem that Georg and Susan faced one week before the completion of the project agreements? What decision did they need to make?

2. In addition to the problem, what were the other PEAK inputs that Susan and Georg used to make this decision?

3. What solutions did they consider? What are the risks associated with each solution?

4. What effect did this decision have on the problem concerning unidentified stakeholders that occurred later in the project?

5. Why do you think that Susan and Georg did not consider Robert Caldwell (from Corporate IT) and Jonathan Lee (from the Web Strategy Team) as candidate stakeholders for establishing the requirements?

6. What were the ramifications of not considering Robert Caldwell and Jonathan Lee as potential stakeholders for the project? What do you think could have been done differently to avoid this from happening?

7. What decision must be made by the upper-level management for the New Account Project?

• What are the PEAK inputs for making this decision?

• What are the potential solutions for this decision and the risks associated with each solution?

• How might this decision impact the way other IT projects are handled by the HBC business units and their IT support groups in the future?

8. What decision would you make regarding Robert Caldwell’s request, and why? What information, other than that provided in the case, would you like to make this decision?

9. Why might the decision makers for Robert Caldwell’s request need to include the VP of Market Development, Mario Sanchello, or the other VPs of business units? (Hint: Consider related issues that might concern all HBC business units.)

10. What are some ways to reduce the risks associated with selecting and involving stakeholders in establishing requirements?

11. Review the key concepts listed at the beginning of this case. Now that you have read the case, are there others that you would include?

Discussion

In general, the identification and selection of the stakeholders for this project was timely and effective. One potential flaw in the selection of stakeholders to help in establishing the requirements occurred when new project stakeholders “identified themselves” after the final review of the software requirements for the project. One of these new corporate-level stakeholders has requested a delay in the project that would be costly if upper-level management grants the request. This new stakeholder may or may not be able to “improve” the requirements.

The assumption that there would be no corporate-level involvement resulted in a decision to not consider stakeholders from the new Corporate IT group and Web Strategy Team. Likewise, the software project managers, Susan and Georg, assumed that they had sufficient knowledge to select the stakeholders who would be candidates for establishing the requirements. They might have reduced the risk that their assumptions were faulty by asking upper-level management as well as the other project stakeholders to review the list of candidate stakeholders and to suggest additional people who should be considered.

The case also presents the problem of allocating sufficient time to handle feedback from the verification and validation of requirements. The time scheduled for the verification and validation of the requirements was not sufficient. The time interval needed to correct errors and handle questions resulting from the review of the requirements overlapped with the week scheduled for the completion of the project agreements. Fortunately, in this case, the software project managers were able to add a week to the establishment of the requirements by using some of the extra time allocated to the project. But unfortunately, the project now has less “spare” time to handle other unexpected events that may arise in the future.

Lastly, this case raises issues regarding the corporate-level management of IT projects across independent business units. The decision to be made by upper-level management regarding the review of requirements for software projects that are “internal” to a business unit relates to these issues. In particular, the new corporate-wide focus on Web-based services highlights the need for policies regarding Web software projects to be undertaken within as well as across the business units.

Conclusions

Despite schedule and budget pressures, the software project managers decided upon a set of stakeholders who worked together effectively to establish the requirements for the New Account Project. The case problem involved the process that the software project managers used to make their decision regarding the selection of candidate stakeholders. They did not adequately consider the risks associated with their assumptions and did not have their decision reviewed by people who might have been able to find potential problems associated with their list of candidate stakeholders.

Key Ideas to Remember

• Selecting appropriate stakeholders for establishing software project requirements is critical.

• The appropriate involvement of stakeholders increases the likelihood that acceptable requirements will be established on time and within budget.

• Consulting upper-level management, people who are experienced in stakeholder selection within an organization, and other software project stakeholders helps ensure that appropriate stakeholders are identified and involved in an effective way.

Case Study: On Time, Within Budget, but Wrong

Directions

When reading this case study, focus on the activities related to eliciting, verifying, and validating the requirements for a software project. Note how the software project managers handle requests to change the requirements. Identify issues associated with identifying and selecting the appropriate functional requirements and software quality attributes.

Case Summary

Description

NavEngineering specializes in navigational systems for the DoD. NavEngineering wants to leverage its global positioning system (GPS) technology and software assets in the commercial marketplace. Management has proposed a joint venture with Signals & Systems (S&S), a company that develops radio frequency identification (RFID) tracking systems for the shipping industry. The joint venture involves the development of a GPS-RFID system to enable the secure and reliable location and tracking of packages, containers, or other goods being transported. S&S has identified target customers who are excited about the product idea and are interested in field-testing the first version of the product. The predicted time to market for this product is 18 months. Software will be a primary component of the new product. The case scenario involves product development that is on time, within budget, but not what the customers in the field test group ultimately want.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand the importance of the following decisions in eliciting the requirements:

• Which software quality attributes are important to the business needs and goals of the client or customer?

• How can requirements regarding software quality attributes be verified and validated?

• When and why should the evolution of the software be thought about and planned when establishing the requirements?

• What risks are associated with the decisions made about the requirements, and how should they be handled?

• Identify the activities by which the organization elicited, verified, and validated the requirements.

• Identify the approach that the software project managers used to handle requests to change the requirements.

• Explain the problems that occurred in the case scenario, the causes of the problems, and ways to reduce the likelihood that similar problems will occur in other software projects. Relate these to the decisions faced by project stakeholders.

Subjects Covered

Decision making, functional requirements, managing requirements change and scope, nonfunctional requirements, requirements elicitation, requirements verification, requirements validation, software evolution, and software quality attributes

Setting

The setting encompasses two privately held companies in the San Francisco Bay Area of California: NavEngineering in San Ramon and S&S in Santa Clara. NavEngineering develops GPS-based GIS systems for the DoD, and S&S develops RFID systems for the shipping industry.

Terminology

DoD: Department of Defense.

Geographical Information System (GIS): Computer-based systems that are used to store and manipulate geographic information. See Aronoff (1989) for a foundational discussion of geographical information systems.

Geographical Navigational Satellite System (GNSS): A satellite system that is used to pinpoint the geographic location of a user’s receiver anywhere in the world. Two GNSS systems are currently operational: the United States’ Global Positioning System (GPS) and the Russian Federation’s Global Orbiting Navigation Satellite System (GLONASS). A third, Europe’s Galileo, is due to be fully operational in 2013. Each of the GNSS systems employs a constellation of orbiting satellites working in conjunction with a network of ground stations (SearchNetworking.com GNSS; British National Science Center 2008).

Global Positioning System (GPS): A “constellation” of at least 24 well-spaced satellites that orbit Earth and make it possible for GPS receivers to determine their geographic location, direction, and time. The location accuracy is anywhere from 100 to 15 meters for most equipment. Accuracy can be pinpointed to within one meter with special military-approved equipment (SearchMobileComputing).

Radio Frequency Identification (RFID): A method of identifying unique items using radio waves. Typically, a reading device communicates with a tag, which holds digital information in a microchip (RFID Journal).

Selective availability (SA): A DoD program that controls the accuracy of pseudo-range measurements, degrading the signal available to nonqualified receivers by dithering the time and ephemeris data provided in the navigation message (National Park Service).

The United States removed SA on May 1, 2000, and currently has the capability to reintroduce the feature (Leopold 2000).

Software quality: The degree to which the software exhibits a desired combination of attributes (IEEE Std. 1061-1998; ISO/IEC Std. 9126-1:2001).

Software quality attributes: Characteristics that the software should exhibit. Some examples are functionality, modifiability, performance, reliability, security, and usability. See Barbacci et al. (1995) for a foundational definition of software quality attributes.

Note that functionality is a quality attribute that describes what the software is supposed to do. Nonfunctional quality attributes (such as performance and security) impose constraints on the design and implementation of software systems. Some practitioners refer to specifications regarding software quality attributes as quality of service (QoS) requirements. A requirements statement about a software quality attribute describes the degree (or the way in which) a particular attribute is to be achieved.

Software release plan: A description of how the software and its requirements are expected or likely to change over the life of the software. A product release plan outlines the functional requirements and nonfunctional requirements to be satisfied by each release of the software (Ruhe and Saliu 2005).

References

See Finkenzeller (2003) and Garfinkel and Rosenberg (2005) for information about RFID technology and its use. Borck (2006) addresses RFID interoperability, which is important for the evolution of commercial products.

Lomer (2007) provides information to support the design of navigational systems that use both Galileo and GPS signals. For a comparison of Galileo, GLONASS, and NAVSTAR (U.S. constellation of navigational satellites), read Thurston (2002). Peruse Proceedings of the IEEE International Conference on RFID for a review of current GPS research.

The Case

Scenario

Having just talked with Sharon McPherson (the requirements and customer relations manager for the NavS&S Project) using his hands-free cell phone, Daniel Choi (general manager for the NavS&S Project) drove north along Interstate Route 680 toward San Ramon, California. He watched the fog blanket the East Bay as he reflected on his conversation with Sharon and on his ill-fated vacation plans.

After countless hours spent managing the NavS&S Project (a joint venture between NavEngineering and S&S), Daniel had been relieved when the new SecureLocTracker product was sent to the field for validation by a group of selected customers called the Customer Field Test Group. He had planned to use a few days of vacation to take his sailboat, the Zephyr, out for a jaunt in the bay. After hearing Sharon’s report on the feedback from the Customer Field Test Group, Daniel grimaced and said to himself, “I might as well say goodbye to my vacation plans. This problem is too big to ignore for a few days. C’est la vie!”

As Sharon had explained to Daniel, the customers were pleased with most of the new product features; however, some of the customers had clearly expressed their disappointment with the product’s ability to accurately and reliably determine difficult-to-locate geographical positions around the world. In particular, they said that they had doubts about the product’s ability to handle locations in higher latitudes, city centers, and mountainous regions. The customers were also surprised that the product does not support the integration of GPS signals (from the U.S. NAVSTAR satellite system) and Galileo signals (to be sent from the European navigational satellite system under development) to enable more accurate and reliable positioning.

Daniel recalled that the Requirements Team had involved the customers in gathering and validating the requirements. But, as he and Sharon had discussed on the phone, maybe the team had incorrectly assumed that the existing GPS technology would be sufficient for the future of the product. The more he thought about it, Robert wondered whether the team had considered the Galileo satellite system being developed by the European Commission, European Space Agency, and private companies. In fact, he surmised that the team had focused solely on performance and security (quality attributes that had been identified as high priority by the Customer Field Test Group) without considering evolvability (the ability to easily change the product over time to satisfy new requirements).

Taking the exit for San Ramon, Daniel drove into the hills where the NavEngineering laboratories are located. His thoughts rolled back in time to the start of the project as he remembered the activities involving the elicitation of the requirements and the subsequent design and implementation of the product. Daniel recalled that the focus had been on the software because the project primarily involved developing software to integrate existing GPS and RFID technology into one system. Maybe they had not focused enough on the system that integrated both hardware and software components.

Flashback to the Start of the Project

Sharon McPherson and Daniel Choi are marketing executives with S&S and NavEngineering, respectively. In addition to their marketing work, they both had extensive experience in engineering and project management. They had carefully worked through the business issues. The integration of NavEngineering’s high-performance GPS systems with S&S’s secure RFID tracking systems was to provide a cost-effective solution for the real-time tracking of packages and containers. The shipping industry needed a solution to the security and reliability problems that plagued the transportation of goods worldwide. NavEngineering was looking to expand its business into the commercial marketplace, and S&S sought new product lines to leverage its engineering expertise. The joint venture, called the NavS&S Project, appeared to be an excellent business opportunity for both stakeholders. Some executives predicted a merger of the two companies in the future.

Sharon and Daniel provided general management for the project. Sharon managed the joint venture’s relationship with a customer user group that will field test and provide feedback on SecureLocTracker, the product to be designed and implemented by the product development teams. She also managed the team to establish the product requirements, including both system and software requirements. Daniel managed the interface between the two companies and provided upper-level project management. He was also responsible for developing the overall project management plan. Through their work on the proposal for the joint venture, Daniel and Sharon had established effective communication and planning strategies. Sharon and Daniel had shared the goal to work together as a team to guide the project to success. (Figure 2-2 shows the NavS&S Project organization.)

Figure 2-2: NavS&S Project organization

Starting with the proposal for the NavS&S Project, the Requirements Team identified the various project stakeholders. Michael Long, the lead of the Requirements Team, assigned team members to serve as points of contact for the various stakeholders. Michael provided the interface to Sharon and Daniel (the executive project managers). The team outlined processes for eliciting, verifying, and validating the system and software requirements. Since the developers at both companies as well as the target customers were comfortable with use case diagrams, the team decided to apply this technique to help elicit and document the functional requirements. One of the Requirements Team members, Martina Costilla, had used a scenario-based approach in graduate school to characterize the requirements of software systems. She explained that these scenarios would help drive the development of a software architecture that would best satisfy the software quality requirements (Bass et al. 2001). The development lead of the Software Development Team, Sanson Chen, offered to work with Martina on the definition of scenarios for the target software quality attributes.

As a preliminary step in eliciting the requirements, the Requirements Team defined the environment and context in which the SecureLocTracker system would be used. (Figure 2-3 shows the context diagram for the SecureLocTracker system.) At the time, Daniel had noted the Software Development Team’s question as to whether there would be any problems with interference between the GPS and RFID signals. The software engineers at NavEngineering had seen how long it took to design a GPS receiver that could be integrated with a wireless cellular device (a device whose radio signals could interfere with the GPS radio signals). The software engineers wanted to known whether the GPS receivers and RFID transponders would need modification. They did not want the project to be delayed because of unexpected problems with the hardware components.

Figure 2-3: SecureLocTracker system context

Through extensive interviews with the Customer Field Test Group and the development teams, the team composed a set of use cases that described in detail how the user and other external components such as the satellites and RFID tags within containers would interact with the SecureLocTracker system. The team carefully considered usage scenarios that focused on the target qualities: interoperability, performance, reliability, reusability, security, and usability. They developed precise specifications based on concrete events that were expected to happen within the context in which the software would be used. Table 2-10 presents only a sample of the nonfunctional requirements that the Requirements Team elicited with respect to the business objectives for the project.

Table 2-10: Sample of the Nonfunctional Requirements

The nonfunctional requirement NF3.1 involved the operation of the SecureLocTracker hardware components without interference from external or internal signals or devices. Part of this requirement addressed the concerns raised by the Software Development Team regarding any potential interference between the GPS receivers and RFID transponders (hardware devices to be integrated into the SecureLocTracker system).

At the time, Daniel commented to Sharon, “The Software Development Team is concerned about NF3.1. The schedule for this project is based on the assumption that existing hardware will be used with little to no modification. I wish that we would have had time to verify the existing hardware’s ability to satisfy NF3.1 before we set the project schedule. I certainly hope that this requirement does not cause problems in the future.” (Fortunately, the electronics engineers had thoroughly studied the interference issue and had designed the GPS receivers to handle any potential interference from other devices in the area.)

The Requirements Team discussed the business goal to integrate the latest GPS and RFID information system technologies developed by NavEngineering and S&S into the SecureLocTracker product. The stakeholders understood that the project would involve integrating existing hardware with some new and existing software. The Customer Field Test Group, which consisted of current users of S&S RFID systems, were interested in access to real-time location data. They thought the idea to incorporate GPS data would increase their tracking capabilities. Location data that would be accurate within 15 meters seemed adequate. The Customer Field Test Group was particularly concerned about security issues and spent a significant amount of time defining the security requirements.

Noticing that the Customer Field Test Group did not spend much time discussing positional accuracy or hard-to-locate positions within indoor environments, urban canyons, or mountainous regions, Sharon said to Daniel, “The Customer Field Test Group does not seem to be concerned about positional accuracy. I assume that this is because of their familiarity with the performance of NavEngineering GPS systems. They are focused on security issues.”

Daniel replied, “The stakeholders know that the new product will integrate our current GPS and RFID devices. I think this is why they are looking at integration and access issues such as security.”

Within four months, the system and software requirements were specified. Then the Requirements Team verified and validated the requirements. They performed walk-throughs of the use cases and inspections of the quality attribute scenarios. Several members of the Requirements Team applied Rate Monotonic Analysis (RMA), a quantitative technique to analyze the ability of the target processing system to handle the task load of software modules needed to receive and process the location and tracking data in real time. See Klein et al. (1993) for a practical guide developed by the Software Engineering Institute to analyze real-time systems using RMA.

The Software Development Team helped by benchmarking existing GPS and RFID interface and processing software that were similar to software functions that would be needed. The development team created prototypes of new software functions to be developed and analyzed their execution-time characteristics. By the time the requirements were established, the Requirements Team was confident that the requirements would direct the development of a product to meet the stakeholders’ expectations regarding scope (requirements), quality, schedule, and budget.

The development of the software and its integration with hardware took place with few surprises. The test engineers worked diligently to find bugs in the new product before handing it over to the Field Test Team. The Field Test Team had already prepared some preliminary user documentation and had briefed the customers on the functionality in the new product. The project was on schedule and within budget when the Field Test Team delivered the first release of the product to the target customers for the field test.

Daniel confided to Sharon, “Though the NavS&S Project is progressing well, I have this feeling that we missed something in establishing the requirements.”

Sharon replied in jest, “If Murphy’s Law applies to product development, a glitch will occur!” Then more seriously she said, “I think that we covered our bases well.”

More than a year passed from the elicitation of the requirements to the field test. Sharon McPherson kept the Customer Field Test Group informed about the status of the product development. But other than status information and a few updates on new product features, there was little communication with the customers until the field test. The NavS&S Project members were anxious to receive the feedback from the Customer Field Test Group.

During the past year, several of the customers had been exploring the new Galileo satellite system that was being developed in Europe to complement GPS-based location techniques. Though they had not been concerned about positional accuracy when the requirements were established, they could now envision how they would use the increased accuracy that could be achieved by using GPS and Galileo data in combination. The customers were also concerned about the SecureLocTracker’s ability to handle difficult-to-locate positions, especially places in northern latitudes (an issue of particular concern to Northern European customers).

In particular, the customers liked the idea that a dual GPS-Galileo system could provide better reliability. If the DoD decided to apply selective availability for whatever reason or if the data from either system was unavailable or degraded, backup calculations and corrections could be done more easily by having access to either GPS or Galileo data. The customers reported that by not having the ability to combine multiple signals from different navigational satellite technologies, the SecureLocTracker system would have a limited life. In addition to the European Galileo system, some of the customers were studying the Russian Global Navigation Satellite System (GLONASS) as well as the Japanese Quazi-Zenith Satellite System (QZSS), which is under development. The customers planned to explore other location-tracking systems that were to come on the market in the next six months before making their product selections.

Back to the Present

Now cloistered in his office, Daniel called back Sharon and explained, “I’ve been thinking. We need to determine how difficult it would be to evolve the SecureLocTracker product to handle multiple signals from different navigational satellite systems.”

Sharon quickly responded, “Did you hear that the President just approved the recommendation that GPS III satellites procured in the future will not support selective availability? It appears as though this aspect of reliability will not be a concern” (U.S. Department of Defense 2007).

She continued, “As we discussed earlier, I think that the first release of the product has a viable market position today. But how long will this position last? I think we need a study group to help us determine how difficult it would be to evolve the product to incorporate new technologies on the horizon for both geophysical-based location and RFID-based tracking.”

Daniel replied, “I agree, though the customers in the Customer Field Test Group seem to think that the product will soon be obsolete. How about asking the heads of the project teams to participate in the study group? We will also need to develop a proposal for the CEOs as to how to go forward with the SecureLocTracker product. We have our work cut out for us.”

“And just when you thought that you could take the Zephyr out for a sail. Maybe next year . . . ,” Sharon commiserated.

Along with a report of the results of the product field test, Sharon and Daniel are responsible for presenting to the company CEOs a proposal for how to proceed with the SecureLocTracker product. They think that the study group can help them develop a solution to the problem relating to the field test results. To start, they need more information before they can formulate a reasonable proposal.

What directives should Daniel and Sharon give to the study group?

Case Problem

A joint project team, from NavEngineering and S&S, has developed a new location and tracking system for the shipping industry. The software development was completed on schedule and within budget. The NavS&S Field Test Team has delivered the product for field tests at several key customers. The customers are disappointed that the product does not integrate multiple geophysical location technologies such as GPS and Galileo. The customers think that the system would be more reliable by having the ability to use data from different navigational satellite systems and would provide more accurate location information by combining data from multiple signals. The managers of the NavS&S project must now decide what to do in response to the feedback received from the key customers.

Case Analysis

Analysis Activity

Analysis Questions

1. How did the NavS&S Requirements Team decide to focus solely on GPS signals rather than on a combination of navigation signals from satellites managed by different countries?

• What were the PEAK inputs?

• What alternative solutions were considered (if any)? Was the use of the Galileo technology considered? If not, why not?

• What risks were associated with the solutions considered?

2. Which nonfunctional software qualities were specified in the software requirements? What technique did the Requirements Team use to specify these requirements? Why did they use this technique?

3. To what degree did the Requirements Team discuss and make plans regarding the evolution of the location and tracking product over its lifetime? How did this impact the resulting product and project outcomes?

4. To what extent did the Software Development Team consider product evolution when making software design and implementation decisions? How did this impact the resulting product and project outcomes?

5. Exactly what problem do the managers of the NavS&S project now face?

6. What information do you need to find a solution to this problem?

• What are the PEAK inputs?

• What are some alternative solutions?

• What are the risks associated with these solutions?

7. What process improvements would you make to help prevent a similar problem from occurring in the future?

8. What key concepts have you identified for this case study?