Requirements Engineering-Based Requirements Engineering-Based Conceptual ModellingConceptual Modelling

From: Requirements EngineeringFrom: Requirements Engineering

E. Insfran, O. Pastor and R. WieringaE. Insfran, O. Pastor and R. Wieringa

Presented by Chin-Yi TsaiPresented by Chin-Yi Tsai

2

OutlineOutline

IntroductionIntroduction

TRADE and OO-MethodTRADE and OO-Method

A Requirements Engineering-Based Conceptual A Requirements Engineering-Based Conceptual Modelling ApproachModelling Approach

Conclusions and Further WorkConclusions and Further Work

3

IntroductionIntroduction Software development processSoftware development process

Requirement AnalysisRequirement Analysis System AnalysisSystem Analysis System DesignSystem Design Implementation Implementation TestingTesting MaintenanceMaintenance

To provide a set of techniques and methodsTo provide a set of techniques and methods To capture software requirementsTo capture software requirements

To provide a way To provide a way to move from requirement to a conceptual schema in a to move from requirement to a conceptual schema in a traceable traceable

wayway

improve the improve the qualityquality of the software production process of the software production process

Translation(iterative, incremental)

Translation(iterative, incremental)

Requirement ModelRequirement Model

SA ModelSA Model

SD ModelSD Model

traceability

traceability

4

Full model-based code generationFull model-based code generation

Introduction (cont’d)Introduction (cont’d)

The approach combines a framework for The approach combines a framework for requirements engineering (requirements engineering (TRADETRADE) and a graphical ) and a graphical object-oriented method for conceptual modelling object-oriented method for conceptual modelling and code generation (and code generation (OO-MethodsOO-Methods).).

Providing a precise methodological guidanceProviding a precise methodological guidance

User requirement (TRADE)User requirement (TRADE)

Conceptual schema (OO-Methods)Conceptual schema (OO-Methods)

Final software produceFinal software produce

5

Introduction (cont’d)Introduction (cont’d)

Quality of the software production processQuality of the software production process Provide predictabilityProvide predictability Improve productivityImprove productivity

traceabilitytraceability

6

TRADE and OO-MethodTRADE and OO-Method

The TRADE is a set of The TRADE is a set of techniquestechniques and and heuristicsheuristics based on an analysis of structured and object-based on an analysis of structured and object-oriented specification methods.oriented specification methods.

Specifying external interaction s and their Specifying external interaction s and their properties in TRADEproperties in TRADE Mission statementMission statement Function refinement treeFunction refinement tree Context diagramsContext diagrams Use case diagramsUse case diagrams Scenario diagramsScenario diagrams

Requirement ModelRequirement Model

7

TRADE and OO-Method (cont’d)TRADE and OO-Method (cont’d)

The OO-Method is an object-oriented method that The OO-Method is an object-oriented method that provides a set of well-defined and complementary provides a set of well-defined and complementary graphical techniquesgraphical techniques to build a conceptual schema to build a conceptual schema of the system.of the system.

8

A Requirements Engineering-Based Conceptual Modelling ApproachA Requirements Engineering-Based Conceptual Modelling Approach

9

Requirements Modelling PhaseRequirements Modelling Phase The purpose of the RM is to accurately and precisely The purpose of the RM is to accurately and precisely

capture what the customer wants to have built.capture what the customer wants to have built. Without high-level training in the notation can understand and Without high-level training in the notation can understand and

review themreview them

The Objectory method introduces use case-driven analysis The Objectory method introduces use case-driven analysis (UCDA)(UCDA) Actor and use casesActor and use cases

UCDA is simple, and use case descriptions are based on UCDA is simple, and use case descriptions are based on natural conceptsnatural concepts

Two disadvantages of using UCDATwo disadvantages of using UCDA The difficulty in finding the correct abstraction level to specify the The difficulty in finding the correct abstraction level to specify the

use caseuse case Finding a process to analyze and translate the use case Finding a process to analyze and translate the use case

specification into a conceptual modelspecification into a conceptual model

10

RM techniquesRM techniques

Mission statementMission statement Describe the purpose of the system in one or two Describe the purpose of the system in one or two

sentences.sentences.

Function refinement treeFunction refinement tree Deals with external interaction partitioning according to Deals with external interaction partitioning according to

the different business areas or business objectives.the different business areas or business objectives.

Use case modelUse case model Include the use case specification to specify the Include the use case specification to specify the

composition of external interaction and the use case composition of external interaction and the use case diagram to show communication between the diagram to show communication between the environment (actors) and the system.environment (actors) and the system.

11

Mission Statement and Function Refinement TreeMission Statement and Function Refinement Tree

12

Use CasesUse Cases

Use cases were introduced in OOSE to represent Use cases were introduced in OOSE to represent external system functionality.external system functionality.

A use case is an interaction between the system A use case is an interaction between the system and an external actor.and an external actor.

The purpose of use case specification is to The purpose of use case specification is to describe the describe the flow of events in detailflow of events in detail, including how , including how the use case starts, ends, modified the system and the use case starts, ends, modified the system and interacts with actors.interacts with actors.

13

14

Conceptual Modelling PhaseConceptual Modelling Phase

The purpose of the conceptual modelling phase is to The purpose of the conceptual modelling phase is to represent use requirements in a specification of represent use requirements in a specification of whatwhat the the system does as if there were a perfect implementation system does as if there were a perfect implementation technology available.technology available.

The OO-MethodThe OO-Method Object modelObject model

Simple class diagramSimple class diagram Dynamic modelDynamic model

State diagramState diagram Collaboration diagramCollaboration diagram

Functional modelFunctional model Textural model used to capture the semantic that is attached to any Textural model used to capture the semantic that is attached to any

change of an object state as a consequence of a service occurrencechange of an object state as a consequence of a service occurrence

15

Requirements Analysis Process (RAP)Requirements Analysis Process (RAP)

In order to evaluate whether that use case has In order to evaluate whether that use case has been provided, we should show what functionality been provided, we should show what functionality was allocated to which class or classes for each was allocated to which class or classes for each use case.use case.

Identify the responsibilityIdentify the responsibility

Allocate the identified responsibilityAllocate the identified responsibility

Use Case Use Case …

16

Notation and TechniqueNotation and Technique

The deal with the activity of identifying The deal with the activity of identifying responsibilities within the use case specification responsibilities within the use case specification and allocating them into class componentsand allocating them into class components Use sequence diagramUse sequence diagram Specify detailed behavior and low-level specificationSpecify detailed behavior and low-level specification

There is at least one sequence diagram per use There is at least one sequence diagram per use case, one for the basic course of action, and one case, one for the basic course of action, and one for each alternative course of action (if any).for each alternative course of action (if any).

17

18

Validation, Verification and TraceabilityValidation, Verification and Traceability

The purpose of the RAP is to obtain a consistent The purpose of the RAP is to obtain a consistent first version of the conceptual schema.first version of the conceptual schema. Validation, verification and traceability are key issues.Validation, verification and traceability are key issues.

The traceability model we use is the structural and The traceability model we use is the structural and cross-reference-based model.cross-reference-based model.

The validation consists of reviewing each one of The validation consists of reviewing each one of the use cases and its corresponding sequence the use cases and its corresponding sequence diagrams with the user to see that they provide the diagrams with the user to see that they provide the behavior implied in the use case specification.behavior implied in the use case specification.

19

Validation, Verification and Traceability (cont’d)Validation, Verification and Traceability (cont’d)

Object ModelObject Model The verification we carry out involves looking at all The verification we carry out involves looking at all

the identified the identified classesclasses and their services in the and their services in the sequence diagramssequence diagrams..

To re-examine the use cases and the To re-examine the use cases and the corresponding sequence diagram to find that corresponding sequence diagram to find that missing behavior.missing behavior.

For traceability purposes, we can represent the For traceability purposes, we can represent the allocation and flowdown of use cases to classes by allocation and flowdown of use cases to classes by means of a means of a function decomposition tablefunction decomposition table..

20

Validation, Verification and Traceability (cont’d)Validation, Verification and Traceability (cont’d)

21

Conclusions and Further WorkConclusions and Further Work

Research in the requirements engineering area Research in the requirements engineering area should be oriented towards properly embedding should be oriented towards properly embedding requirements engineering into the software requirements engineering into the software production process as a whole.production process as a whole.

The integration providesThe integration provides Start from generally accepted notational standards and Start from generally accepted notational standards and

techniques to specify user requirementstechniques to specify user requirements Gives methodological guidance to convert these Gives methodological guidance to convert these

requirements into a precise conceptual schemarequirements into a precise conceptual schema Links this conceptual schema with model-based code Links this conceptual schema with model-based code

generation techniques of the OO-Methodgeneration techniques of the OO-Method