1. An Overview of Requirements Engineering Tools and Methodologies*
5/8/2018
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
5/8/2018
Outline of presentation
Introduction to requirements engineering
Improving requirements specification practices
Improving requirements management practices
Vision
Tools

3. What is Requirements Engineering ?
5/8/2018
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 ?
5/8/2018
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 ?
5/8/2018
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 ?
5/8/2018
07/20/98
What about the documents that we are used to ? 33

7. Is the requirements activity worth the effort ? Who needs it ?
5/8/2018
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
5/8/2018
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
5/8/2018
Improving Requirements Engineering
Improved
Requirements Specification Practices
Conventional
Approaches
Improved Requirements
Management Practices

10. Requirements Specification Characteristics [IEEE Std 830]
5/8/2018
Requirements Specification Characteristics [IEEE Std 830]
Correct
Unambiguous
Complete
Consistent
Ranked for importance/effort/stability
Verifiable
Modifiable
Traceable
Understandable

11. Requirements Specification Techniques
5/8/2018
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
5/8/2018
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
5/8/2018
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. 5/8/2018
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
5/8/2018
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 “system’s” functionality from the user’s [actor’s] 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
5/8/2018
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
5/8/2018
Specifying a use case and its scenarios
Scenarios
Use Case

18. Describing a scenario’s flow of events
5/8/2018
Describing a scenario’s 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
5/8/2018
Example of a use case and its main line scenario

20. Example of textual scenario
5/8/2018
Example of textual scenario

21. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases

22. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

23. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

24. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

25. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

26. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

27. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

28. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

29. Requirements Specification using Use Cases
5/8/2018
Requirements Specification using Use Cases A1 A2 A3 A4

30. 5/8/2018
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
<<include>>
<<extend>>
<<include>>

31. 5/8/2018
Current requirement management practices are based on document driven approaches !
Marketing
Requirements
Spec
Acceptance
Test
Spec
System
Requirements
Spec
System
Test
Spec
System
Design
Spec
System
Integration
Spec
Software
Requirements
Spec
Software
Test
Spec
Design and
Construction
Artifacts

32. 5/8/2018
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
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 ?
5/8/2018
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. Requirements Data Base
5/8/2018
An information systems approach to Requirements Engineering based on Database Technology !
queries
organize
enter
relate
change
analyze
Database Schema
Requirements
Data Base
Repository
reports
documents
audit trails

35. 5/8/2018
An information systems approach to Requirements Management provides multi-user support !
Project Management
Database Schema
Requirements
Data Base
Repository
Marketing Group,
Product Management
Development Groups
[System, HW, SW]
Validation Group

36. An information systems approach to Requirements
5/8/2018
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
5/8/2018
Requirements Definition Improvement
RTM
Improved
Requirements Specification Practices
Requisite-Pro
Conventional
Approaches
Improved Requirements
Management Practices

38. Evaluation Criteria for Requirements Management Tools
5/8/2018
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. Design, Construction & Component Testing
5/8/2018
The Future
Marketing
Requirements
Specification
Acceptance
Test
Specification
Acceptance
Test
Execution
System
Engineering
Specification
System
Validation Test
Specification
System
Validation Test
Execution
Software
Requirements
Specification
Software
Validation Test
Specification
Software
Validation Test
Execution
Design, Construction & Component Testing

40. The Future 5/8/2018 Integrated Knowledge, Task & Workgroup Management
Marketing
Requirements
Specification
Acceptance
Test
Specification
Acceptance
Test
Execution
System
Engineering
Specification
System
Validation Test
Specification
System
Validation Test
Execution
Software
Requirements
Specification
Software
Validation Test
Specification
Software
Validation Test
Execution
Design, Construction & Component Testing

41. The Future - integrated Engineering Information Management
5/8/2018
The Future - integrated Engineering Information Management
Integrated Knowledge, Task
& Workgroup Management
Marketing
Requirements
Specification
Acceptance
Test
Specification
Acceptance
Test
Execution
System
Engineering
Specification
System
Validation Test
Specification
System
Validation Test
Execution
Software
Requirements
Specification
Software
Validation Test
Specification
Software
Validation Test
Execution
Design, Construction & Component Testing

42. 5/8/2018