Atjaunināt sīkdatņu piekrišanu

E-grāmata: Software & Systems Requirements Engineering: In Practice

4.00/5 (9 ratings by Goodreads)
, , ,
  • Formāts: 352 pages
  • Izdošanas datums: 03-Mar-2009
  • Izdevniecība: Osborne/McGraw-Hill
  • Valoda: eng
  • ISBN-13: 9780071605489
Citas grāmatas par šo tēmu:
  • Formāts - PDF+DRM
  • Cena: 82,05 €*
  • * ši ir gala cena, t.i., netiek piemērotas nekādas papildus atlaides
  • Ielikt grozā
  • Pievienot vēlmju sarakstam
  • Šī e-grāmata paredzēta tikai personīgai lietošanai. E-grāmatas nav iespējams atgriezt un nauda par iegādātajām e-grāmatām netiek atmaksāta.
Software & Systems Requirements Engineering: In PracticePalielināt
  • Formāts: 352 pages
  • Izdošanas datums: 03-Mar-2009
  • Izdevniecība: Osborne/McGraw-Hill
  • Valoda: eng
  • ISBN-13: 9780071605489
Citas grāmatas par šo tēmu:

DRM restrictions

  • Kopēšana (kopēt/ievietot):

    nav atļauts

  • Drukāšana:

    nav atļauts

  • Lietošana:

    Digitālo tiesību pārvaldība (Digital Rights Management (DRM))
    Izdevējs ir piegādājis šo grāmatu šifrētā veidā, kas nozīmē, ka jums ir jāinstalē bezmaksas programmatūra, lai to atbloķētu un lasītu. Lai lasītu šo e-grāmatu, jums ir jāizveido Adobe ID. Vairāk informācijas šeit. E-grāmatu var lasīt un lejupielādēt līdz 6 ierīcēm (vienam lietotājam ar vienu un to pašu Adobe ID).

    Nepieciešamā programmatūra
    Lai lasītu šo e-grāmatu mobilajā ierīcē (tālrunī vai planšetdatorā), jums būs jāinstalē šī bezmaksas lietotne: PocketBook Reader (iOS / Android)

    Lai lejupielādētu un lasītu šo e-grāmatu datorā vai Mac datorā, jums ir nepieciešamid Adobe Digital Editions (šī ir bezmaksas lietotne, kas īpaši izstrādāta e-grāmatām. Tā nav tas pats, kas Adobe Reader, kas, iespējams, jau ir jūsu datorā.)

    Jūs nevarat lasīt šo e-grāmatu, izmantojot Amazon Kindle.

Publisher's Note: Products purchased from Third Party sellers are not guaranteed by the publisher for quality,  authenticity, or access to any online entitlements included with the product.







Proven Software & Systems Requirements Engineering Techniques

"Requirements engineering is a discipline used primarily for large and complex applications. It is more formal than normal methods of gathering requirements, and this formality is needed for many large applications. The authors are experienced requirements engineers, and this book is a good compendium of sound advice based on practical experience." --Capers Jones, Chief Scientist Emeritus, Software Productivity Research

Deliver feature-rich products faster, cheaper, and more reliably using state-of-the-art SSRE methods and modeling procedures. Written by global experts, Software & Systems Requirements Engineering: In Practice explains how to effectively manage project objectives and user needs across the entire development lifecycle. Gather functional and quality attribute requirements, work with models, perform system tests, and verify compliance. You will also learn how to mitigate risks, avoid requirements creep, and sidestep the pitfalls associated with large, complex projects.





Define and prioritize customer expectations using taxonomies

Elicit and analyze functional and quality attribute requirements

Develop artifact models, meta-models, and prototypes

Manage platform and product line development requirements

Derive and generate test cases from UML activity diagrams

Deploy validation, verification, and rapid development procedures

Handle RE for globally distributed software and system development projects 



Perform hazard analysis, risk assessment, and threat modeling
Industrial Foreword xvii
Academic Foreword xix
Preface xxi
Acknowledgments xxv
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
How to Read This Book
16
Summary
16
Discussion Questions
17
References
17
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
Summary
37
Discussion Questions
37
References
37
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
Summary
69
Discussion Questions
70
References
70
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
Summary
121
Discussion Questions
122
References
122
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
Summary
172
Discussion Questions
172
References
172
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
Summary
191
Discussion Questions
191
References
191
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
Summary
217
Discussion Questions
218
References
218
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
Summary
231
Discussion Questions
231
References
231
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
Summary
254
Discussion Questions
254
References
254
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
Summary
272
Discussion Questions
272
References
273
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
Summary
286
Discussion Questions
286
References
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
Summary
300
Index 301
Brian Berenbach is the technical manager of the requirements engineering competency center at Siemens Corporate Research and an ACM distinguished engineer.

Daniel J. Paulish is a distinguished member of technical staff at Siemens Corporate Research, responsible for the Siemens Software Initiative in the Americas.

Juergen Kazmeier is vice president of the Software Engineering Services Division of Siemens IT Solutions and Services, headquartered in Vienna, Austria.

Arnold Rudorfer heads the Requirements Engineering (RE) Global Technology Field with Centers of Competence in Princeton (NJ, USA), Munich and Erlangen (Europe), as well as Beijing (China).
Biežāk uzdotie jautājumi par e-grāmatām Biežāk uzdotie jautājumi par e-grāmatām
Permanent link: https://www.kriso.lv/db/97800716054892e.html
Keywords: