6. Attention ceci est une « Bullet Attack »
Un bon cahier des charges peut être caractérisé par !
les 7 qualificatifs suivants [IEEE 830]:!
!
• non ambigu!
• complet!
• vérifiable!
• consistant!
• modifiable!
• traçable!
• utilisable durant la maintenance
@aloyer
8. Project Challenged Factors
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
!
Project Impaired Factors % of
1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%
4. Unrealistic Expectations 9.9%
5. Lack of Executive Support 9.3%
6. Changing Requirements & Specifications 8.7%
7. Lack of Planning 8.1%
8. Didn't Need It Any Longer 7.5%
9. Lack of IT Management 6.2%
10. Technology Illiteracy 4.3%
Chaos Report
http://blog.standishgroup.com/
@aloyer
9. The Bull Survey (1998)
!
All the managers interviewed had previously taken the lead in integrating large systems
within organizations in the Times Top 100.!
!
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
@aloyer
10. The Bull Survey (1998)
!
All 2005 the Survey: managers The interviewed Top had previously taken the lead in integrating large systems
within organizations in the Challenges Times Top Facing 100.!
Business !
Analysts
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
Business Improvement Architect’s research sur vey of Business Analysts attending Project World/
Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of
the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two
challenges facing their organizations in managing business requirements.!
!
-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm
@aloyer
11. Why IT Projects Fail
1. Lack of Governance!
2. Internal Politics!
3. Poor communication between business and IT!
4. Unclear expectations!
The Bull Survey (1998)
!
All 2005 the Survey: managers The interviewed Top had previously taken the lead in integrating large systems
within organizations in the Challenges Times Top Facing 100.!
Business !
Analysts
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
Business Improvement Architect’s research sur vey of Business Analysts attending Project World/
Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of
the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two
challenges facing their organizations in managing business requirements.!
!
-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm
!
http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4
@aloyer
12. Why IT Projects Fail
1. Lack of Governance!
2. Internal Politics!
3. Poor communication between business and IT!
4. Unclear expectations!
The Bull Survey (1998)
!
All 2005 the Survey: managers The interviewed Top had previously taken the lead in integrating large systems
within organizations in the Challenges Times Top Facing 100.!
Business !
Analysts
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
Business Improvement Architect’s research sur vey of Business Analysts attending Project World/
Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of
the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two
challenges facing their organizations in managing business requirements.!
!
-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm
!
http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4
Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes
(2005)!
http://spectrum.ieee .org/computing/software/why-software-fails!
!
Among the most common factors:!
* Unrealistic or unarticulated project goals!
* Inaccurate estimates of needed resources!
* Badly defined system requirements!
* Poor reporting of the project's status!
* Unmanaged risks!
* Poor communication among customers, developers, and users!
* Use of immature technology!
* Inability to handle the project's complexity!
* Sloppy development practices!
* Poor project management!
* Stakeholder politics!
* Commercial pressures
@aloyer
13. Why IT Projects Fail
1. Lack of Governance!
2. Internal Politics!
3. Poor communication between business and IT!
4. Unclear expectations!
Seven Reasons IT Projects Fail - February 2012
!
1. Poor Project Planning and Direction
2. Insufficient Communication
3. Ineffective Management
4. Failure to Align With Constituents and Stakeholders
!
The Bull Survey (1998)
!
All 2005 the Survey: managers The interviewed Top had previously taken the lead in integrating large systems
within organizations in the Challenges Times Top Facing 100.!
Business !
Analysts
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
Business http://Improvement www.ibmsystemsmag.com/power/Systems-Management/Workload-Management/
Architect’s research sur vey of Business Analysts attending Project World/
Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of
the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two
challenges facing their organizations in managing business requirements.!
!
-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm
!
http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4
Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes
(2005)!
http://spectrum.ieee .org/computing/software/why-software-fails!
!
Among the most common factors:!
* Unrealistic or unarticulated project goals!
* Inaccurate estimates of needed resources!
* Badly defined system requirements!
* Poor reporting of the project's status!
* Unmanaged risks!
* Poor communication among customers, developers, and users!
* Use of immature technology!
* Inability to handle the project's complexity!
* Sloppy development practices!
* Poor project management!
* Stakeholder politics!
* Commercial pressures
project_pitfalls/?page=2!
@aloyer
14. Why IT Projects Fail
1. Lack of Governance!
2. Internal Politics!
3. Poor communication between business and IT!
4. Unclear expectations!
Seven Reasons IT Projects Fail - February 2012
!
1. Poor Project Planning and Direction
2. Insufficient Communication
3. Ineffective Management
4. Failure to Align With Constituents and Stakeholders
!
The Bull Survey (1998)
!
All 2005 the Survey: managers The interviewed Top had previously taken the lead in integrating large systems
within organizations in the Challenges Times Top Facing 100.!
Business !
Analysts
Project Evaluation Criteria
!
The main IT project failure criteria identified by the IT and project managers were:!
* missed deadlines (75%)!
* exceeded budget (55%)!
* poor communications (40%)!
* inability to meet project requirements (37%).!
!
http://www.it-cortex.com/Stat_Failure_Cause.htm
Business http://Improvement www.ibmsystemsmag.com/power/Systems-Management/Workload-Management/
Architect’s research sur vey of Business Analysts attending Project World/
Business Analyst World 2005 in Toronto, Canada, identified that ‘Lack of Clarity in the Scope of
the Business Functions’ and ‘Business Requirements Not Well-Defined” are the top two
challenges facing their organizations in managing business requirements.!
!
-- http://www.bia.ca/articles/TheTopChallengesFacingBusinessAnalysts.htm
!
http://www.itbusinessedge.com/slideshows/show.aspx?c=81818&slide=4
Why Software Fails - We waste billions of dollars each year on entirely preventable mistakes
(2005)!
http://spectrum.ieee .org/computing/software/why-software-fails!
!
Among the most common factors:!
* Unrealistic or unarticulated project goals!
* Inaccurate estimates of needed resources!
* Badly defined system requirements!
* Poor reporting of the project's status!
* Unmanaged risks!
* Poor communication among customers, developers, and users!
* Use of immature technology!
* Inability to handle the project's complexity!
* Sloppy development practices!
* Poor project management!
* Stakeholder politics!
* Commercial pressures
project_pitfalls/?page=2!
The Most Common Factors for the failure of Software Development Project
!
1. Lack of Customer or User Involvement
2. Unclear goals and objectives
3. Poor Requirement Set
4. Lack of Resources
5. Failure to communicate and act as a team
!
!
Volume 1, No. 11, Januar y 2013 ISSN – 2278-1080 !
The International Journal of Computer Science & Applications!
http://www.journalofcomputerscience.com/2013Issue/Jan13/V1No11Jan13P044.pdf
@aloyer
31. Working together to find better solutions
Use real-world examples to build a
shared understanding of the domain
People understand requirements
best using concrete examples.
Examples clear up ambiguity and misunderstandings.
Examples expose missing requirements.
Examples force everyone to think harder about a problem.
@aloyer
32. Behavior Driven Development!
« 2003 »
Test First
Test Driven Development
Executable Specification!
& Automation
Exploratory Examples!
& Discussion
@aloyer
33. It’s NOT about tools
http://pencilink.blogspot.fr/2010/10/iron-man-160-jim-starlin-cover-steve.html
@aloyer
34. It’s NOT about tools
It’s about Communication and Behavior!
http://pencilink.blogspot.fr/2010/10/iron-man-160-jim-starlin-cover-steve.html
@aloyer
35. It’s NOT about Testing
http://ungoliantschilde.tumblr.com/post/78793890826/ungoliantschilde-barry-windsor-smith-that
@aloyer
36. It’s NOT about Testing
It’s about Exploring the Unknown
http://ungoliantschilde.tumblr.com/post/78793890826/ungoliantschilde-barry-windsor-smith-that
@aloyer
50. Why?
Goal?
Business Value?
Feature: ...
In order to <achieve the vision>
As a <stakeholder>
I want <value>
Intention What?
How!
@aloyer
51. Why?
Goal?
Business Value?
Feature: ...
In order to <achieve the vision>
As a <stakeholder>
I want <value>
Intention
As a <role>
I want <goal>
So that <value>
User focused
What?
How!
@aloyer
52. No Narrative
No Business Value
Unnecessary Feature !
@aloyer
53. Feature
Criteria!
(Rules)
Criteria!
(Rules)
What is it
supposed to do
Example
Example
Illustration of
Example
Example
Example
Acceptance Criteria vs Example @aloyer 32
54. Password OK/KO Reason
Arn4uld KO No special characters
arnauld$ KO No upper case
Arn4ld$ OK
Z0€ KO too short
Last Passwords Password OK/KO
J0hn$!
$m1th!
Arn4ld$
Arn4ld$ KO
J0hn$!
Arn4ld$!
$m1th
Arn4ld$ KO
Arn4ld$!
J0hn$!
$m1th
Arn4ld$ OK
Examples of Examples @aloyer 33
55. Feature: ...
As a...
I want to...
Scenario: ...
In order to...
@aloyer
56. Feature: ...
As a...
I want to...
Scenario: ...
In order to...
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
57. BDD uses examples to illustrate
Feature: ...
As a...
I want to...
Scenario: ...
In order to...
behavior
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
58. Scenario: Some determinable business situation
Every scenario consists of a list of steps
Given <a specific context>
When <an action is performed on the system>
Then <an expected outcome should be observed>
Gherkin - Scenario - Given/When/Then
35
Resulting!
State
Initial!
Context
Given
Given
Given
Given
When
Then
When
Then
Then
Transition
@aloyer
59. Given!
!
The purpose of givens is to put the system in a known state
before interacting with it. They defines the preconditions.
!
• Indicate which environment to use
• Insert values in database
• Fill context with predefined users
• Log user
• …
Given there are no users on site!
Given the database is clean
Given the predefined high and volatile stocks
Given I am logged in as "Balthazar"
Gherkin - Scenario - Given/When/Then
@aloyer 36
60. When!
!
The purpose of when steps is to describe the key action
performed (the state transition).
!
• Trigger commands
• Interact with the UI
• Go to a specific page, Fill a form, Select books or CDs
• Launch a batch
• …
When I log in the application as "Gaspard"
When I look at my profile!
When I book the deal
When I generate the financial report
Gherkin - Scenario - Given/When/Then
@aloyer 37
61. Then!
!
The purpose of Then steps is to observe outcomes. The
observations should be related to the business value/
benefit of the feature.
!
• Feedback message
• Generated document, Mail sent
• Command output
• Data updated
• …
Gherkin - Scenario - Given/When/Then
It should be
something related to
the Given/When
Then I should see a welcome message
Then the report should contain the created deal!
Then the result should be 42
@aloyer 39
62. Why do YOU
like should?
It encourages
debate, and
constant Questioning
of the premise of the
application you are
developing.
Dan North, March 2005
DMZ
BDD
Approach
Gherkin - Should 40 @aloyer 40
63. Scenario: Some determinable business situation
!
Given a specific context
Given another specific context
Given an even other specific context
When an action is performed on the system
When another action is performed on the system
Then expected outcome
Then an other expected outcome
Then an even other expected outcome
Gherkin - Scenario - Given/When/Then
@aloyer 41
64. Scenario: Some determinable business situation
!
Given a specific context
And another specific context
But an even other specific context
When an action is performed on the system
And another action is performed on the system
Then expected outcome
And an other expected outcome
But an even other expected outcome
Given/When/Then + And/But
Gherkin - Scenario - And/But
@aloyer 42
65. Feature: Trade Execution
!
In order to reduce the risk of other clearing firm failing to honor its trade
settlement obligations
As a clearing firm
I want that a clearing house stands between me and the other firm
Scenario: New trade is confirmed between the bank and counterparty
!
Given A new trade between the bank and counterparty
When the trade is captured
Then it should be sent to clearing house for matching
Gherkin - Sample
@aloyer 43
66. Feature: Trade Execution
!
In order to reduce the risk of other clearing firm failing to honor its trade
settlement obligations
As a clearing firm
I want that a clearing house stands between me and the other firm
Scenario: New trade is confirmed between the bank and counterparty
!
Given A new trade between the bank and counterparty
When the trade is captured
Then it should be sent to clearing house for matching
Gherkin - Sample
44
Must give a quick
overview of what
scenario is doing
@aloyer
67. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
Gherkin - Sample Calculator Feature
@aloyer 45
68. What could be
the first use case?
@aloyer
Gherkin - Sample Calculator Feature 46
69. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
Gherkin - Sample Calculator Feature
@aloyer 47
70. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
the Given/When ‟
Gherkin - Sample Calculator Feature
47
It should be
something related to
@aloyer
71. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
the Given/When ‟
Gherkin - Sample Calculator Feature
48
It should be
something related to
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 23 Should Fail!
@aloyer
72. What could be the next
Scenario?
@aloyer
Gherkin - Sample Calculator Feature 49
73. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
!
Scenario: Addition of a positive number and a negative number
!
Given two numbers 11 and -3
When I add them
Then the result should be 8
Gherkin - Sample Calculator Feature
@aloyer 50
74. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
!
Scenario: Addition of a positive number and a negative number
!
Given two numbers 11 and -3
When I add them
Then the result should be 8
Gherkin - Sample Calculator Feature
51
Reusable
Step
@aloyer
75. Feature: Addition feature
!
In order to perform mathematical operations
As an accounting officer
I want to be able to add numbers
!
Scenario: Addition of positive numbers
!
Given two numbers 12 and 7
When I add them
Then the result should be 19
!
Scenario: Addition of a positive number and a negative number
!
Given two numbers 11 and -3
When I add them
Then the result should be 8
Gherkin - Sample Calculator Feature
52
Parameterized
Step
@aloyer
80. Feature: ...
As a...
I want to...
Scenario: ...
In order to...
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
81. Feature: ...
As a...
I want to...
Scenario: ...
In order to...
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
82. Examples help discover things early
Feature: ...
As a...
I want to...
Scenario: ...
In order to...
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
83. One may discover that one doesn't know
Feature: ...
As a...
I want to...
Scenario: ...
In order to...
but others do!
Given <a context>
When <an event happens>
Then <an outcome should occur>
@aloyer
