Instantiation requirement: how the team delivers the right software

Instantiation requirement: how the team delivers the right software
Basic Information
Original Title: specification by example: how successful teams deliver the right software
Author: (SEL) adzic (G.) [Translator's introduction]
Translator: Zhang changgui, Zhang bochao, Shi yongchao
Series name: Turing programming Series
Press: People's post and telecommunications Press
ISBN: 9787115290267
Mounting time:
Published on: February 1, September 2012
Start: 16
Page number: 1
Version: 1-1
Category: Computer

More about instantiation requirements: how the team delivers the right software
Directory
Instantiation requirement: how the team delivers the right software
Start Part 1
Chapter 2 main advantages 2
1.1 implement change more effectively 4
1.2 higher product quality 5
1.3 fewer rework 8
1.4 better collaboration 10
1.5 remember 11
Chapter 1 key process mode 12
2.1 obtain Range 13 from target
2.2 Requirements for collaborative development 14
2.3 example 14
2.4 extraction Requirement Description 15
2.5 requirements not modified during automated verification 15
2.6 frequent verification 17
2.7 evolved a document system 17
2.8 actual example 18
2.8.1 business objective 18
2.8.2 range 18
2.8.3 key instance 18
2.8.4 description of instance requirements 19
2.8.5 description of executable requirements 20
2.8.6 active document 20
2.9 remember 20
Chapter 21 live documentation 21
3.1 why do we need authoritative documentation 22
3.2 test can be a good document 22
3.3 create document 23 Based on executable requirements
3.4 benefits of a document-centric model 25
3.5 remember 25
Chapter 1 Changes to 26
4.1 how to start the change process 27
4.1.1 describe implementation requirements as part of broader process changes 27
4.1.2 focus on improving quality 27
4.1.3 automated functional testing 28
4.1.4 introduce an executable Requirement Description tool 29
4.1.5 use test-driven development as a stepping stone 30
4.2 How to change team culture 31
4.2.1 avoid using agile terminology 31
4.2.2 ensure that you get support from management 32
4.2.3 describe the requirements for instantiation as a better way to promote 33
4.2.4 do not make test automation The final goal. 34
4.2.5 do not focus too much on tools 34
4.2.6 during the migration process, the legacy scripts should also be maintained by 35
4.2.7 track who is running (and not running) Test automatic check program 35
4.3 how Teams integrate and collaborate in processes and iterations 36
4.3.1 global
Talent management team 37
4.3.2 Level B Paribas Bank's siec team 38
4.3.3 skynetwork service department 39
4.4 deal with acceptance and traceability 40
4.4.1 save executable requirements in the version control system
4.4.2 sign for 41 via exported live documents
4.4.3 acceptance scope, not Requirement Description 41
4.4.4 sign for the "simplified use case" 42
4.4.5 introduce case implementation 42
4.5 warning signal 43
4.5.1 test with frequent changes 43
4.5.2 careful rollback 44
4.5.3 organization-level disorder 44
4.5.4 beware of "just in case" Code 44
4.5.5 pay attention to elastic modification 45
4.6 remember 45
Part 2 Key Process Model
Chapter 1 obtain the range from the target: 48
5.1 build correct range 49
5.1.1 understand "why" and "who" 50
5.1.2 understand where value comes from 51
5.1.3 understand the expected output of commercial users 52
5.1.4 let developers provide the "I want" part of the user story 53
5.2 collaborate to determine the scope of 53 without high-level Control
5.2.1 ask "Why are these things useful ?" 54
5.2.2 ask about alternative solution 54
5.2.3 do not focus on the minimum requirement 55
5.2.4 ensure that the team delivers the complete functions 55
5.3 more information 56
5.4 remember 56
Chapter 4 requirements developed through collaboration 58
6.1 why need collaboration? 58
6.2 most popular collaboration model 59
6.2.1 try all large-scale workshops 59
6.2.2 try a small workshop ("Shen Yong sanjian ke") 61
6.2.3 write pairing 62
6.2.4 allow developers to review the test frequently before the iteration starts 63
6.2.5 try informal conversation 64
6.3 prepare for collaboration 65
6.3.1 hold briefing 65
6.3.2 invite stakeholders 66
6.3.3 perform specific preparation and prior review 67
6.3.4 let team members Review story 68 as soon as possible
6.3.5 only prepare the initial instance 69
6.3.6 don't let excessive preparation hinder discussion 69
6.4 select collaboration model 70
6.5 remember 71
Chapter 2 example 72
7.1 example: Example 74
7.2 The example must be accurate to 75
7.2.1 do not show the answer "yes/no" in the example 75
7.2.2 avoid using equivalent abstract classes 75
7.3 The example must be complete 76
7.3.1 test with data 76
7.3.2 use alternative methods to test functions 76
7.4 The example must be authentic. 77
7.4.1 avoid fictitious data 77
7.4.2 obtain basic example 78 directly from the customer
7.5 examples should be easy to understand 79
7.5.1 avoid exploring all possible combinations 80
7.5.2 search for implicit concepts 80
7.6 describe non-functional requirements 81
7.6.1 get precise performance requirements 82
7.6.2 use a low-fidelity prototype for the UI 82
7.6.3 trial of the quper model 83
7.6.4 use check list 84 during discussion
7.6.5 create a reference example 84
7.7 remember 85
Chapter 1 Requirement Description 86
8.1 example 87
8.1.1 free shipping service 87
8.1.2 instance 87
8.2 example of a poor Requirement Description 88
8.3 what do you care about when refining requirements? 90
8.3.1 The instance must be accurate to 90
8.3.2 The script is not a requirement description 90
8.3.3 do not use the stream program description 91
8.3.4 the requirement description should focus on business functions rather than software design 92
8.3.5 avoid writing requirements that are closely coupled with the Code 92
8.3.6 do not introduce temporary solutions with technical difficulties in the Requirement Description 93
8.3.7 do not fall into the details of the user interface 93
8.3.8 the requirement description should be self-explanatory 94
8.3.9 use a narrative title and use a short frame to interpret objective 94
8.3.10 show to others and keep silence 94
8.3.11 do not over-define instance 95
8.3.12 start with a simple example and expand 96
8.3.13 focus on 97
8.3.14 use the "given-when-then" language 97 in the Requirement Description
8.3.15 do not specify
All dependencies 98
8.3.16 apply the default value 99 in the automation Layer
8.3.17 do not always rely on the default value 99
8.3.18 description of requirements should use the domain language 100
8.4 refining practices 100
8.5 remember 102
Chapter 4 automated verification without modifying requirements 9th
9.1 automation required? 104
9.2 starting from automation 105
9.2.1 for the purpose of learning tools, first try a simple Project 105
9.2.2 planned automation 106
9.2.3 do not delay automation or assign others 107
9.2.4 avoid automation based on the original manual test script 107
9.2.5 win trust 108 through User Interface Test
9.3 management automation layer 109
9.3.1 do not treat automated code as second-class citizen 109
9.3.2 describe the verification process in the automation layer 110
9.3.3 do not copy the business logic 111 in the test automation Layer
9.3.4 automation 112 along system boundaries
9.3.5 do not check the business logic 113 through the user interface
9.3.6 automation under the application skin 113
9.4 Automated User Interfaces 115
9.4.1 details the functions of the user interface with a higher level of abstraction 115
9.4.2 UI Requirement Description: only check UI function 117
9.4.3 avoid recording UI testing 117
9.4.4 Create an environment in the database 118
9.5 manage test data 119
9.5.1 avoid using pre-fill data 119
9.5.2 try to use pre-filled referenced data 120
9.5.3 obtain the prototype from the database 120
9.6 remember 121
Chapter 1 frequent verification 10th
10.1 improve stability 123
10.1.1 identify and solve the most annoying problem, and repeat 123
10.1.2 use the CI test history to find unstable tests 124
10.1.3 build a dedicated continuous Verification Environment 125
10.1.4 use automatic deployment 125
10.1.5 creating simple test alternatives for external systems 125
10.1.6 selectively isolate external systems 126
10.1.7 try multi-level verification 127
10.1.8 execute test 127 in the transaction
10.1.9 quick check of referenced data 128
10.1.10 wait for the event, instead of waiting for a fixed length of 128
10.1.11 convert asynchronous processing to optional 129
10.1.12 do not use the executable Requirement Description for end-to-end verification 129
10.2 get faster feedback 130
10.2.1 business introduction time: 130
10.2.2 separate long tests into smaller modules 131
10.2.3 avoid using memory databases for testing 131
10.2.4 separating fast and slow tests 132
10.2.5 maintain stability during night testing 132
10.2.6 create a test package for the current iteration 133
10.2.7 Parallel Run test 133
10.2.8 disable a test with low risk 134
10.3 test of management failure 135
10.3.1 create a regression test package with known failures 135
10.3.2 automatically check for disabled tests 136
10.4 remember 137
Chapter 1 Evolution of the Document System 11th
11.1 live documentation must be easy to understand 138
11.1.1 do not create lengthy demands. Description 138
11.1.2 do not use many small requirement descriptions to describe a single function 139
11.1.3 looking for a higher level concept 139
11.1.4 avoid using technical automation concepts during testing 139
11.2 live documents must be consistent 140
11.2.1 evolved from a language 141
11.2.2 anthropomorphic language 142
11.2.3 Definition Language for collaboration 143
11.2.4 document the building module 143
11.3 live documents must be organized in a well-organized manner for easy access 144
11.3.1 organize the current work by user stories 144
11.3.2 organize user stories by Feature Area 145
11.3.3 organize by the navigation path of the user interface 146
11.3.4 organize by business process 146
11.3.5 use tags instead of URL 147 When referencing the executable Requirement Description
11.4 listen to live documentation 147
11.5 remember 148
Part 3 case study
Chapter 2 uswitch 12th
12.1 START process change 152
12.2 optimization process 154
12.3 current process 156
12.4 result 157
12.5 important lessons learned 157
Chapter 2 rainstor 13th
13.1 process change 159
13.2 current process 161
13.3 important lessons learned 162
Chapter 2 Iowa student loan company 14th
14.1 process change 163
14.2 optimization process 164
14.3 active documents as competitive advantage 166
14.4 important lessons learned 167
Chapter 2 sabre airline solutions 15th
15.1 process change 168
15.2 improved collaboration 169
15.3 result 171
15.4 important lessons learned 171
Chapter 4 eplan services 16th
16.1 process change 172
16.2 live documentation 174
16.3 current process 175
16.4 important lessons learned 176
Chapter 2 songkick 17th
17.1 process change 177
17.2 current process 179
17.3 important lessons learned 180
Chapter 2 thoughts summary 18th
18.1 collaborate to develop requirements to build trust between project stakeholders and delivery teams 182
18.2 collaboration requires preparation 183
18.3 collaboration in a variety of ways 183
18.4 regard the final purpose as a business process document, which is a useful model 184
18.5 live documentation brings long-term value of 184
Appendix A Resource 186

This book is from: China Interactive publishing network