Shai Koenig

1

ESSI PIE 27582 - ARMT
Presented to ISERD Meeting Software Best
Practice 5 Sept 1999

• Shai Koenig
• ECI Telecom Ltd.
• Corporate Software Engineering Department

2
Project Objectives

• Improve system/software development by
  introducing automated requirements management
  technology

3
Project Work Packages

• Tool survey, study, selection and acquisition
• Select baseline project
• Establish RM environment
• Internal training
• Baseline project RM process and tool support
• Results and conclusions
• Internal dissemination
• External dissemination

4
What is Requirements Management ?

• Requirements management is a systematic approach
  to
• eliciting
• organizing
• analyzing
• documenting
• relating
• baselining
• changing, and
• viewing
• requirements.

What level of requirements ? What kind of
requirements ? Is the investment in requirements
worthwhile ?
5
Is the requirements activity worth the effort
?Who needs it ?
Basis for project planning and tracking
Basis for customer agreement
Basis for design and implementation
Statement of Requirements
Basis for system/product testing and validation
6
Ok, Im convinced !

• Requirements management is important !
• It should cover all levels and types of
  requirements !
• If requirements are not managed well, the project
  will be exposed to serious schedule, cost, and
  quality problems !
• Moreover the cost of correcting these problems
  will be very high !
• But what can I do to improve the situation ???
• Well - first lets look at the current situation !

7
Current requirement management practices are
based on document driven approaches !
Marketing Requirements Spec
Acceptance Test Spec
System Test Spec
System Requirements Spec
System Design Spec
System Integration Spec
Software Requirements Spec
Software Test Spec
Design and Construction Artifacts
8
But, these document driven approaches suffer from
a number of severe drawbacks !

• documents are one-dimensional or linear
• both within a single document and between
  documents
• difficult to describe relationships between
  requirements
• both within a single document and between
  documents
• subject to information duplication
• difficult to maintain consistency
• difficult to maintain up-to-date-ness
• difficult to evolve
• difficult to control changes
• difficult to find information
• difficult to coordinate development - one man
  show

• relationships
• requirement decomposition
• requirement specialization
• requirement allocation
• requirements / test coverage
• requirement dependency

9
Is there another approach ?
Requirements management is a form of information
management so why not apply information
management approaches ?

• For example
• Database technology
• Client server architecture
• Query capabilities
• Graphical User Interfaces

10
An information systems approach to Requirements
Management based on Database Technology !
organize enter relate change analyze
queries reports documents audit trails
11
An information systems approach to Requirements
Management provides multi-user support !
Project Management
Requirements Repository
Marketing Group, Product Management
Database Schema
Development Groups System, HW, SW
Requirements Data Base
Validation Group
12
What about the documents that we are used to ?
13

An information systems approach to Requirements
Management provides significant benefits!

• requirements information is multi-dimensional
• relationships between requirements are easily
  established
• requirements information is not duplicated
• requirements consistency is easier to attain
• easier to maintain up-to-date-ness
• information evolves naturally
• changes are more easily controlled
• easy to find information
• easy to coordinate development - multi-user
  support

14
Requirements Definition Improvement
100
Requirements Specification Practices
Conventional Approaches
0
100
Requirements Management Practices
0
15
Requirements Specification Practices

• Conventional Approaches
• textual, informal prose
• The product will ...
• The system shall ...
• The software should ...

• Structured Approaches
• Functional decomposition
• input-process-output
• state machines
• preconditions/postconditions
• STD
• state transition tables
• scenarios, use cases, message sequence diagrams

16
Requirements Definition Improvement
100
RTM
iDDE
Requirements Specification Practices
URS/ Access
Requisite-Pro
Conventional Approaches
0
100
0
Requirements Management