An Overview of Requirements Engineering Tools and Methodologies

1
An Overview of Requirements Engineering Tools and
Methodologies
Professor Ron Kenett Tel Aviv Unversity School
of Engineering
Based on a presentation by Dr. S. Koenig
2
Outline of presentation

• Introduction to requirements engineering
• Improving requirements specification practices
• Improving requirements management practices
• Vision
• Tools

3
What is Requirements Engineering ?

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

• What level of requirements ?
• What kind of requirements ?
• Is the investment in requirements worthwhile ?

4
What kind of Requirements ?

• Functional Requirements
• Non-functional Requirements
• Inverse Requirements Thou shalt not ...
• Interface Requirements
• Data Requirements
• Design and Implementation Constraints

5
What level of Requirements ?
Marketing Requirements Spec
System Requirements Spec
System Design Spec
Hardware Requirements Spec
Software Requirements Spec
6
What about the documents that we are used to ?
7
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
8
Assumptions

• Requirements engineering is important
• Requirements engineering should strive to 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

9
Improving Requirements Engineering
Improved Requirements Specification Practices
Conventional Approaches
0
Improved Requirements Management Practices
0
10
Requirements Specification Characteristics IEEE
Std 830

• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance/effort/stability
• Verifiable
• Modifiable
• Traceable
• Understandable

11
Requirements Specification Techniques

• Hierarchical Decomposition
• Natural language
• Structured natural language
• Prototyping
• Entity Relationship Modeling
• Use Cases and Scenarios
• Control Modeling state-based approaches, e.g.,
  Statecharts, SDL
• Structured Analysis SA, SADT
• Structured Analysis/RT
• Requirements specification languages e.g.,
  PSL/PSA, RSL
• Formal Specification Languages e.g., Z, VDM,
  Algebraic specification
• ...
• Note these are not mutually exclusive

12
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

13
Requirements Specification Practices
Informal
Formal

• Structured Approaches
• structured natural language
• tabular
• hierarchical decomposition
• functional
• architectural
• methodologies
• input-process-output
• stimulus/response
• scenarios, use cases, message sequence diagrams
• entity-relatiuonship modeling

• Conventional Approaches
• natural language
• document-oriented
• organized into chapters, sections, paragraphs,
  ...
• textual, informal prose
• The product will ...
• The system shall ...
• The software should ...

• Formal Approaches
• languages with formal semantics
• rigid
• state-based SDL, Statecharts
• logic-based Z, VDM, CSP

14
The Use Case Approach

• Use cases describe functional requirements in an
  informal but structured manner
• easier to read
• easier to write
• self-organizing
• Use cases define behavioral requirements
• from an external viewpoint
• in terms of goals
• that are achieved or not by end-to-end
  scenarios
• Use cases define only the functional requirements
• Use cases provide a framework for defining
  non-functional requirements
• Scenarios are relatively easy to translate to
  test procedures

15
Basic Concepts of the Use Case Approach

• Actors
• the external entities e.g., humans, hardware,
  other systems with which which the system
  interacts
• User Scenario
• a sequence of actions, each performed by the
  system or one of its actors, that yields an
  observable result of value to a particular actor
• a system behavior or an instance of using the
  system
• primary
• secondary often resulting from exception or
  error conditions
• Use case
• set of scenarios with a common goal
• the functionality of a system may be defined by
  a collection of use cases, each of which consists
  of a number of scenarios
• use cases define a systems functionality from
  the users actors point of view, without
  specifying how the use cases are implemented
• the description of a use case defines what
  happens when the use case is performed

16
Specifying use cases and scenarios

• Use Case
• Name
• Goal/Brief description
• Precondition
• Postconditions
• Triggering Actor
• Trigger Event
• Remarks

• Scenario
• Name
• Brief description
• Type primary, secondary
• Precondition
• Flow of events
• step number
• actor or specification entity
• inputs, actions, outputs, responses
• remarks

• Scenario
• Name
• Brief description
• ...

...
17
Specifying a use case and its scenarios
Scenarios
Use Case
18
Describing a scenarios flow of events

• prose
• structured prose
• tables
• pseudocode
• interaction diagrams
• sequence diagrams
• collaboration diagrams

19
Example of a use case and its main line scenario
20
Example of textual scenario
21
Requirements Specification using Use Cases
22
Requirements Specification using Use Cases
23
Requirements Specification using Use Cases
24
Requirements Specification using Use Cases
25
Requirements Specification using Use Cases
26
Requirements Specification using Use Cases
27
Requirements Specification using Use Cases
28
Requirements Specification using Use Cases
29
Requirements Specification using Use Cases
30
Organizing use cases

• you can organize use cases by grouping them into
  packages
• use case diagrams
• you can organize use cases by specifying
  relationships among them
• generalization - use cases that are specialized
  versions of other use cases
• include - use cases that are included as parts of
  other use cases
• extend - use cases that extend the behavior of
  other use cases

ltltincludegtgt
ltltextendgtgt
ltltincludegtgt
31
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
32
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

33
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

34
An information systems approach to Requirements
Engineering based on Database Technology !
queries
organize enter relate change analyze
reports
documents
audit trails
35
An information systems approach to Requirements
Management provides multi-user support !
Project Management
Marketing Group, Product Management
Development Groups System, HW, SW
Validation Group
36

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

37
Requirements Definition Improvement
RTM
Improved Requirements Specification Practices
Requisite-Pro
Conventional Approaches
0
Improved Requirements Management Practices
0
38
Evaluation Criteria for Requirements Management
Tools

• Importance 1-3
• Impact of using tool
• much better
• better
• same
• worse
• much worse
• Root cause
• methodology
• tool
• both

39
The Future
Design, Construction Component Testing
40
The Future
Integrated Knowledge, Task Workgroup Management
Design, Construction Component Testing
41
The Future - integrated Engineering Information
Management
Integrated Knowledge, Task Workgroup Management
Design, Construction Component Testing
42
(No Transcript)