Software & systems requirements engineering: in practice:
Gespeichert in:
| Format: | Buch |
|---|---|
| Sprache: | English |
| Veröffentlicht: |
New York [u.a.]
McGraw-Hill
2009
|
| Schlagworte: | |
| Online-Zugang: | Inhaltsverzeichnis |
| Beschreibung: | XXV, 321 S. Ill., graph. Darst. |
| ISBN: | 9780071605472 0071605479 |
Internformat
MARC
| LEADER | 00000nam a2200000zc 4500 | ||
|---|---|---|---|
| 001 | BV036765607 | ||
| 003 | DE-604 | ||
| 005 | 20130709 | ||
| 007 | t | ||
| 008 | 101109s2009 ad|| |||| 00||| eng d | ||
| 010 | |a 2009002434 | ||
| 020 | |a 9780071605472 |9 978-0-07-160547-2 | ||
| 020 | |a 0071605479 |9 0-07-160547-9 | ||
| 035 | |a (OCoLC)836810011 | ||
| 035 | |a (DE-599)HEB22255312X | ||
| 040 | |a DE-604 |b ger | ||
| 041 | 0 | |a eng | |
| 049 | |a DE-M347 |a DE-91G |a DE-384 | ||
| 084 | |a ST 237 |0 (DE-625)143623: |2 rvk | ||
| 084 | |a DAT 335f |2 stub | ||
| 245 | 1 | 0 | |a Software & systems requirements engineering: in practice |c Brian Berenbach ... |
| 264 | 1 | |a New York [u.a.] |b McGraw-Hill |c 2009 | |
| 300 | |a XXV, 321 S. |b Ill., graph. Darst. | ||
| 336 | |b txt |2 rdacontent | ||
| 337 | |b n |2 rdamedia | ||
| 338 | |b nc |2 rdacarrier | ||
| 650 | 0 | 7 | |a Requirements engineering |0 (DE-588)4213997-1 |2 gnd |9 rswk-swf |
| 650 | 0 | 7 | |a Software Engineering |0 (DE-588)4116521-4 |2 gnd |9 rswk-swf |
| 689 | 0 | 0 | |a Requirements engineering |0 (DE-588)4213997-1 |D s |
| 689 | 0 | 1 | |a Software Engineering |0 (DE-588)4116521-4 |D s |
| 689 | 0 | |5 DE-604 | |
| 700 | 1 | |a Berenbach, Brian |e Sonstige |4 oth | |
| 856 | 4 | 2 | |m GBV Datenaustausch |q application/pdf |u http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=020682559&sequence=000001&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA |3 Inhaltsverzeichnis |
| 999 | |a oai:aleph.bib-bvb.de:BVB01-020682559 | ||
Datensatz im Suchindex
| _version_ | 1804143434748919808 |
|---|---|
| adam_text | IMAGE 1
SOFTWARE & SYSTEMS
REQUIREMENTS ENGINEERING:
IN PRACTICE
BRIAN BERENBACH
DANIEL J. PAULISH JUERGEN KAZMEIER ARNOLD RUDORFER
MC GRAW HILL
NEW YORK CHICAGO SAN FRANCISCO LISBON LONDON MADRID MEXICO CITY MILAN
NEW DELHI SAN JUAN SEOUL SINGAPORE SYDNEY TORONTO
TECHNISCHE
IN FOR MAT! O N S3! BLIOTHEK
UNIVERSITATSBIDLIOTHEK HANNOVER
IMAGE 2
CONTENTS
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 AFTERA 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 OFREQUIREMENTS
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
VII
IMAGE 3
VIII SOFTWARE & SYSTEMS REQUIREMENTS ENGINEERING: IN PRACTICE
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 TIMEAND REPORTS INTO A SINGLE CHAIN OF
COMMAND 7
DEFINITION OFREQUIREMENTS 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
RETAXONOMY 21
TAXONOMY ATTRIBUTES 24
CREATION OF AN RE TAXONOMY 24
OTHER TYPES OFTAXONOMIES USEFUL IN RE ... 25 TAXONOMY EXTENSION 26
RE ARTIFACT MODEL 27
ELEMENTS OF AN ARTIFACT MODEL 27
IMAGE 4
CONTENTS IX
CREATION OFA REQUIREMENTS ENGINEERING ARTIFACT MODEL 28
USING THE ARTIFACT MODEL 30
EXTENDING AN ARTIFACT MODEL TO AUGMENT PROCESS DEFINITION 30
USING TEMPLATES FORREQUIREMENT 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 INREQUIREMENTS 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 OFPRODUCT NEEDS IS
INCOMPLETE 46
USERS MISUNDERSTAND WHAT COMPUTERS CAN DO 47
THE REQUIREMENTS ENGINEER HAS DEEP DOMAINKNOWLEDGE 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
ELICITINGBUSINESS GOALS 49
ETHNOGRAPHIC TECHNIQUES 52
PRIORITIZATION ANDRANKING OF REQUIREMENTS 53
IMAGE 5
X SOFTWARE & SYSTEMS REQUIREMENTS ENGINEERING: IN PRACTICE
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 INCREMENTALPRODUCT 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
IMPROVEDMANAGEMENT OF CROSS-CUTTING REQUIREMENTS 85
NAVIGATION OF COMPLEX SYSTEM REQUIREMENT SETS 86
RAPID REVIEW OF BUSINESS PROCESSES AND REQUIREMENTS RELATIONSHIPS 86
METRICS FOR QUALITYAND 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 THEPRODUCT WILL BE USED 90
IMAGE 6
CONTENTS XI
ANALYZING PRODUCTFEATURES AND CREATING A USE CASE MODEL 92
EXTRACTINGREQUIREMENTS 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
EVERYCONCRETE 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
IMAGE 7
XII SOFTWARE & SYSTEMS REQUIREMENTS ENGINEERING: IN PRACTICE
BUSINESS OBJECTMODELING 108
COHERENT LOW-LEVEL PROCESSES SHOULD BE DEFINED WITH STATE OR ACTIVITY
DIAGRAMS 112
ELICITREQUIREMENTS AND PROCESSES BY STARTING ATBOUNDARIES 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 THATSHOULD BE CORRECTED BEFORE A MODEL IS COMPLETED 113
TRANSITIONING FROMANALYSIS TO DESIGN 115
SUGGESTED MODEL CONVERSIONHEURISTICS 115 DESIGN MODEL PACKAGE STRUCTURE
115
USE CASE TRACING 115
INTERFACE TRACING 115
ARTIFACTTRACING 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 FORMODELING REQUIREMENTS 120
SUMMARY 121
DISCUSSION QUESTIONS 122
REFERENCES 122
5 QUALITY ATTRIBUTE REQUIREMENTS 125
WHY ARCHITECTURAL REQUIREMENTSARE 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
QUALITYATTRIBUTE WORKSHOP 143
IMAGE 8
CONTENTS XIII
GOAL MODELING 145
GLOBALANALYSIS 146
TESTING ASRS 154
CASE STUDY: BUILDINGAUTOMATION SYSTEM 156 FEATURES THAT DEFINE THE
PRODUCT 157
FORCESTHAT 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
COMPLETETHE 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
IMAGE 9
XJV SOFTWARE & SYSTEMS REQUIREMENTS ENGINEERING: IN PRACTICE
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 PRODUCTLINES 213
TIPS FOR REQUIREMENTS MANAGEMENT 215
BEST PRACTICES 215
SUMMARY 217
IMAGE 10
CONTENTS XV
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
EARLYREQUIREMENT 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
IMAGE 11
XVI SOFTWARE & SYSTEMS REQUIREMENTS ENGINEERING: IN PRACTICE
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
DISCUSSIONQUESTIONS 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 MODELINGMETRICS 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
RDBADVANCED 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
|
| any_adam_object | 1 |
| building | Verbundindex |
| bvnumber | BV036765607 |
| classification_rvk | ST 237 |
| classification_tum | DAT 335f |
| ctrlnum | (OCoLC)836810011 (DE-599)HEB22255312X |
| discipline | Informatik |
| format | Book |
| fullrecord | <?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim"><record><leader>01439nam a2200373zc 4500</leader><controlfield tag="001">BV036765607</controlfield><controlfield tag="003">DE-604</controlfield><controlfield tag="005">20130709 </controlfield><controlfield tag="007">t</controlfield><controlfield tag="008">101109s2009 ad|| |||| 00||| eng d</controlfield><datafield tag="010" ind1=" " ind2=" "><subfield code="a">2009002434</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="a">9780071605472</subfield><subfield code="9">978-0-07-160547-2</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="a">0071605479</subfield><subfield code="9">0-07-160547-9</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)836810011</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(DE-599)HEB22255312X</subfield></datafield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">DE-604</subfield><subfield code="b">ger</subfield></datafield><datafield tag="041" ind1="0" ind2=" "><subfield code="a">eng</subfield></datafield><datafield tag="049" ind1=" " ind2=" "><subfield code="a">DE-M347</subfield><subfield code="a">DE-91G</subfield><subfield code="a">DE-384</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">ST 237</subfield><subfield code="0">(DE-625)143623:</subfield><subfield code="2">rvk</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">DAT 335f</subfield><subfield code="2">stub</subfield></datafield><datafield tag="245" ind1="1" ind2="0"><subfield code="a">Software & systems requirements engineering: in practice</subfield><subfield code="c">Brian Berenbach ...</subfield></datafield><datafield tag="264" ind1=" " ind2="1"><subfield code="a">New York [u.a.]</subfield><subfield code="b">McGraw-Hill</subfield><subfield code="c">2009</subfield></datafield><datafield tag="300" ind1=" " ind2=" "><subfield code="a">XXV, 321 S.</subfield><subfield code="b">Ill., graph. Darst.</subfield></datafield><datafield tag="336" ind1=" " ind2=" "><subfield code="b">txt</subfield><subfield code="2">rdacontent</subfield></datafield><datafield tag="337" ind1=" " ind2=" "><subfield code="b">n</subfield><subfield code="2">rdamedia</subfield></datafield><datafield tag="338" ind1=" " ind2=" "><subfield code="b">nc</subfield><subfield code="2">rdacarrier</subfield></datafield><datafield tag="650" ind1="0" ind2="7"><subfield code="a">Requirements engineering</subfield><subfield code="0">(DE-588)4213997-1</subfield><subfield code="2">gnd</subfield><subfield code="9">rswk-swf</subfield></datafield><datafield tag="650" ind1="0" ind2="7"><subfield code="a">Software Engineering</subfield><subfield code="0">(DE-588)4116521-4</subfield><subfield code="2">gnd</subfield><subfield code="9">rswk-swf</subfield></datafield><datafield tag="689" ind1="0" ind2="0"><subfield code="a">Requirements engineering</subfield><subfield code="0">(DE-588)4213997-1</subfield><subfield code="D">s</subfield></datafield><datafield tag="689" ind1="0" ind2="1"><subfield code="a">Software Engineering</subfield><subfield code="0">(DE-588)4116521-4</subfield><subfield code="D">s</subfield></datafield><datafield tag="689" ind1="0" ind2=" "><subfield code="5">DE-604</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Berenbach, Brian</subfield><subfield code="e">Sonstige</subfield><subfield code="4">oth</subfield></datafield><datafield tag="856" ind1="4" ind2="2"><subfield code="m">GBV Datenaustausch</subfield><subfield code="q">application/pdf</subfield><subfield code="u">http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=020682559&sequence=000001&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA</subfield><subfield code="3">Inhaltsverzeichnis</subfield></datafield><datafield tag="999" ind1=" " ind2=" "><subfield code="a">oai:aleph.bib-bvb.de:BVB01-020682559</subfield></datafield></record></collection> |
| id | DE-604.BV036765607 |
| illustrated | Illustrated |
| indexdate | 2024-07-09T22:47:36Z |
| institution | BVB |
| isbn | 9780071605472 0071605479 |
| language | English |
| lccn | 2009002434 |
| oai_aleph_id | oai:aleph.bib-bvb.de:BVB01-020682559 |
| oclc_num | 836810011 |
| open_access_boolean | |
| owner | DE-M347 DE-91G DE-BY-TUM DE-384 |
| owner_facet | DE-M347 DE-91G DE-BY-TUM DE-384 |
| physical | XXV, 321 S. Ill., graph. Darst. |
| publishDate | 2009 |
| publishDateSearch | 2009 |
| publishDateSort | 2009 |
| publisher | McGraw-Hill |
| record_format | marc |
| spelling | Software & systems requirements engineering: in practice Brian Berenbach ... New York [u.a.] McGraw-Hill 2009 XXV, 321 S. Ill., graph. Darst. txt rdacontent n rdamedia nc rdacarrier Requirements engineering (DE-588)4213997-1 gnd rswk-swf Software Engineering (DE-588)4116521-4 gnd rswk-swf Requirements engineering (DE-588)4213997-1 s Software Engineering (DE-588)4116521-4 s DE-604 Berenbach, Brian Sonstige oth GBV Datenaustausch application/pdf http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=020682559&sequence=000001&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA Inhaltsverzeichnis |
| spellingShingle | Software & systems requirements engineering: in practice Requirements engineering (DE-588)4213997-1 gnd Software Engineering (DE-588)4116521-4 gnd |
| subject_GND | (DE-588)4213997-1 (DE-588)4116521-4 |
| title | Software & systems requirements engineering: in practice |
| title_auth | Software & systems requirements engineering: in practice |
| title_exact_search | Software & systems requirements engineering: in practice |
| title_full | Software & systems requirements engineering: in practice Brian Berenbach ... |
| title_fullStr | Software & systems requirements engineering: in practice Brian Berenbach ... |
| title_full_unstemmed | Software & systems requirements engineering: in practice Brian Berenbach ... |
| title_short | Software & systems requirements engineering: in practice |
| title_sort | software systems requirements engineering in practice |
| topic | Requirements engineering (DE-588)4213997-1 gnd Software Engineering (DE-588)4116521-4 gnd |
| topic_facet | Requirements engineering Software Engineering |
| url | http://bvbr.bib-bvb.de:8991/F?func=service&doc_library=BVB01&local_base=BVB01&doc_number=020682559&sequence=000001&line_number=0001&func_code=DB_RECORDS&service_type=MEDIA |
| work_keys_str_mv | AT berenbachbrian softwaresystemsrequirementsengineeringinpractice |