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

Outline of presentation 5/8/2018 Outline of presentation Introduction to requirements engineering Improving requirements specification practices Improving requirements management practices Vision Tools

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 ?

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

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

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

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

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

Improving Requirements Engineering 5/8/2018 Improving Requirements Engineering Improved Requirements Specification Practices Conventional Approaches Improved Requirements Management Practices

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

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

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

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

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

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

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 ... ...

Specifying a use case and its scenarios 5/8/2018 Specifying a use case and its scenarios Scenarios Use Case

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

Example of a use case and its main line scenario 5/8/2018 Example of a use case and its main line scenario

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

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

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

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

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

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

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

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

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

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

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>>

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

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

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

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

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

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

Requirements Definition Improvement 5/8/2018 Requirements Definition Improvement RTM Improved Requirements Specification Practices Requisite-Pro Conventional Approaches Improved Requirements Management Practices

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

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

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

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

5/8/2018