Towards a GoalOriented Requirements Methodology Based on the Separation of Concerns Principle

1
Towards a Goal-Oriented Requirements Methodology
Based on the Separation of Concerns Principle
VI Workshop on Requirements Engineering

• Geórgia Maria C. Sousa
• Jaelson Brelaz de Castro

2
Outline

• Context
• Our Proposal
• Case Study
• Conclusions

3
Context
4
Motivation

• Increasing importance of reusability,
  maintainability and comprehensibility of software
  system artifacts.
• Separation of Concerns is one of the Software
  Engineering principles to achieve those qualities
• It means deal with different issues of a problem
  individually so that it is possible to
  concentrate on each one separately

5
Problem Statement

• BUT, sometimes
• references to the specification of one
  requirement is scattered across multiple
  artifacts (scattering)
• one requirement artifact contains references to
  multiple requirements (tangling).
• Ex. each non-functional requirement (NFR) is
  normally repeated in every use case that the NFR
  affects

This fact makes it DIFFICULT to COMPREHEND,
REUSE and MAINTAIN the software artifacts
6
Our Proposal
7
Proposal Charactheristics

• Objective
• improve reusability, maintainability and
  comprehensibility of requirements specifications
• How?
• requirements should be represented according to
  the Separation of Concerns (SoC) principle.
• Proposed Solution
• a Goal-oriented REquirements Methodology founded
  on the SoC principle.
• GREMSoC provides a way to represent requirements
  apart from the requirements they affect and to
  specify the composition between them in a
  noninvasive way.

8
Proposal Outline
9
GREMSoC Activities
10
Functional Analysis and Specification

• We adopt the Cockburns approach 16,24 for the
  functional analysis for two reasons it is
  goal-oriented and use-case driven.

Steps of Cockburns Approach
Basic Use Case Template (adapted from 25)
11
Non-Functional Analysis and Specification

• We adopt the NFR Framework, but we include a new
  activity Specify Operations.

GREMSoC approach to analyze and specify NFRs
Operationalization Template (adapted from 25)
12
Crosscutting Requirements Identification and
Composition

• Firstly, it is necessary to identify among the
  requirements which of them are crosscutting.
• A requirement is crosscutting if it affects other
  requirements in such a way that the crosscutting
  requirement needs to be applied in some point of
  other requirements specification.
• The next step is specifying how each crosscutting
  requirement affects the requirements it
  transverses.
• we provide a composition table that should be
  specified for each crosscutting requirement

13
Composition Table

• This table should be specified for each
  crosscutting requirement

• To determine how a crosscutting requirement is
  applied in a particular point that it affects, we
  use the following composition rule operators
  26
• Overlap indicates that the crosscutting
  requirement should be applied before or after the
  step of the scenario it transverses
• Override the behaviour described by the
  crosscutting requirement substitutes the
  behaviour defined by the step

14
Case Study
15
Case StudyInternet Banking System

• Following the Proposal Steps (1/3)

16
Case Study Functional Specification
17
Case StudyInternet Banking System

• Following the Proposal Steps (2/3)

18
Case Study Non-Functional Analysis
19
Case Study Non-Functional Specification
20
Case StudyInternet Banking System

• Following the Proposal Steps (3/3)

21
Crosscutting Requirements Identification and
Composition
22
Conclusions
23
Conclusions

• Difficulty in applying the SoC principle in the
  specification of requirements artifacts due to
  the strong relationship and the interdependencies
  among some requirements.
• This fact is true especially in the specification
  of non-functional requirements that are naturally
  crosscutting.
• The purpose of GREMSoC methodology is to promote
  an approach to solve this problem
• HOW? Selecting goal-oriented techniques to
  specify requirements separately and providing a
  way to compose these requirements in an artifact
  apart.
• THEREFORE, using GREMSoC methodology the
  comprehensibility, the maintainability and the
  reusability of requirements specification are
  improved.
• Our approach relies on well-known techniques
• Furthermore, the composition mechanism is quite
  simple.

24
The End
CONTACTS AND INFORMATION Geórgia Sousa
(gmcs_at_cin.ufpe.br) Jaelson Castro
(jbc_at_cin.ufpe.br)
25
Difference Between UML Mechanisms and Our
Approach (1/3)

• INCLUDE

THE USE CASES SPECIFICATIONS EXPLICITLY DEPEND ON
THE CHECK INTERNET PASSWORD
26
Difference Between UML Mechanisms and Our
Approach (2/3)

• EXTENDS

It does not make reference to the Check Internet
Password. They only need to specify the
extension points.
It makes references to those use cases. ITS
SPECIFICATION IS NOT INDEPENDENT.
27
Difference Between UML Mechanisms and Our
Approach (3/3)

• OUR PROPOSAL

ALL USE CASES SPECIFICATIONS ARE INDEPENDENT OF
EACH OTHER