Software and systems requirements engineering : in practice / Brian Berenbach ... [et al.].

CONTENIDO
1 Introduction 1
Why Has Requirements Engineering Become So Important? 2
Misconceptions about Requirements Engineering 3
Misconception 1: Any Subject Matter Expert Can Become a Requirements Engineer after a Week or Two of Training 4
Misconception 2: Nonfunctional and Functional Requirements Can Be Elicited Using Separate Teams and Processes 4
Misconception 3: Processes That Work for a Small Number of Requirements Will Scale 4
Industrial Challenges in Requirements Engineering 4
Key Success Factors in Requirements Engineering 5
The Project Has a Full-Time, Qualified Chief Architect 5
A Qualified Full-Time Architect Manages Nonfunctional Requirements 5
An Effective Requirements Management Process Is in Place 6
Requirements Elicitation Starts with Marketing and Sales 6
Requirements Reviews Are Conducted for All New or Changed Requirements or Features 6
Requirements Engineers Are Trained and Experienced 6
Requirements Processes Are Proven and Scalable 6
Subject Matter Experts Are Available as Needed 6
All Stakeholders Are Identified 7
The Customer Is Properly Managed 7
Progress and Quality Indicators Are Defined 7
The RE Tools Increase Productivity and Quality 7
The Core Project Team Is Full Time and Reports into a Single Chain of Command 7
Definition of Requirements Engineering 8
Requirements Engineering's Relationship to Traditional Business Processes 8
Characteristics of a Good Requirement 9
Feasible 9
Valid 10
Unambiguous 10
Verifiable 11
Modifiable 11
Consistent 11
Complete 12
Traceable 13
Other Project- or Product-Specific Characteristics 13
Characteristics of a Good Requirements Specification 14
Requirements and Project Failure 15
Quality and Metrics in Requirements Engineering 15
Function Point Metrics as Leading Indicators 16
2 Requirements Engineering Artifact Modeling 19
Introduction 20
RE Taxonomy 21
Taxonomy Attributes 24
Creation of an RE Taxonomy 24
Other Types of Taxonomies Useful in RE 25
Taxonomy Extension 26
RE Artifact Model 27
Elements of an Artifact Model 27
Creation of a Requirements Engineering Artifact Model 28
Using the Artifact Model 30
Extending an Artifact Model to Augment Process Definition 30
Using Templates for Requirement Artifacts 30
Dynamic Tailoring of an Artifact Model 34
Organizational Artifact Model Tailoring 34
Creating a System Life Cycle Process 35
Tips for Requirements Engineering Artifact Modeling 36
3 Eliciting Requirements 39
Introduction 40
Issues and Problems in Requirements Elicitation 41
The Missing Ignoramus 41
The Wrong Stakeholders 42
Untrained Analysts 42
Not Identifying Requirements Level 42
Failure to Accurately Identify Stakeholders 43
Problems Separating Context from Requirement 44
Failure to Collect Enough Information 44
Requirements Are Too Volatile 45
System Boundaries Are Not Identified 45
Understanding of Product Needs Is Incomplete 46
Users Misunderstand What Computers Can Do 47
The Requirements Engineer Has Deep Domain Knowledge 47
Stakeholders Speak Different Natural and Technical Languages 47
Stakeholders Omit Important, Well-Understood, Tacit Information 48
Stakeholders Have Conflicting Views 48
Requirements Elicitation Methods 48
Eliciting Business Goals 49
Ethnographic Techniques 52
Prioritization and Ranking of Requirements 53
Quality Function Deployment (QFD) Method 55
Brainstorming Sessions 55
Tabular Elicitation Techniques 56
Process Modeling Techniques 58
Customer-Specific Business Rules 62
Why Are Customer-Specific Business Rules Important? 62
What Are Their Characteristics? 62
Example Customer-Specific Business Rules 63
Managing the Customer Relationship 64
Managing Requirements Elicitation 64
Planning Elicitation Sessions 64
Requirements and Cost Estimation 67
Requirements Elicitation for Incremental Product Development 67
Tips for Gathering Requirements 68
4 Requirements Modeling 73
Introduction 74
Model-Driven Requirements Engineering (MDRE) 79
Advantages of an MDRE Approach 84
Using MDRE to Estimate Project Size and Cost 85
Improved Management of Cross-Cutting Requirements 85
Navigation of Complex System Requirement Sets 86
Rapid Review of Business Processes and Requirements Relationships 86
Metrics for Quality and Progress 86
Semiautomatic Generation of Project Plans and Requirements Database Content 86
Prerequisites for Using MDRE 87
Modeling Skills Not Readily Available 87
Inadequate Tooling 87
Organization Not Ready for MDRE 87
MDRE Processes 88
Initial Understanding 88
Understanding the Context and How the Product Will Be Used 90
Analyzing Product Features and Creating a Use Case Model 92
Extracting Requirements from the Model 94
Starting an MDRE Effort 96
Managing Elicitation and Analysis Sessions 96
Improved Productivity Through Distributed Modeling 98
Conducting Model Reviews 98
Elicitation and Analysis Model Heuristics 99
The Model Should Have a Single Entry Point 99
All Actors Associated with the System Being Analyzed Should Appear on the Context Diagram 99
The Early Modeling Effort Should Cover the Entire Breadth of the Domain 100
Identify "Out-of-Scope" Use Cases as Early as Possible 100
Every Diagram Should Have an Associated Description and Status 100
Avoid the Early Use of Packages 101
Do Not Substitute Packages for Abstract Use Cases 101
Every Artifact in a Model Should Be Visible on a Diagram 101
Every Symbol Should Have a Bidirectional Hyperlink to the Diagrams That Define It 102
Package Dependencies Should Be Based on Content 102
Every Concrete Use Case Must Be Defined 102
Use an Activity Diagram to Show All Possible Scenarios Associated with a Use Case 105
Use Sequence Rather Than Collaboration Diagrams to Define One Thread/Path for a Process 105
Abstract Use Cases Must Be Realized with Included or Inherited Concrete Use Cases 107
Extending Use Case Relationships Can Only Exist Between Like Use Cases 108
A Concrete Use Case Cannot Include an Abstract Use Case 108
Avoid Realization Relationships and Artifacts in the Analysis Model 108
Business Object Modeling 108
Coherent Low-Level Processes Should Be Defined with State or Activity Diagrams 112
Elicit Requirements and Processes by Starting at Boundaries and Modeling Inward 112
Hide Complexity by Using Compound Business Objects 112
Initiate Prototyping Efforts Quickly 112
Determining Model Completeness 113
Diagram Quality 113
Content Correctness 113
Model Faults That Should Be Corrected Before a Model Is Completed 113
Transitioning from Analysis to Design 115
Suggested Model Conversion Heuristics 115
Design Model Package Structure 115
Use Case Tracing 115
Interface Tracing 115
Artifact Tracing 115
Design Model Structure 117
Tracing Requirements Through the Design Model 117
Intermodel Quality Assurance Checks 117
Design Model Initial Construction 118
Use of Tooling for MDRE 120
Tips for Modeling Requirements 120
5 Quality Attribute Requirements 125
Why Architectural Requirements Are Different 126
Terminology 127
An Integrated Model 130
Quality Attribute Scenarios 131
Quality Attribute Requirements 131
Factors, Issues, and Strategies 132
Product Architecture 132
Quality Attribute Requirements 132
Selecting Significant Stakeholders 140
Identifying Potential Stakeholders 141
Methods for Architectural Requirements Engineering 142
Quality Attribute Workshop 143
Goal Modeling 145
Global Analysis 146
Testing ASRs 154
Case Study: Building Automation System 156
Features That Define the Product 157
Forces That Shape the Architecture 159
Constraints on the Architecture 160
Architectural Drivers 161
Architecture Design 162
Modeling the Domain 164
Performance Modeling 164
Practice and Experience 168
Impact of Business Goals 168
The Notion of Quality 169
Integration of Functional Requirements, Quality Attributes, and Architecture 170
Tips for Quality Attribute Requirements 171
6 Requirements Engineering for Platforms 175
Background 176
Challenges 177
Practices 178
Define Questionnaires 180
Elicit the Stakeholders' Inputs 181
Unify Terminology 181
Normalize Stakeholders' Inputs 181
Reconcile Stakeholders' Inputs 182
Define the NFRs for the Platform 182
Derive the NFRs for the Components 183
Check for Consistency 184
Check for Testability 185
Complete the Constraints 185
Tune the NFRs for Feasibility 185
Complete NFRs 186
Formal Review by Stakeholders 186
Experience 186
Define the Questionnaires and Elicit the Stakeholders' Inputs 186
Unify Terminology 187
Normalizing and Reconciling Stakeholders' Inputs 188
Derive the NFRs for the Software Platform 190
Check for Testability and Complete the Constraints 190
Tips for RE for Platforms 190
7 Requirements Management 193
Background 194
Change Management 195
Impact Analysis 197
Derivation Analysis 198
Coverage Analysis 198
Routine Requirements Management Activities 198
Identifying Volatile Requirements 198
Establishing Policies for Requirements Processes and Supporting Them with Workflow Tools, Guidelines, Templates, and Examples 199
Prioritizing Requirements 199
Establishing and Updating the Requirements Baseline 199
Documenting Decisions 199
Planning Releases and Allocating Requirements to Releases 199
Traceability 200
Goal-Based Traceability 202
Types of Traces 202
Example Engineering Project-Based Traceability Model 202
Measurement and Metrics 204
Project Metrics 205
Quality Metrics 205
Scalability 207
Creation of a Requirements Management Process 207
Measuring Savings with RE Processes 209
Organizational Issues Impacting Requirements Management 210
Creating a Requirements Database 210
Managing Requirements for Product Lines 213
Tips for Requirements Management 215
Best Practices 215
8 Requirements-Driven System Testing 219
Background 220
Requirements Engineering Inputs for Testing 222
Model-Based Testing 222
Testing Performance and Scalability Requirements 227
Rules of Thumb/Best Practices 228
Reviewing Models 229
Improved Test Coverage 229
Tracing to Requirements 229
Start Early in the Development Life Cycle 229
Improved Efficiency 230
9 Rapid Development Techniques for Requirements Evolution 233
Background 234
When to Prototype 236
Early Requirement Elicitation 236
Conflicting or Nonprioritized Requirements 237
Bridge the Skills of Stakeholders and Developers 238
Capture Detailed Requirements 238
Time-to-Market 239
Practices and Experience 240
Requirements Engineering and Prototype Development in Parallel 240
Identify and Eliminate Stakeholder Conflicts 243
Rapid Iteration of Requirements/Stakeholder Feedback 244
Storyboarding 246
Executable Prototypes 248
Transparency 250
Testing 250
Modification Optimization 251
Tips for Prototyping 252
10 Distributed Requirements Engineering 257
Background 258
Requirements Engineering for Global Projects 260
Organizations for Distributed Projects 261
Managing Distributed RE Efforts 266
Requirements and Collaboration Tools 267
Communications, Culture, and Team Size 269
RE with OEMs and Suppliers 270
Tips for Distributed Requirements Engineering 271
11 Hazard Analysis and Threat Modeling 275
Hazard Analysis 276
Terms Used in Hazard Analysis 276
Hazard Analysis Processes 277
Reflecting Actions into the Requirements Database 280
Hazard Analysis and MDRE 281
Importance of Hazard Analyses 282
Threat Modeling 284
Basic Terminology 284
Threat Modeling and MDRE 285
Threat Modeling Metrics 286
12 Conclusion 287
A Configuring and Managing a Requirements Database 291
Introduction 292
Prerequisites for the Use of a Requirements Database 293
RDB Basic Features 295
RDB Advanced Features 297
Automatic Upward Propagation of Attributes 297
Automatic Downward Propagation of Attributes 298
Unique Needs for a Product Line RDB 299
Multidimensional Support 299
Generation of Product Maps 299