nsse-2011-sbhattacharya-reqtraceability

8/7/2019 NSSE-2011-SBhattacharya-ReqTraceability

1/57

Traceability of Requirements in

Software Development Process

Swapan Bhattacharya

Department of Computer Science & Engineering

Jadavpur University, Kolkata

700032, IndiaEmail : [email protected]

January 14, 2011


2/57

Contents

Software Engineering In comparison to Conventional Engineering

Evolution in SE

Software Development Process SRD, SA, ST

Issues & Challenges

Traceability of Requirements

Non-engineering example

In Software development

Significance

Domain of Our Research

Research Framework Graph based

Why Graph based framework ?

Introduction to OOG

Application of OOG to Software Development process

Achieving Requirement Traceability

Results & Contribution

January 14, 2011


3/57

Contents


Evolution in SE


Issues & Challenges




Significance

Domain of Our Research



Introduction to OOG




January 14, 2011


4/57

Software Engineering

Software Engineering vis--vis Conventional Engineering (Differences)

Ref : http://www.fact-index.com/s/so/software_engineering.html

January 14, 2011

Traditional engineering is based onphysics, chemistry, and calculus.

Construction and manufacturingcosts are high, so traditionalengineering may only cost 15% of aproject. So engineering cost overrunsmay not affect a project's viability

Traditional engineers apply knownand tested principles

Software engineering is based oncomputer science, informationscience, and discrete math

Software engineering andconsulting often cost more than 50%of a project. Even minor softwareengineering cost-overruns can causea project to fail

Software engineers apply new anduntested elements in many softwareprojects


5/57


Software Engineering vis--vis Conventional Engineering(Similarities)

January 14, 2011

Software engineers aspire to build low-cost, reliable, safe software,which is much like what traditional engineers do.

Software engineers use terms from traditional engineeringdisciplines: requirements analysis, quality control, and projectmanagement techniques

Traditional engineers now use software tools to design and analyzesystems

SE is all pervasive in todays society - Almost all Conventionalengineering disciplines utilize the benefits of computing fortheir business


6/57


Significance

January 14, 2011

In the USA, software drove 1/4 of all increase inGDP during the 1990s (about $90 billion per year),

and 1/6 of all productivity growth (efficiency withinGDP) during the late 1990s (about $33 billion peryear).


7/57


Software Development Process

Requirement Definition

Requirement Analysis

Architecture Design

Detailed Design

Coding & Implementation

Testing

Additionally there are several project management

activities around these phases of development

January 14, 2011


8/57


Evolution in Software Engineering- Collection of programs & Data

- Programs, Data & Documentation

- Software & Hardware components integrated to serve a requirement

- Software, Hardware, Personnel & Processes

- Collection of all of above & many more to offer services for providingsolutions

- Above all it is a mix of Art, Science, Philosophy & Engineering

Current directions

Aspect programming

Service Oriented paradigm

Agile process

January 14, 2011


9/57


Issues and Challenges

January 14, 2011

Highly Complex

Distributed development

Quality driven

Use of Tools and Technology Model based development and Testing

Software Verification consumes a significant amount of effort andtime of the overall software development process.

Software Traceability ensures development of Quality softwareproduct in the most efficient way


10/57

Contents


Evolution in SE


Issues & Challenges


Definition - Requirement, Trace, Software Requirement Traceability Non-engineering example


Significance

Motivation of Our Research

Research Framework Graph basedWhy Graph based framework ?

Introduction to OOG




January 14, 2011


11/57

Definition - Software Requirement

Documented Need of the business

An agreement between the

customer and the developer

regarding the system to bedeveloped

Comprises of

Functional - Functions that the software

system is to execute

Non-functional requirements - Security,performance, availability, maintainability,

reliability, etc

Provided by the relevant

stakeholders of business

January 14, 2011


12/57

Definition Trace, Software Requirement Tracing Trace as defined in English dictionary is to -

Follow, discover or ascertain the course ofdevelopment of something

Software Requirement Tracing is theprocess of following the course or path ofrequirement through the software

development process From Requirement elicitation to

Implementation & Use Both in Forward &Backward direction

January 14, 2011

Software Requirement Traceability is the ability to follow aSoftware Requirement through its various phases of

development in the life cycle


13/57

A Tailoring Shop1. The Customer wants a dress

to be tailor made

2. She chooses the cloth(material)

3. She chooses the style

4. She provides the sizespecifications

5. She also mentions if she istrying to get slim or gainweight

6. She provides the timeline

1. The Designer checks if there isenough cloth according to themeasurement.

2. The designer makes herjudgment if the cloth is suitable

for the style chosen

3. The designer makes her call toanalyze if the timeline ispractical

4. She provides a cost estimation

to the customer

The customer agrees ornegotiates

Requirement

FeasibilityStudy

CostAnalysis

Customer

FashionDesigner

January 14, 2011

Requirement Traceability - A Non-Engineering Example


14/57

1. The Designer assigns a group of people(cutting, stitching, finishing)

2. The designer hands over the detailsgathered from the customer to theworkforce.

1. The workforce analyzes the requirements gathered.

2. The group of cutters cut the cloth according to the measurements.

3. The cutters keep provision so that if there is a change in size

1. After finishing cutting each part, they go back to the specifications and verifies.

2. After finishing cutting each part, they hand over the part to the sewing team andstart working on the new part.


Change management

Requirement Tracing (backward

Testing


January 14, 2011

Implementation


15/57


1.The group of stitchers find the details from the specifications.

2.They stitch each part based on the specifications.

3.The stitchers keep provision so that if there is a change in

size.

4.After finishing stitching each part, they go back to the

specifications and verifies.

5.After finishing stitching each part, they hand over the part to

the finishing team.a


Change management

Requirement Tracing (backward

Testing

January 14, 2011


16/57

1. The group of finishing experts find the details from the specifications.

2. They loosely assemble and stitch each part received from the stitchers based

on the specifications.

3. They keep provision so that if there is a change in size.

4. After assembling any two parts, they go back to the specifications and verifies.

5. After finishing integrating all the parts, they hand over the loosely stitched outfit

to the designer.


Change management

Requirement Tracing (backward)

Testing

January 14, 2011


Implementation


17/57

1. The designer calls the customer for a trial.

2. They customer comes in and tries the outfit .

1. The customer likes itand it fits her well.

2. The finishing teammakes final stitchingof the parts together.

3. Ironing.

4. Delivery

1. The customer likes it but it does not fither well.

2. The finishing team sends the part thatneeds to be altered to thecutting/stitching team.

3. The concerned team makes theappropriate changes based on the

specification and customer feedback.4. Assembly.

5. Trial

1. The customerdoes not like itat all (style,sizeeverything).

2. She calls off

the orderRequirement Tracing(forward)

Feedback & Change

Testing

ReworkJanuary 14, 2011


January 14, 2011


18/57

Requirement Traceability Software Development

Process

RequirementSpecification

FunctionalNon-Functional

RequirementAnalysis

Feasibility StudyCost Analysis

Architecture

DesignImplementation

Testing

CustomerFeedback

Integration

DeliveryMaintenance

ForwardTraceability

BackwardTraceability

January 14, 2011


19/57

Software Requirement Traceability- in phases of Software development process

January 14, 2011


20/57

Software Requirement Traceability

- Definition

A much cited definition of requirements

traceability

The ability to describe and follow the life of

a requirement, in both forward and a

backward direction, i.e., from its origins,

through its development and specification,

to its subsequent deployment and use, and

through periods of ongoing refinement and

iteration in any of these phases.

January 14, 2011


21/57

Requirement Traceability techniques answers the following

questions:

Are all requirements allocated? Are we done?

Is this design element necessary?

Is the implementation compliant with the requirements?

What acceptance test will be used to verify a requirement?

What is the impact of changing a requirement?

Requirement Coverage

Redundancy check

Requirement Sufficiency

Test Coverage

Change Management

January 14, 2011

Requirement Traceability - Significance


22/57

Requirement Traceability - Significance

Verify the conformance of a solution with its needs

Relate and link all the outputs of intermediate phases to

requirements in beginning &solution in the end

Ability to identify impact of requirements to manage changes

easily

In Software development context, Requirment Traceability

offers a viable solution for ensuring

Consistency

Correctness

Requirement change management

Early error detection

Higher quality

Lesser cost

January 14, 2011


23/57

Software Architecture &Requirement Traceability

January 14, 2011

Business Requriements

System Requirements

Functional Non-Functional

Use Cases

Business Rules

Functional Components

Architectural Decisions

Architectural Designs

Technical Components

Ref : http://applicationarchitecture.wordpress.com/2010/05/25/knowledge-

nugget-what-is-requirements-traceability/


24/57

Software Architecture &Requirement Traceability

January 14, 2011

In layered

Architecture

Model, Software

Requirement

Traceability is

gaining significance


25/57

Contents


Evolution in SE


Issues & Challenges




Significance

Focus of Our Research



Introduction to OOG




January 14, 2011


26/57


1. Identification of any error or potential for error as early aspossible

2. Isolation from one phase in production phase from another phasemaintaining the missing links

3. Deployment of appropriate verification tools and techniques atevery phase

4. Integration of customer involvement in software developmentprocess for better requirement understanding & management

5. Evolutionary approach for accommodating updates and/or new

user requirements

January 14, 2011

Traceability of Requirements in Software Development Processaddresses these key issues & concerns


27/57

Contents


Evolution in SE


Issues & Challenges




Significance




Introduction to OOG




January 14, 2011


28/57

Research Framework Graph Model

Why Graph ?

Well-known area of Mathematics

Vast repository of graph constructs

Vast repository of algorithms for analyzing graphs

Capable of modeling related artifacts

Modeling of complex systems becomes simpler

Hence we propose

Graph based framework for modeling all related artifacts of aSoftware Development Process

Graph based Analysis for ensuring Traceability of Requirementsfrom beginning till the end

January 14, 2011


29/57

Object Oriented Graph (OOG)

Hierarchical Directed Graph

Each layer of the graph abstracts OO systems during different

phases of development

Nodes in each layer corresponds to the different artifacts

produced in a phase

Directed edges in each layer models the interconnection or

relations between the artifacts (modeled by Nodes)

January 14, 2011

Research Framework - OOG


30/57

S/W Development UML Models Graph name

Phase used

Requirement Use Case URG

Analysis Diagram (UseCase Relationship Graph)

Detailed Activity ARGAnalysis Diagram (Activity Relationship Graph)

Detailed Sequence D-SG

Design Diagram (Distributed Scenario Graph)

Coding Java code E-CFG

(Classes)

Deployment Component CAG

(Classes to Components) Diagram (Component Architecture Graph)

January 14, 2011



31/57

January 14, 2011

Research Framework

Layered Graph

ARG

URG

D-SG

ECFG

CAG

Trac

eRequriem

ents

across

thephases

ofS/W

Deve

lopmentProcess


32/57

January 14, 2011


Constructs of OOG :

Nodes in Sequence

Nodes connected to more than one Node

In Degree > 1

Out Degree > 1

Nodes in loop (repetitively referred)

Many Nodes in iteration Single Node in iteration


33/57

January 14, 2011

Research Framework OOG Constructs

Nodes of OOG in Sequence

N1

N2

Nodes of OOG Connectedwith More than One Node

N1

N2 N3 N4

Nodes of OOG deing called/Referred More than Once

N1 N2 N3

N4

Nodes of OOG in Iteration i.e.Repeatedly Referred

SingleNode N1

Group of Nodes (N1-N2 in sequence)


34/57

January 14, 2011

Research Framework OOG Paths

Paths in OOG in each layer :

The paths in the graph of each layer gives a measure of

the number of test cases to be executed at each level.

Path computation is done as per a generic formula

defined for each phase.

The path is expressed as a function of the paths in each

node of OOG and is referred to as OGP (Object Graph

Path).

Summarizing this in next slide


35/57

January 14, 2011

Research Framework - OOG PathsSl. No. Type of

Construct

Path Metrics Explanation

Case 1 Nodes are in

sequence

P= OGP(Gx) if OGP(Gx) >

OGP(G1), OGP(G2)....

OGP(Gn) and 1< x < n

Gx is the graph for Node Nx

which has the maximum no. of

paths among all the nodes G1

Gn

Case 2 Out degree > 1 P = OGP(G1) + OGP(G2) +

OGP (Gn) (n-1)

(n-1) nodes N2 Nn whose

graphs are represented by G1,

G2 . Gn

Case 3 In Degree > 1 P = (OGP(G1)+ OGP (G2)-

1)+ .... ..........+ OGP (Gn) +

(n-2)

is the graph for Node 1 which

is called by N2 ..Nn whose

graphs are G2 Gn

Case 4a Iteration/Recursio

n of one Node

P = OGP(G1) + 1, where G1 is the graph for

Node1, OGP is the paths in N1

Case 4b Iteration/recursion

of more than one

node

P = OGP(G) + 1 where G is more than one

node connected as per case 1

or 2

Path calculation metrics for different constructs of OOG


36/57

The significance of paths is different for each graph in each layer

In URG we do not show/identify any paths since it simply shows theinterconnection of use cases only.

In ARG, the paths signify the event paths for a requirement.

This is further detailed out in D-SG where scenario paths can be identifiedas a set of sequence messages realizing a requirement.

Finally in ECFG, the paths denote the independent paths in object-orientedcode similar to McCabes basis set in procedural programs.

Since CAG models the interconnection of components, which does nothave any sequence, the concept of paths does not apply there.

The paths in each layer are analyzed to give a measure of thenumber of test cases to be executed at each level.

The different levels are interconnected to trace the path of Requirements

OOG Paths Significance in different levels

January 14, 2011


37/57

Application of OOG Case Study

Insurance System Requirements

Policy Creation

Policy Maintenance Policy Claim

Policy Termination

January 14, 2011

Next slide lists the Use cases that model theseRequirements. The Use cases for each requirement is

shown together to indicate the mapping clearly


38/57

Case Study: List of Use Cases (Requirements toUse Case Mapping)

Use Case

No.Use Case Name

Use Case

No.Use Case Name

1 Policy Creation 25 Policy Claim

2 Application Entry 26 Accept Claim request

3 Underwriting 27 Validate Claim

4 Underwriting 1 28 Verify initial documents

5 Accept More Details 29 Beneficiary validation

6 Underwriting 2 30 Policy validation

7 Process Error 31 Claim validation

8 Premium Calculation 32 Calculate Claim amount9 Premium Payment 33 Disburse Claim amount

10 Policy Issuance 34 Policy Termination

11 Certificate Generation 35 Lapse

12 Policy Maintenance 36 Non-payment of premium

13 Policy updation 37 Calculate lapse amount

14 Non-financial update 38 Disburse lapse amount

15 Financial update 39 Surrender

16 Policy Value Calculation 40 Partial/full surrender process17 Add new premium 41 Calculate surrender amount

18 Calculate interest 42 Disburse surrender amount

19 Deductions 43 Maturity

20 Loan Processing 44 Calculate maturity value

21 Accept Loan request 45 Disburse maturity amount

22 Verify/recalculate Loan amount 46 Calculate

23 Adjust Policy value 47 Disberse

24 Disburse loanJanuary 14, 2011


39/57

25

26

32

27

3031

2928 33

1

2 3 8 109

11

4 5 6

7

34

4339

35

36 37 38

40 4142

4445

12

13 16 20

14 15 19

21

1817

2322 24

4746

Use Case Relationship Graph (URG)of Insurance System

Nodes 1 2 3 4 5 6 7 8 9 10 11

1 01

a

1

a0 0 0 0

1

a

1

a1a

0

2 0 0 0 0 0 0 0 0 0 00

3 0 0 01

a

1

a

1

a0 0 0 0

0

4 0 0 0 0 0 01

a0 0 0

0

5 0 0 0 0 0 0 0 0 0 00

6 0 0 0 0 0 01

a0 0 0

0

7 0 0 0 0 0 0 0 0 0 0 0

8 0 0 0 0 0 0 0 0 0 0 0

9 0 0 0 0 0 0 0 0 0 0 0

10 0 0 0 0 0 0 0 0 0 01a

11 0 0 0 0 0 0 0 0 0 0 0

Partial Adjacency matrix for URG

Case Study: URG 1st Level of OOG

January 14, 2011


40/57

Analysis Phase : ARG (Activity Relationship Graph)

In the analysis phase, the flow of events of a usecase is modeled using UML activity diagrams.

Each use case event maps to an activity state whichmay be one of the different types available as per

UML 2.0 standard Action state, Decision box, fork,join, etc.

Use cases may be interrelated through the UMLconstructs includes and extends. Likewise, the

activity diagrams realizing the use cases are alsointer-related as modeled in ARG.

January 14, 2011


41/57


42/57

Case Study: ARG 2nd level of OOG

A4

A5

A6

A7

A8

A9

A10

A11

A12

END

A2

A3

A1

Each node of the ARG is an activitydiagram, which can be further visualizedas a graph like ADG and each ADG hasseveral independent paths ADP.

It can be noted that the manner in

which the nodes are connected can bedetected from the ARG.

The nodes that are in sequence areshown by the firm edges.

Likewise the dashed edges denote theother constructs of ARG.

ARG for the Policy Creation of Insurance System

January 14, 2011


43/57

Case Study: ARG Node conflict resolution

AD NoCases of Interleaving Case#

(Node#)

Conflict

ResolutionADP

1 Case 1 (3), Case 2 (2) Case 1 2

2 Case 4 (4, 7) Case 4 2

3 Case 1 (1) - 3

4Case 2 (5, 7, 8, 9), Case 3 (2, 3),

Case 4 (2, 7)

Case 4 6

5 Case 1 (6), Case 2 (4) Case 2 2

6 Case 1 (5), Case 2 (7, 8, 9) Case 2 4

7 Case 3 (4, 6), Case 4 (2, 7) Case 4 4

8 Case 3 (4, 6) - 2

9 Case 3 (4, 6) - 310 Case 1 (9, 11) - 2

11 Case 1 (10, 12) - 3

12 Case 1 (11) - 4

Activity Nodes Conflict Resolution and ADP Values

January 14, 2011


44/57

Case Study: Events Paths from ARG

Calculation of EP

We divide the ARG into subgraphs where eachcomprises of a set of nodes with a type of connection asper the Table.

Subgraph 1: Node 1 calling Node 2, 3 as per Case 2.

EP (SG1) = ADP (Node1) + ADP (Node2) + ADP (Node3) (3-1)

Therefore EP= ADP (Node1) + ADP (Node2) + ADP (Node3) -2

= 2 + 2+ 3 2 = 5

Subgraph 4: Node 10, 11 and 12 in series

EP (SG4) = Max (ADP (10), ADP (11), ADP (12)) + 1= Max (2, 3, 4) + 1

= 4 + 1 = 5

In total there are 34 scenario paths based onthe ARG for Policy Creation requirementReq Traced to events

A4

A5

A6

A7

A8

A9

A10

A11

A12

END

A2

A3

A1

January 14, 2011


45/57

Design Phase : D-SG (Distributed Scenario Graph)

In the design phase, sequence diagrams are commonly usedto implement the sequence of events of an activity diagram.

The event-method mapping is also done here and based onthat the methods are formulated in the design phase.

Sequence diagrams essentially depict the interaction between

objects of different classes through the use of methodscorresponding to an event in activity diagram.

In the next section we discuss the relationship betweenactivity diagrams and sequence diagrams.

This forms the basis of translation of ARG to the next levelgraph D-SG.

January 14, 2011


46/57

D-SG : Relationship between Activity &Sequence Diagram

The different cases of mapping between these two commonly useddiagrams.

Oneto-one When there is a single sequence diagramcorresponding to each activity diagram. Here every event maps

to one or more messages Oneto-many - When there are many sequence diagrams

corresponding to one activity diagram. Here again every eventmaps to one or more messages. There may be different reasonsfor this mapping as explained below

When alternate flow of events in activity diagram are depicted byseparate sequence diagram

When separate sequence diagrams are used to depict the sameActivity events. This is required in distributed development scenariowhere region specific events interleave with generic or common eventsto fulfill a requirement scenario.

January 14, 2011


47/57

D-SG: Sequence Diagrams in DistributedEnvironment

Global distributed model for development introduces complexity

Software architecture involves lot of interleaving between the sequencediagrams

We apply the concept of OOG at this level for modeling the interleaving ofsequence diagram capturing all possible scenarios of a system.

We name it as Distributed Scenario graph (D-SG).

It is a hierarchical directed graph where the top level identifiesconnections between sequence diagrams and direction denotes thesequence or order in which they are connected.

The next level models the object interactions within a sequence diagram

as a graph. Optimum Scenario Path (OSP) metrics that measures the minimum

number of independent path in the D-SG can be calculated.

January 14, 2011


48/57

Case Study: D-SG 3rd level of OOG S1

S2 S3 S4

S5

S6 S7

S8

S10

S9

S12

S11

S13

S14

S15 S16 S17

S19 S20 S21

S22

S18

S23

S24 END

D-SG of PolicyCreation

January 14, 2011

In total there are 71

scenario paths basedon all the relatedsequence diagramsmodeling therequirement.

Trace Requirementsto SequenceDiagrams at DesignPhase


49/57

Case Study: Activity events traced toSequence messages

Activity Diagram Activity Node Sequence Diagram Sequence Node

Application Entry

Main Application

Entry Policy specific

A1 A2, A3 Application Entry Main

Application Entry Policy specific

Application Entry Location

Specific

S1 S2, S3, S4 S5, S6, S7,

S8

Underwriting1 A4 Underwriting1 S9

Accept more details A5 Accept more details S10

Underwriting2 A6 Underwriting2 S11

Data entry error,

Business logic error

A7 A8 Data Entry Error Business Logic

Error

S12 S13

Premium calculation A9 Premium Calculation main

Premium Calculation Policy

Specific Premium calculationLocation Specific

S14 S15, S16, S17 S18,

S19, S20, S21

Premium payment A10 Premium payment S22

Issue policy A11 Issue policy S23

Certificate generation A12 Certificate generation S24

Activity Diagram to Sequence Diagram Mapping

January 14, 2011


50/57

Coding Phase : ECFG (Extended ControlFlow Graph)

January 14, 2011

White-box testing based on Control Flow Graph (CFG) though widely

used for procedural systems fails to be applicable as it is in case of Object

Oriented systems.

A new model Extended Control Flow Graph (ECFG) has been proposed

which is a layered graph with a collection of CFGs of the individualoperations of the OO software.

A new metrics Extended Cyclomatic Complexity (E-CC) has been

proposed which gives a measurement of the minimum number of test cases

that should be designed for ensuring covergae of all the independent controlpaths in the code.


51/57

In an E-CFG, the nodes are Methods and each method is represented byMcCabes CFG. The nodes may be connected in one of these ways -

Operations/Methods connected in series

Method calling one/more methods one/many times Many methods calling one particular method

Method is recursively called

Extended Cyclomatic Complexity number (E-CC) is derivedbased on the McCabes Cyclomatic Complexity of the

individual operations/methods. Represents the minimum no. of test

paths in the Object oriented code

Coding Phase : ECFG (Extended ControlFlow Graph)


52/57

ECFG for part of the system

Case Study: ECFG 4th level of OOG

E-CC (Extended Cyclomatic Complexity measures the minimumnumber of test paths through the OO code


53/57

Deployment Phase : Component Diagram forCase Study

Classes developed during coding phase are packaged into componentsand each component interact with others through well defined interfaces

Component Diagram of Insurance System


54/57

Case Study : CAG 5th Level of OOGComponent Architecture Graph

Component Diagram Modeled as a Graph named

Component Architecture Graph (CAG)

C1C2

1

C3 2 C4

3

C5

4

C6

5

C7

6

C8C9

C10C11

7

8


55/57

Deployment Phase : CAG Metrics

Component Level Metrics Component Fan-in Factor (CFIF) Component Fan-out Factor (CFOF) Component Interaction Factor (CIF) ( Average of CFIF & CFOF)

Component to Component Coupling Metrics Interface Count (IC) Component Paths (CP)

Architecture Level Metrics Architecture Component Interaction Factor (ACIF)Architecture Interface Count (AIC)Architecture Paths (AP)

Overall Complexity ACIF + AIC + APNamed as -

Component Architecture Complexity Measurement Metrics (CACMM)


56/57

ReferencesBooks :1. Ananya Kanjilal, Sabnam Sengupta and Swapan Bhattacharya, Graph Based Analysis of

Object Oriented Systems: An Integrated Approach, Nova publishers2. Swapan Bhattacharya, Ananya Kanjilal and Sabnam Sengupta, Tools and Techniques for

Model Based Testing, Handbook of Research on Software Engineering and ProductivityTechnologies: Implications of Globalization, Information Science Reference (Imprint of IGIGlobal), pp 226-249, August 2009

January 14, 2011

Journals:3. Sabnam Sengupta, Ananya Kanjilal, Swapan Bhattacharya,AGraph Based Approach to

Measure Complexity of Component Based Architecture, to be published in ACM SigsoftSoftware Engineering Notes (SEN), Vol. , Issue , pp , Jan 2011.

4. Dipankar Majumdar, Sabnam Sengupta, Ananya Kanjilal, Swagata Kundu, A MathematicalReusability Model for Quantifying the Reduction in Development Effort, ACM SigsoftSoftware Engineering Notes (SEN), Vol. 35, Issue 4, pp 1-8, July 2010.

5. Ananya Kanjilal, Goutam Kanjilal and Swapan Bhattacharya, Metrics based analysis ofrequirements for object-oriented systems: An empirical approach, INFOCOMP Journal ofComputer Science, Vol 7, No. 2, pp 26-36, June 2008.

6. Swapan Bhattacharya and Ananya KanjilalCode Based Analysis of Object OrientedSystems, Journal of Computer Science & Technology JCST, Springer-Verlag, Vol 21, No. 6,pp 965-972, November 2006.


57/57

Thank You

nsse-2011-sbhattacharya-reqtraceability

Documents