5. 5 20-Nov-2006 RM for INCOSE
Requirements definition – a challenge
6. 6 20-Nov-2006 RM for INCOSE
The basic requests process
• In HP-Indigo we defined a special type of
requirement: A REQUEST
• A request is a requirement that is allocated to
someone else than yourself
Person A Person B
Satisfy request:
Define requirements
Issue a request
7. 7 20-Nov-2006 RM for INCOSE
The basic method – for multi-product
B
A
A spec
Request1
product X
B spec
Requirement1
product X
‘assigned to’ B link
Requirement2
product X
Requirement1
product X
link
Request2
Requirement3
link
‘assigned to’ B
product Y
product Y
,Y
8. 8 20-Nov-2006 RM for INCOSE
Requirements hierarchy
Marketing System
Sub-
system
Sub-
system
SW
system
SW
sub-
system
SW
sub-
system
SW
sub-
system
9. 9 20-Nov-2006 RM for INCOSE
Inheritance flow – process overview
Leading
product
Sub-
system
Sub-
system
Derived
product
Inherit
Delta
request
10. 10 20-Nov-2006 RM for INCOSE
Progress monitoring
Number of requirements and % approved
0
1000
2000
3000
4000
5000
6000
7000
8000
9000 04/09/2005
27/09/2005
02/11/2005
06/12/2005
03/01/2006
07/02/2006
09/03/2006
28/04/2006
16/05/2006
12/06/2006
02/07/2006
09/07/2006
23/07/2006
15/08/2006
27/08/2006
22/10/2006
0%
10%
20%
30%
40%
50%
60%
Parameters
Requirements
%_approved
כאן עמוד שדות שחרר
Date
Data
11. 11 20-Nov-2006 RM for INCOSE
Traceability status monitoring
Overall number of requests to software and number of satisfied requests
0
200
400
600
800
1000
1200
1400
04/09/2005
27/09/2005
02/11/2005
06/12/2005
03/01/2006
07/02/2006
09/03/2006
28/04/2006
16/05/2006
12/06/2006
02/07/2006
09/07/2006
23/07/2006
15/08/2006
27/08/2006
22/10/2006
Assigned_ Satisfied_
12. 12 20-Nov-2006 RM for INCOSE
Requirements distribution
3403
770
4514
2866
Marketing
System
Sub-System
Software
13. 13 20-Nov-2006 RM for INCOSE
Lesson learned
• Management sponsorship is a must
• “Pay as you go” – don’t attempt to solve all your
problems at the start
• We applied distributed system engineering –
every sub system owner is managing his own
requirements and interfaces – controversial
• RM made it possible to measure progress of
requirements definitions, implementation and
verification
• Timing (when to apply RM in a project life cycle)
General
14. 14 20-Nov-2006 RM for INCOSE
Lesson learned
• Your opposition today might become your biggest
support in the future (or not…)
• Holding hands is a must
• Training of new users must be 1/1
• Group workshops for advanced users is very
beneficial
• Updating spec’s is perceived as low priority
documentation task, compared to other “burning”
tasks of the designer – requires on going
education effort
People
15. 15 20-Nov-2006 RM for INCOSE
Lesson learned
• Facilitated interaction between different disciplines –
engineers, scientists, etc.
• Improved communications between remote sites but
required special attention
• Requirements and parameters, together with design
considerations and links, lead to comprehensive
documentation data base
− Achieved structured spec’s by using predefined templates (e.g.
industry std, MIL)
• Requirements with "TBD's" that are used as flags and place
holders are problematic – horizon and/or assumptions are
also needed!
Collaboration
