Title:
A requirements pattern : succeeding in the internet economy
Personal Author:
Publication Information:
Reading, Mass. : Addison-Wesley, 2002
ISBN:
9780201738261
Available:*
Library | Item Barcode | Call Number | Material Type | Item Category 1 | Status |
---|---|---|---|---|---|
Searching... | 30000010022714 | QA76.76.D47 F49 2002 | Open Access Book | Book | Searching... |
On Order
Summary
Summary
This title identifies the problems of requirement management for the development of Internet based applications. It defines the evolutionary process of a requirement from the conceptual idea to the implemented feature.
Author Notes
Patricia L. Ferdinandi is the President of Strategic Business Decisions, Inc.
Excerpts
Excerpts
Corporations today allocate billions of dollars to information technology (IT), not only to stay afloat but also to expand market share in the fast-paced global marketplace. The combination of hardware, software, and networks provides valuable information and performs critical functions for a corporation, its stockholders, and clients. Indeed, information technology has become the backbone of the modern corporation. Without successful and high-quality IT solutions, the success of a corporation can be compromised. Defects in IT products can result in missed market opportunities, ineffective strategic decisions, and lost market share. The first step toward developing, enhancing, or maintaining IT solutions is to understand the needs and wants of the business. This is the most challenging part of the entire effort. As you will discover in this book, if you get the requirements wrong, the final product will not satisfy the needs of the business. In fact, this wasted effort will cost the company greatly. The Standish Group has been following failed IT projects since 1995. Across the board, the researchers have found poor requirements, in one form or another, to be one of the top causes of costly project failures. "Poor requirements" refers to a failure to capture the needs that must be satisifed by the solution. Typically, failures in IT projects are not the fault of an individual or even a department. Nor are these failures the fault of a specific technique or tool used to gather the requirements of a project. The problem, more often, lies in misunderstanding the definition, process, practices, and management of requirements. In the end, requirements have a major impact on a project's success. The project may be done on time and within budget, but unless the requirements are complete and accurate, the project will be a failure. Requirement is an ambiguous term. Different people will provide valid but different points of view, with perhaps some overlap. There lies the problem! Our individual views of requirements have been narrow, allowing for gaps that lead to defects in the final product. The final set of requirements may turn out to be full of intangible, moving targets that are inherently inconsistent. This leads to a poor-quality product, which in turn diminishes the return on investment for the corporation. Why This Book? The purpose of this book is to clarify this ambiguity. The book focuses on several perspectives designed to create a common understanding of requirements, from concept through implementation. The evolution, classification, and management of requirements are placed in easy-to-understand terms, so that everyone can share a common level of understanding. A framework is provided that categorizes and organizes the different types of requirements, forming a requirements set. The requirements pattern, based on the requirements set framework, is provided to assist in capturing and evolving the individual requirements. Information on the best requirement-related practices is provided to ensure the quality and integrity of the individual requirements and the requirements set. The ideas in A Requirements Pattern can be applied to any product (including non-IT-oriented ones). The Internet is used here primarily for illustrative purposes. This volatile environment provides many examples that clearly explain the four key topics of this book: 1. The breadth of requirements that comprise the requirements set 2. The evolutionary process of a requirement from the conceptual idea to the implemented feature 3. The need to initiate parallel and coordinated requirement development efforts 4. The impact of change (including scope creep) on Internet products By understanding the concepts presented, you will be able to see the gaps created with current methodologies, methods, and techniques. It is important to be able to see that requirements are not just documentation but rather a full understanding of the problem, the environment in which requirements are developed, and the delivered features of the solution. The generic role responsible for requirement-related activities is the requirements engineer, the primary audience for this book. Requirements engineers must have a detailed understanding of the requirements process and the valuable role requirements engineers play in maximizing the product's return on investment. The more they understand, the better equipped they will be to tackle the nuances of the Internet. Technical analysts and architects many times must gather specific types of requirements and therefore will also benefit from reading this book. Each may have a different focus during the development process. It is important to realize the impact their requirements have on other areas of the project. Even if the analysts and architects are not involved in eliciting the business requirements, they will have an impact on those requirements. These personnel need to have an understanding of the evolution of the requirements from inception until they are allocated for development. The quality of requirements has a direct impact on the cost of the final product. It is the job of the quality control analyst to assist with validating the specified requirements for possible defects, a topic addressed in A Requirements Pattern . By understanding how to identify the quality of a requirement, quality control analysts can actively participate in validation. They contribute to the requirements process by identifying inconsistencies long before code testing. Many books already exist on the requirements process, techniques, and methods. Other books address what good requirements are as well as various elicitation, analysis, verification, and management techniques. Examples of such books are provided in the Additional Resources section at the back of the book. This helpful compilation provides suggestions for a continual path of education in the field of requirements engineering. The Internet requirements pattern presented in this book complements all of the recommendations by introducing readers to the basics of requirements, requirements engineering, and requirements management. Requirements engineering is an integral part of developing software. It is time consuming and at times a tedious activity. The size and type of a project seem to have little effect on the complexity of this process. The incorporation of the Internet requirements pattern (and anti-patterns) and activities described in this book will enhance the requirements engineer's efforts. With the fuller understanding of requirements, readers can make positive impacts when developing quality solutions for their companies. Pat Ferdinandi June 2001 0201738260P11052001 Excerpted from A Requirements Pattern: Succeeding in the Internet Economy by Patricia Ferdinandi All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.Table of Contents
Preface | p. xv |
Acknowledgments | p. xix |
Chapter 1 Requirements Engineering for Internet Products: an Introduction | p. 1 |
Chapter Key Topics/The Internet Impact | p. 1 |
The Power of the Internet | p. 3 |
Defining Requirements Engineering | p. 7 |
Requirements Engineering and the Internet | p. 8 |
The State of Requirements Today | p. 9 |
Defining Technology's Involvement | p. 10 |
A Paradoxical View | p. 10 |
Affecting the Return on Investment | p. 11 |
Requirements Engineering Skill Set | p. 11 |
Identifying Requirements for Business | p. 12 |
The Need for Clear, Concise, and Organized Requirements | p. 13 |
Getting Business Units Involved | p. 13 |
The Right Person for the Job | p. 14 |
The Need for Parallel Efforts | p. 15 |
An Easy-to-Follow Process | p. 16 |
Improving Communication | p. 16 |
Keeping the Team Apprised of All Requirements | p. 18 |
A Flexible and Evolving Process | p. 18 |
The Internet and Requirements Engineering: Working Together | p. 19 |
The Collapsing Hierarchy Structure | p. 19 |
Blurred Corporate Lines and Business Partnerships | p. 20 |
New Lines of Business | p. 21 |
Customer-Centric versus Cost-Cutting Focus | p. 21 |
Profits versus Potential Revenue | p. 22 |
Putting It All Together | p. 22 |
Terminology: A Common Understanding | p. 23 |
Conclusion | p. 36 |
Chapter 2 Requirement Evolution | p. 37 |
Chapter Key Topics/The Internet Impact | p. 37 |
Evolution of Requirements | p. 38 |
The Internet Development Process | p. 39 |
The Requirements Development Process | p. 41 |
The Birth of an Idea | p. 42 |
The Business Concept | p. 45 |
Building a Business Case | p. 46 |
Scoping Requirements | p. 47 |
The Requirements Process | p. 49 |
Allocation of Requirements | p. 50 |
Avoiding Politics | p. 52 |
Why a Process? | p. 56 |
Requirements Process Scenario | p. 58 |
The Correlation between Allocation Level and Perspective | p. 59 |
Requirements Evolving through Perspectives | p. 59 |
The Requirements Subprocess | p. 60 |
Requirements Analysis | p. 64 |
Specification | p. 65 |
Validation | p. 66 |
Approval as a Separate Activity | p. 68 |
Quality Gate Checkpoints | p. 69 |
Managing the Requirements and the Requirements Set | p. 69 |
The Subprocess Is a Generic Process | p. 70 |
Reuse of Requirements | p. 71 |
Conclusion | p. 71 |
Chapter 3 The Requirements Set | p. 73 |
Chapter Key Topics/The Internet Impact | p. 73 |
Requirement Categories | p. 75 |
Requirement Community | p. 75 |
Requirement Perspective | p. 79 |
Requirement Focus | p. 79 |
Relationships between Categories | p. 80 |
Requirement Organization | p. 80 |
A Quality Home | p. 81 |
The House That Zachman Built | p. 82 |
Different Perspectives for Either Process | p. 83 |
Different Perspectives for Requirements | p. 84 |
Different Views of the Same House | p. 86 |
Different Focuses of the Same Software Solution | p. 87 |
Volumetrics | p. 94 |
Extensions to the Information Systems Architecture | p. 95 |
Additional Focuses | p. 95 |
Product Constraints | p. 97 |
Adaptability Requirements | p. 97 |
Reliability Requirements | p. 98 |
Scalability Requirements | p. 99 |
Security Requirements | p. 102 |
Usability Requirements | p. 103 |
Maintainability Requirements | p. 104 |
Project Constraints | p. 104 |
Adding Community to the Infrastructure | p. 105 |
Requirement Associations | p. 108 |
Organization Impact | p. 112 |
Conclusion | p. 113 |
Chapter 4 The Internet Requirements Pattern | p. 117 |
Chapter Key Topics/The Internet Impact | p. 117 |
The Kickoff | p. 119 |
Changing the Business Model | p. 119 |
Understanding the Problem or Need | p. 120 |
Preparing for Allocation | p. 121 |
The Pattern Specifics | p. 124 |
Community Allocation | p. 125 |
Important Community Specifics | p. 125 |
Focus Details | p. 140 |
Cell Association Checklist | p. 152 |
Gap Analysis | p. 153 |
Conclusion | p. 154 |
Chapter 5 Internet Requirements Anti-Patterns | p. 159 |
Chapter Key Topics/The Internet Impact | p. 159 |
Gaps in Knowledge | p. 161 |
Predators: Hacker Intervention and Other Security Issues | p. 162 |
Quality of Service Impact | p. 168 |
Create, Read, Update, Delete, and List | p. 171 |
Gaps in Participation | p. 174 |
Involvement of Network Engineers | p. 174 |
Business Model Tolerance Indicators | p. 177 |
Click-Stream Data | p. 181 |
Gaps in Process | p. 184 |
Scope Creep | p. 184 |
Technology for the Sake of Technology | p. 187 |
Imposed Deadlines | p. 188 |
Creating Additional Anti-Patterns | p. 190 |
Basic Information to Include in an Anti-Pattern | p. 192 |
Review and Use of Created Anti-Patterns | p. 196 |
Conclusion | p. 197 |
Chapter 6 Requirement Quality | p. 199 |
Chapter Key Topics/The Internet Impact | p. 199 |
Quality of the Individual Requirements | p. 200 |
Quality Characteristics | p. 200 |
Guidelines for Better Requirement Writing | p. 203 |
Tool Implications | p. 205 |
Quality of the Requirements Specification | p. 206 |
Quality of the Requirements Set | p. 207 |
Implementing Quality Procedures | p. 210 |
Quality-Checking Techniques | p. 212 |
Prototyping the Requirements | p. 220 |
Scope-Level Prototypes | p. 220 |
Business-Level Prototypes | p. 220 |
Designer-Level Prototypes | p. 221 |
Builder-Level Prototypes | p. 221 |
Subcontractor-Level Prototypes | p. 221 |
Conclusion | p. 222 |
Chapter 7 Managing the Requirements Set | p. 223 |
Chapter Key Topics/The Internet Impact | p. 223 |
The Objectives of Requirements Management and Configuration Management | p. 225 |
The Capability Maturity Model of the Software Engineering Institute | p. 226 |
Key Process Areas for CMM Level 2 | p. 228 |
Interpreting the Capability Maturity Model | p. 229 |
What Is Configuration Management? | p. 230 |
Tools for Managing Requirements | p. 231 |
Requirements Specification Tools | p. 232 |
Requirements Management Tools | p. 233 |
Configuration Management Tools | p. 233 |
Integrating Tools for Configuration Management | p. 234 |
The Configuration Management Process | p. 234 |
Configuration Management States for Requirements | p. 238 |
Baselines and Libraries | p. 238 |
Authorizing Changes to Requirements | p. 243 |
The Components of Configuration Management | p. 247 |
The Benefits of Configuration Management | p. 250 |
Configuration Management for Requirements | p. 250 |
Implementing Configuration Management for Requirements for Internet-Type Applications | p. 253 |
What Needs to Be Managed? | p. 253 |
Proper Staffing for Maintaining the Integrity of the Requirements | p. 259 |
Preparing for Implementation | p. 261 |
The Implementation Process | p. 262 |
Conclusion | p. 264 |
Chapter 8 Roles and Responsibilities | p. 267 |
Chapter Key Topics/The Internet Impact | p. 267 |
Requirement Suppliers | p. 268 |
Product Direction Roles | p. 268 |
Requirement Detail Roles | p. 272 |
Requirement Users | p. 275 |
Requirement Supporters | p. 282 |
Requirement Producers | p. 285 |
Common Deliverables | p. 285 |
Meeting Minutes | p. 286 |
Requirements Engineering Roles | p. 287 |
Necessary Skills for Requirements Engineers | p. 294 |
Practical Experience | p. 296 |
Engineering Knowledge | p. 296 |
Project Management Skills | p. 298 |
Understanding of Techniques and Tools | p. 298 |
Knowledge about Quality Issues | p. 299 |
Personality and People Skills | p. 299 |
The Requirements Engineering Organization | p. 300 |
Organizational Styles | p. 300 |
Support for Responsibilities in All Organizational Styles | p. 303 |
The Internet Organization | p. 306 |
Conclusion | p. 308 |
Chapter 9 Parting Thoughts | p. 311 |
Chapter Key Topics/The Internet Impact | p. 311 |
How Long Will This Take? | p. 314 |
Planner Perspective Estimation | p. 315 |
Owner Perspective Estimation | p. 316 |
Designer Perspective Estimation | p. 318 |
How to Get Started | p. 320 |
Applying the Requirements Pattern to Other Application Types | p. 321 |
Key Points to Remember | p. 322 |
Conclusion | p. 323 |
Appendix A Internet Requirements Pattern Specification Format | p. 325 |
Appendix B Internet Requirements Pattern for the Information Technology Community | p. 337 |
Appendix C Requirements Pattern Work Breakdown Structure | p. 399 |
Appendix D Requirements Pattern Language | p. 423 |
Appendix E The Pattern at Work | p. 445 |
Glossary | p. 457 |
Bibliography | p. 475 |
Additional Resources | p. 481 |
Index | p. 487 |