Johan Sjöblom
Product Area Manager
Ericsson WasaLab
Johan.Sjoblom@ericsson.fi
Contents
How do requirements behave today?
CMM - Capability Maturity Model - Req. Mgmt
The Incremental Development Model
Requirements and Incremental Design
0
Johan.Sjoblom@ericsson.fi 2.11.1999
How Do Requirements Behave Today?
Requirements Loosen Up when moving
from networks to services and applications
Requirements and Incremental Design
1
Johan.Sjoblom@ericsson.fi 2.11.1999
Requirements without 50k of ITU/ETSI specs?
No Microsoft type player around in Telecom??
Industry Consortiums:
– Symbian, EPOC operating system, www.symbian.com
– WAP Forum, www.wapforum.org
– Bluetooth
Other de facto standards
– IETF: Req. For Comments (RFC’s)
– Java API’s
– W3C (HTML, XHTML, XML)
Requirements and Incremental Design
2
Johan.Sjoblom@ericsson.fi 2.11.1999
CMM & Requirement Management
CMM - Capability Maturity Model
Levels 1-5
Level 2 is project oriented, and is called
“repeatable”
KPA - Key Process Areas
Requirement Management is a KPA in CMM level 2
Requirements and Incremental Design
3
Johan.Sjoblom@ericsson.fi 2.11.1999
CMM 2 - KPA - RM - Activity 1
The software engineering group reviews the
allocated requirements BEFORE they are
incorporated into the software project
– 4. Commitments resulting from the allocated
requirements are negotiated with the affected groups.
Requirements and Incremental Design
4
Johan.Sjoblom@ericsson.fi 2.11.1999
CMM 2 - KPA - RM - Activity 2
The software engineering group uses the
allocated requirements as the basis for software
plans, work products, and activities.
– 1. Allocated requirements are managed and controlled.
Requirements and Incremental Design
5
Johan.Sjoblom@ericsson.fi 2.11.1999
CMM 2 - KPA - RM - Activity 3
Changes to the allocated requirements are
reviewed and incorporated into the software
project
– 1. The impact to existing commitments is assessed, and
changes are negotiated as appropriate.
Requirements and Incremental Design
6
Johan.Sjoblom@ericsson.fi 2.11.1999
Incremental Development
ID
Requirements and Incremental Design
7
Johan.Sjoblom@ericsson.fi 2.11.1999
Introduction to Incremental Development
Part I
• Waterfall model
• Problems with the waterfall model
• Incremental Development concepts
Part II
• Incremental Development:
Benefits, Pitfalls & Concerns
• Experiences
Requirements and Incremental Design
8
Johan.Sjoblom@ericsson.fi 2.11.1999
Waterfall model
Analysis
Implementation
Test
time
Requirements and Incremental Design
9
Johan.Sjoblom@ericsson.fi 2.11.1999
Existing Problems (1)
• Late feedback for customers and designers
• How to cope with changing requirements?
• Big bang integration with interface and integration problems
Big Bang Integration
Requirements and Incremental Design
10
Johan.Sjoblom@ericsson.fi 2.11.1999
Existing problems (2)
• Rush on test resources
• Lack of Project Control
• Slow process improvement
“Rush on test resources”
Requirements and Incremental Design
11
Johan.Sjoblom@ericsson.fi 2.11.1999
ID Process View
Plan
Analysis
Implementation
Test
Integrate
* Divide the work in small controllable parts (= increments)
* Increments must be testable parts of the system
Plan
Integrate
Requirements and Incremental Design
12
Johan.Sjoblom@ericsson.fi 2.11.1999
ID System View
User Functionality
6
4
2
1
3
5 7
Platform
Each accumulation of developed increments is
a complete user executable system
Requirements and Incremental Design
13
Johan.Sjoblom@ericsson.fi 2.11.1999
Benefits & Pitfalls
Requirements and Incremental Design
14
Johan.Sjoblom@ericsson.fi 2.11.1999
Benefits
1) Lead-time reduction
waterfall
Analysis
Implementation
Test
incremental
Analysis
Implementation
Test
Requirements and Incremental Design
15
Johan.Sjoblom@ericsson.fi 2.11.1999
Benefits
2) No ‘big bang’ integration
Waterfall
Time to solve problems
Integrate
Incremental Development
Integrate
Integrate
Integrate
Requirements and Incremental Design
16
Johan.Sjoblom@ericsson.fi 2.11.1999
Benefits
3) Handling of unstable requirements
Unstable requirement
Added requirement
Requirements and Incremental Design
17
Johan.Sjoblom@ericsson.fi 2.11.1999
Pitfalls
1) Planning & Tracking
Anatomy
• Allocation of features
dependent of technical
contents.
• Delay in one part of the
project can on short term
impact early deliveries.
Charging
SW Superv.
Statistics
Traffic
HW Superv.
Commands
HW Init.
Load appl.
Planning
Load OS
Requirements and Incremental Design
18
Johan.Sjoblom@ericsson.fi 2.11.1999
Pitfalls
2) Configuration Management
project X
project Y
incr. 1
product baseline
incr. 1
incr. 1
Requirements and Incremental Design
19
Johan.Sjoblom@ericsson.fi 2.11.1999
Pitfalls
3) Postponement of features
Requirements and Incremental Design
20
Johan.Sjoblom@ericsson.fi 2.11.1999
Concerns
More increments implies shorter design verification cycles
Extra testing
– Test cases needs to be rerun in several increments
– Possibility for continues system test
4
More reviews
and inspections
– Documents impacted by several increments need more
inspections. (simplyfied inspections from R&I)
Requirements and Incremental Design
21
Johan.Sjoblom@ericsson.fi 2.11.1999
Conclusion
ID solves the following problems in waterfall
projects:
– Late feedback / Changing requirements / Big bang
integration
– Rush on test resources / Lack of project control / Slow
process improvement
Is has been used successfully for the last decade
Extra attention needed for:
– Planning & Tracking
– Configuration Management
Increased use of testing and reviews &
inspections
Requirements and Incremental Design
22
Johan.Sjoblom@ericsson.fi 2.11.1999