using agile methods to improve efficiency in requirements ... · reconf2016, 01 march 2016...
TRANSCRIPT
REConf 2016, 01 March 2016-1-
Using Agile Methods to Improve Efficiency in Requirements
Engineering
Colin Hood Systems EngineeringEvans Business CentreRegents Pavilion4 Summerhouse RoadMoulton ParkNorthampton NN3 6BJGreat [email protected]
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
AimTo show that by learning from the Agile Manifesto, in particular the two main principles, respectful treatment of people, and dealing flexibly with changes i.e.
§ individuals and interactions over processes and tools
§ responding to change over following a plan
we see:
§ agreeing responsibility with small teams made individuals and interactions moreimportant than blindly following a process
and
§ responding to change is easier with small teams and fewer requirements.
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Manifesto for Agile Software Development
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
Source: http://agilemanifesto.org/
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Manifesto for Agile Software Development
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
Source: http://agilemanifesto.org/
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Agile e.g. Scrum
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer Requirements
System Requirements
System Architecture
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer
System Analyst
System Architect
Sub-System Analyst
Sub-System Architect
Sub-System Developer
Feature Owner and Chief Requirements Engineer
Unless someone is responsible for satisfying customer requirements,no-one is responsible for satisfying customer requirements
Chi
ef R
equi
rem
ents
Eng
inee
r
Feat
ure
Ow
ner
Feat
ure
Ow
ner
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Simple Information Model
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer Requirements
System Requirements
System Architecture
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer
System Analyst
System Architect
Sub-System Analyst
Sub-System Architect
Sub-System Developer
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Simple Information Model
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer Requirements
System Requirements
System Architecture
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer
System Analyst
System Architect
Sub-System Analyst
Sub-System Architect
Sub-System Developer
200
10,000 + 7,000
1,000
5,000
Total 23,000
Requirements grew from 200 to 23,000
becauseblindly following a process
was considered more importantthan
Individuals and interactions
The software was completelong before the requirements
becauseresponding to change
with so many requirements was very difficult.
Most requirements werenot needed
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer Requirements
System Requirements
System Architecture
Sub-System Requirements
Sub-System Architecture
Sub-System Detailed Design
Customer
System Analyst
System Architect
Sub-System Analyst
Sub-System Architect
Sub-System Developer
Feature Owner and Chief Requirements Engineer
Chi
ef R
equi
rem
ents
Eng
inee
r
Feat
ure
Ow
ner
Feat
ure
Ow
ner
200
1,000
5,000
Total 6,000
Agreeing responsibility withsmall teams valued
Individuals and interactionsover processes and tools
Responding to change iseasier with small teamsand few requirements
Most requirements not repeated
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016
SummaryBy learning from the Agile Manifesto, in particular the two main principles, respectful treatment of people, and dealing flexibly with changes i.e.
§ individuals and interactions over processes and tools
§ responding to change over following a plan
we see:
§ agreeing responsibility with small teams made individuals and interactions moreimportant than blindly following a process
and
§ responding to change is easier with small teams and fewer requirements.
Agreeing responsibility withsmall teams valued
Individuals and interactionsover processes and tools
Responding to change iseasier with small teamsand few requirements
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016-11-
Colin Hood Systems Engineering LimitedEvans Business CentreRegents Pavilion4 Summerhouse RoadNorthampton NN3 6BJ – UK
Systems Engineering since 1985
Founding Member of IREB 2006(International Requirements Engineering Board)
Copyright © 2016 Colin Hood Systems Engineering
REConf 2016, 01 March 2016-12-
Organisational Change
Source: Colin Hood 1987 based on work by Shein and Lewin
Lack of discomfort with current, fear of the new.Ignore information that does not fit in with past.Lack of psychological security with the change,fear of loss of identity or status.
For successful change we must:1. Overcome barriers to change2. Communicate benefits to change3. Support a learning environment4. Embedd the new way of working
Progress of Change
Unfreeze
Learn
Refreeze
Copyright © 2016 Colin Hood Systems Engineering