Embed Size (px)
Citation preview
• Hä löns int´ förklar´ för den som int´ begrip”
Context driven requirements
Click icon to add picture
1. Shu 2. Ha3. Ri
Clark Terry
• The value of any practice or method depends on its context.• There are good practices in context, but there are no best practices.• People, working together, are the most important part of any
project’s context.• Projects unfold over time in ways that are often not predictable.• Requirements are the “what” when delivered solves the business
need.• Requirement engineering & management is a challenging
intellectual process.• Only through judgment and skill, exercised cooperatively
throughout the entire project, are we able to do the right things at the right time to effectively develop our products.
Basic principles of context driven requirements
Context• Constraints• Rate of Change • Governance • Proximity • Size • Criticality • Org culture & Climate• Novelty• Complexity• Value• Purpose
Click icon to add picture
Constraints
Business Domain
Click icon to add picture
Constraints
Business Domain
Legacy system
• Documentation?• Lack of knowledge• Complex
Dependencies• Integrations• Technical debt
Application Domain
• Techniques and tools• Certification procedures • Compliance to standards
Constraints
Ceremony
• Documentation• Artefacts• Roles & Activities• Check Point• Reports• Plans• Milestones• Formal Reviews• Traceability
Empirical Process
• Change driven• Adaptive way of working
Defined Process
• Plan driven • Predictive way of working
• Known• Steps• Simple
• Unknown• Innovation• Complex
Waterfall Agile LeanStart up
Way to go
• Uncertain or volatile requirements
• Responsible & motivated team
• Involved customer
Relay more on:• Understanding• Discipline• Skill
Way to go
• Fixed requirements• Fixed Scope contract• Fixed price • Relay more on:• Documents• Process • Ceremony
Governance
• Reporting• Steering• Safety implications• Security implications?• Regulations?
• Requirement status reports
• Requirement format• Requirement planing• Requirement attributes• Requirement process• Requirement traceability• Requirement management
Local Team
Proximity of team
Distributed team Challenges: • Difficult to initiate
communication • Misunderstanding/
miscommunication• Dramatically decreased
frequency of communication • Increased communication
cost— time, money, and staff • Time difference
Team Collaboration
Prod
uctiv
ity
Distributed Team
Many peopleUsing a lightmethodology
Alistair Cockburn: Agile Software Development
Many peopleUsing a heaviermethodology
Many peopleUsing a very heavymethodology
Methodology Weight
Small team
Prob
lem
size
Methodology Weight
A few peopleUsing a lightMethodology
A few peopleUsing a heavyMethodology
Alistair Cockburn: Agile Software Development
Size
Number of people involved
CommunicationLoad
Methodology
Size
Effectivness perperson
Criticality
Loss of lifeLoss of essential moneyLoss of discretionary moneyLoss of comfort
MoreCeremony
Complexity
Low Complexity
Team Collaboration
Prod
uctiv
ity
High Complexity
The association among project manager's leadership style, teamwork and project successLi-Ren Yang · Chung-Fah Huang · Kun-Shan Wu . Apr 2011 · International Journal of Project Management
Medium Complexity
Complexity
Low Complexity
Team Communication
Prod
uctiv
ity
High Complexity
The association among project manager's leadership style, teamwork and project successLi-Ren Yang · Chung-Fah Huang · Kun-Shan Wu . Apr 2011 · International Journal of Project Management
Medium Complexity
Complexity
Low Complexity
Team Cohesiveness
Prod
uctiv
ity
High Complexity
The association among project manager's leadership style, teamwork and project successLi-Ren Yang · Chung-Fah Huang · Kun-Shan Wu . Apr 2011 · International Journal of Project Management
Medium Complexity
Productivity gain• Team Communication +50%• Team Collaboration + 77%• Team Cohesiveness +74%
High Complexity situation
Organizational culture & Climate
Where are high-performance teams found?Manager-
led tea
m
Self-managed tea
m
Self-organizin
g team
Self-govern
ing team
Prod
uctiv
ity
Novelty
Simple
Fuzzy?
RequirementAnalystknowledge
Stakeholder knowledge
Coaching
Discovery
Cost
ValueBuild business value
Pay to learn
Trim the tail
Value
Purpose
Evaluation:• Needs • Business Req• Non Func Req
Development:• User Req• Func Req• Non Func Req
What to do?
Pay to Learn
• Are we building the right ting?• Can these people build it?• Will our solution work• Do we understand the cost?
Are we building the right ting?
Paper prototypingAmbassador userEarly deliveryEmpty delivery and Manual
delivery
Can these people build it?
Early victoryWalking SkeletonSimplest first, worst second
Will our solution work
Micro-incremental development Walking skeletonSpikesStory splitting
Do we understand the cost?
Core SamplesMicrocosm
Less More
• Extensive Stakeholder involvement • Outsourced development• Dev team has considerable domain
knowledge
• COTS solution will be used
• Precedents are available
• Req traceability is needed
• Team is dispersed
• Testing will be based on requirements
• Accurate estimates are needed
Requirements details
• Constraints in play
Time
Effectivness
Just In Time
Timing
Time
Effectivness
Quality
Good Enough
In conclusion
Requirements aren´t analysed or defined until they are needed
Development is allowed to begin with incomplete requirement set
Analysis and definition is continuous throughout the project
Requirements are continuously refined as the project moves forward
Only a small investment is required at the start
Questions?
• Context Charting• Requirement LCM• Requirement Coaching• Requirement Tool mentoring• Requirement when evaluating• Business Requirements vs
Needs
AddQ offerings
• Requirement Plan• Requirement Discovery• Requirement Analysis• Requirement Formulation• Requirement Validation• Customized trainings• Requirement Automation
