User-centered Requirements

The Scenario-based Engineering Process

Karen L. McGraw, Karan Harbison

• Publisher: CRC Press
• Year: 2020
• eBook ISBN: 9781000149234
• Topic: Technology & Engineering
• Subtopic: Industrial Engineering
• Index: Technology & Engineering

Developing today's complex systems requires more than just good software engineering solutions. Many are faced with complex systems projects, incomplete or inaccurate requirements, canceled projects, or cost overruns, and have their systems' users in revolt and demanding more. Others want to build user-centric systems, but fear managing the process. This book describes an approach that brings the engineering process together with human performance engineering and business process reengineering. The result is a manageable user-centered process for gathering, analyzing, and evaluating requirements that can vastly improve the success rate in the development of medium-to-large size systems and applications.

Unlike some texts that are primarily conceptual, this volume provides guidelines, "how-to" information, and examples, enabling the reader to quickly apply the process and techniques to accomplish the following goals:
* define high quality requirements,
* enhance productive client involvement,
* help clients maintain competitiveness,
* ensure client buy-in and support throughout the process,
* reduce missing functionality and corrections, and
* improve user satisfaction with systems.

This volume clearly details the role of user-centered requirements and knowledge acquisition within Scenario-Based Engineering Process (SEP) and identifies SEP products and artifacts. It assists project personnel in planning and managing effective requirements activities, including managing risks, avoiding common problems with requirements elicitation, organizing project participants and tools, and managing the logistics. Guidelines are provided for the following: selecting the right individual and group techniques to elicit scenarios and requirements from users; subject matter experts, or other shareholders; and ensuring engineers or analysts have the necessary skills.

Part I
INTRODUCTION AND FOUNDATION

Chapter 1
An Introduction to the Scenario-based Engineering Process

Computers and software programs are prevalent in our daily lives—and no longer simply as number crunching machines. Today they operate as decision aides that support complex human tasks. Furthermore, some advances in computer automation are enabling businesses to revise, enhance, and streamline long-standing business processes and roles. However, advances in the field of computer automation and consequent new uses for computer systems have outpaced developers' abilities to build systems that are responsive to users' needs.

Both systems/software engineering and business process re-engineering are providing partial responses to this problem. Systems/software engineering changes address the systems development aspect, whereas business process re-engineering activities address issues related to work process and role refinement, including cultural, organizational, and enterprise issues.

In this chapter we describe a process that marries these engineering practices, resulting in a synergy that addresses current needs in the areas of business process refinement, automation, and systems development. The chapter begins with a description of the systems development problem, followed by a brief chronology of existing systems/software engineering solutions. Next, we present a definition of the Scenario-based Engineering Process (SEP) and a discussion of the characteristics and guiding principles that define it. We then offer a more in-depth discussion of SEP as a model-based development process. Finally, we discuss the primary benefits of the SEP approach and present a rationale for its use.

This chapter is intended to provide the reader with an understanding of how the Scenario-based Engineering Process compares to existing solutions, and the contexts in which SEP is useful. It is designed to help readers meet the following goals:

• Recognize systems development problems that are not being solved with existing system/software engineering solutions.
• Build a framework for systems/software engineering against which to compare and understand SEP.
• Understand characteristics and guiding principles that define SEP.
• Identify the primary benefits of SEP.

THE SYSTEMS DEVELOPMENT PROBLEM

More than $250 billion is spent each year on information technology application development projects, with average project costs ranging from $400,000 for small companies, to over $2 million for large companies. As reported by the Standish Group (Johnson, 1995), 31% of these projects will be canceled before completion. In fact, estimates are that only 16% of software projects in the United States are completed on time and on budget. Even when a project running over budget or schedule was completed, on average only 61 % of originally specified features and functions were available in the finished project. The result of cost and time overruns, and the failure of the applications to provide expected features, is extremely costly in terms of lost opportunities, competitiveness, and user satisfaction. Figure 1.1 summarizes some of the published costs for large software projects.

As we consider the usual costs for systems development, we must also keep in mind that development costs are only the "tip of the iceberg." Figure 1.2 displays an example ratio of a project's tasks and the percentage of total costs that can be attributed to each task. The percentage of costs for maintenance (67%) relative to other tasks is quite high. Most maintenance costs are a result of effort expended providing required, but missing functionality, making corrections, and dealing with compatibility issues. Each of these issues relates to requirements, and obviously, developers would like to find ways to reduce these costly expenditures. If these maintenance costs reflected extensions, newfeatures, and integration into other systems, the ratio might be more acceptable. The improved use of maintenance costs is one of the goals for new systems/software engineering processes.

Certainly, the development process has been and continues to be a major issue. Many factors contribute to the problems of delivering computer-based systems. The Standish Group (Johnson, 1995) reports reasons for project failure that include lack of user involvement, lack of executive management support, poorly stated or incomplete requirements, and politics. Individual developers report problems ranging from insufficient memory to cultural shock. Common complaints include inadequate tools, con

FIG. 1.1. Published costs for software development projects (data from Johnson, 1995).

FIG. 1.2. Percentage of an average project's costs throughout its lifecycle.

figuration management nightmares, shifting requirements, and the artistic nature of software engineering.

Problems regularly mentioned by customers include late delivery, invalid information, unfriendly user interfaces, lack of documentation, applications that do not support their needs, and numerous bugs. Commonly heard user complaints include:

• "My software is not upward compatible!"
• "It takes too many keystrokes!"
• "I don't have a hand free to type!"
• "The font is too small!"
• "I was promised this three months ago!
• "This new system increases my call handle time!"
• "Why can't I put this drawing in this file!"

A BRIEF CHRONOLOGY OF SYSTEMS/SOFTWARE ENGINEERING

There have been many attempts to enhance the management and efficiency of software application development. For years, systems/software engineers have used conventional or traditional approaches such as the waterfall model (Boehm, 1981) for some classes of problems. As projects began addressing knowledge-intensive problems, techniques such as artificial intelligence were used, requiring rapid prototyping approaches

TABLE 1.1. Characteristics of Traditional/Conventional Problems and Knowledge-Intensive Problems

Traditional Problems	Knowledge-Intensive Problems
• Calculating rapidly, with high accuracy	• Learning from experience
• Controlling simple, large forces smoothly and with great precision	• Perceiving patterns
• Storing vast amounts of numeric and alphanumeric data	• Dealing effectively with people
• Manipulating data with great speed	• Understanding images
• Operating reliably and predictably

to solve development problems (Hayes-Roth, Waterman, & Lenat, 1983). Table 1.1 compares some characteristics of the traditional and knowledgeintensive classes of problems (McGraw & Harbison-Briggs, 1989).

When systems/software development problems escalate in complexity and size, different lifecycle approaches are required. These often include userdriven or user-centered process, architecture-based solutions, iterative development, and quick or rapid prototyping. These relatively new lifecycle approaches are currently being tested against today's development problems.

The transition from traditional approaches to complex systems approaches can be represented historically by some major milestones. Figure 1.3 depicts a transition from traditional code integration, through Structured Analysis and Design Techniques (SADT), into component-based design, and finally to an emphasis on users and their needs. As this historical progression indicates, today there is much more of an emphasis on user involvement and satisfaction in systems development.

FIG. 1.3. Progression of software engineering.

Systems developers realize they are on the "high velocity" end of the learning curve for engineering large, complex systems. These systems are the target of significant research and development in science and engineering. Solving the problems in large, complex systems development requires the joint effort of investigators in multiple disciplines—computer science, engineering, mathematics, cognitive science, sociology, physics, and information systems to name a few. These problems are also forcing participants in domains and development areas to collaborate on standards, protocols, and definitions.

THE SCENARIO-BASED ENGINEERING PROCESS (SEP)

Some members of the disciplines noted previously, in cooperation with domain performers and system users, have developed an engineering process to address needs in large, complex systems development. Rather than "reinventing the wheel," we have attempted to pull together useful concepts from various development approaches for use in engineering complex systems. These include those shown in Table 1.2. We have concentrated on providing a high-level conceptual process that describes what to do rather than how to do it. Within these "what" guidelines, developers can use their own techniques and favored methodologies, and choose tools and representations that work for them. This overall process has been named the Scenario-based Engineering Process (SEP).

Definition and Applicability

SEP is a user-centered methodology for systems or business process engineering that employs the use of scenarios to scope, bound, and focus

TABLE 1.2. SEP Reflects Components and Features of Various Software Engineering Concepts and Approaches

Feature or Component of SEP	Source
• Structured analysis and design	• Conventional systems (development of procedural, well defined, well understood tasks)
	• Department of Defense 2167a
• Quick prototyping	• Intelligent or knowledge-based systems (development of well focused, tightly scoped cognitive tasks)
• User-centered systems engineering
• Domain-specific system architectures	• Complex systems...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Contents
• Acknowledgments
• PART I—INTRODUCTION AND FOUNDATION
• PART II—PROCESS & TECHNIQUES
• References
• Author Index
• Subject Index