Hybriding CMMI and Requirement Engineering Maturity

& Capability Models

Applying the LEGO Approach for Improving Estimates

Luigi Buglione

, Jean Carlo Rossa Hauck

, Christiane Gresse von Wangenheim

and

Fergal Mc Caffery

Industry & Services BU, Engineering.IT SpA, Rome, Italy

Computer Science, UFSC - Federal University of Santa Catarina, Florianopolis, Brazil

Computing and Maths, Dundalk Institute of Technology, Dundalk, Ireland

Keywords: Process Appraisals, Process Improvement, CMMI, ISO/IEC 15504, LEGO, Requirement Management,

Maturity & Capability Models.

Abstract: Estimation represents one of the most critical processes for any project and it is highly dependent on the

quality of requirements elicitation and management. Therefore, the management of requirements should be

prioritised in any process improvement program, because the less precise the requirements gathering,

analysis and sizing, the greater the error in terms of time and cost estimation. Maturity and Capability

Models (MCM) represent a good tool for assessing the status of a set of processes, but an inner limit of any

model is its scope and approach for describing a certain issue. Thus, integrating two or more models with a

common area of focus can offer more information and value for an organization, keeping the best

components from each model. LEGO (Living EnGineering prOcess) is an approach projected for this

purpose. This paper proposes a LEGO application hybridizing a ‘horizontal’ model (a MM containing

processes going through the complete supply chain, from requirements right through to delivery, e.g. CMMI

or ISO 12207/15504) with a few specific ‘vertical’ models (MMs with focus on a single perspective or

process category, e.g. TMMi or TPI in the Test Management domain, P3M3 and OPM3 in the Project

Management domain) for Requirement Engineering.

1 INTRODUCTION

One of the latest neologisms from the last 5 years is

‘glocal’(Swyngedouw, 1997), which refers to the

ability to “think globally and act locally”. Cultural

differences among countries should be taken into

account more and more when designing processes,

particularly as very interesting ideas may arise from

a comparison among different practices. For

instance, when comparing Western and Eastern

worlds and behaviours, Western people ‘act’,

Eastern people ‘think’ (a bit more) before acting

(Hassan et al., 2010) (Luo, 2008) (Chang, 2010). But

observing both perspectives and attitudes, it is

possible to represent it as a sort of ‘yin-yang’,

complementing each other (Stawicki, 2008). Thus,

there is never a better idea, but different shades to be

considered when (re)designing a process and/or a

technique.

Estimation is one of the core processes in any

organization. According to the Webster-Merriam

dictionary, it is “1. a judgment or opinion about

something; 2. the act of judging the size, amount,

cost, etc., of something : the act of estimating

something; 3. a guess about the size, amount, cost,

etc., of something”. PMBOK defines estimation as

“a quantitative assessment of the likely amount or

outcome. Usually applied to project costs, resources,

effort, and durations and is usually preceded by a

modifier (i.e., preliminary, conceptual, feasibility,

order-of-magnitude, definitive)” (PMI, 2008).

However, estimates often have a higher error rate

than expected, by running a RCA (Root-Cause

Analysis) for detecting issues, it is possible to

remove issuing surrounding requirements. The top-

10 of estimation “deadly sins" (McConnell, 2002)

(McConnell, 2006) can be a valid starting point for

improving it, noting how much the missing (or the

low quality) of requirements and its related historical

data as well their granularity level could largely

impact on the estimation process. Using again

CMMI-DEV elements, Project Planning (PP)

Buglione L., Hauck J., Gresse von Wangenheim C. and Mc Caffery F..

Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for Improving Estimates.

DOI: 10.5220/0004082700550061

In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 55-61

ISBN: 978-989-8565-19-8

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

process area – where estimation is run – in the

‘Related Process Areas’ includes also Requirement

Management (RM) and Requirement Development

(RD) for the management of requirements; PP SP1.2

affirms that “The estimates should be consistent with

project requirements to determine the project’s

effort, cost, and schedule”. It’s the same when using

the SPICE (ISO/IEC 15504) language, dealing with

MAN.3 (Project Management) for estimates and

ENG.1 (Requirements Elicitation) plus ENG.4

(Software Requirement Analysis) (Buglione et. al.,

2012)..Thus, there is a huge need for any

organization to first reinforce the Requirement

Management process (in a broader sense, not strictly

in the CMMI terms because it’s a ML2 process

area), starting from elicitation and analyzing (RD –

Requirements Development, ML3) throughout

requirements management.

But what’s the problem? What does not currently

exist?

The aim of this paper is to propose a LEGO

(Living EnGineering prOcess) application for the

Requirements Engineering (RE) area, matching

together different RE processes using a four-step

process, in order to obtain a comprehensive process

to be applied in an organization, which could enable

better estimates to be achieved.

The paper is organized as follows: Section 2

proposes a series of specific requirements

management maturity models and frameworks, for

extracting any possible element of interest (EoI) for

reinforcing a typical Requirements Engineering

(horizontal) process. Section 3, summarizes the

LEGO approach, with its main elements and four-

step process. Section 4, shows the deployment of

LEGO to the Requirements Management process,

joining the CMMI-DEV RD process area with the

EoI from the previously examined RE

models/frameworks. Finally, Section 5 provides

some conclusions and the next steps for this work.

2 REQUIREMENT

ENGINEERING: SOME

MATURITY & CAPABILITY

MODELS (MCM)

During the ‘90s the ‘maturity models mania’ started

(Copeland, 2003) and now many ‘something-maturity-

model(s)’ exist in many application areas and

domains, and this is also the case for (software) RE.

Table 1, presents some Maturity Models in the RE

arena that can represent potential “vertical” models

to be integrated into a consolidated and well known

“horizontal” model such as CMMI-DEV (SEI, 2010)

or SPICE (ISO/IEC 15504) (ISO, 2007).. The

specific processes to be involved would be

respectively: RD (Req. Development) and RM (Req.

Management) for CMMI_DEV and ENG.1 (Req.

Elicitation) and ENG.4 (Software Design) processes

for SPICE. For each of the models we present: its

representation types, number of MLs, process

architecture type and further comments/notes.

Some comments about those RE models that could

be useful for the LEGO analysis:

 A general trend in RE is to propose staged models

more than continuous ones  suggesting a

‘standard’ way to progress maturity within an

organization more than focusing upon each single

RE process. This provides interesting information

should be considered when re-modelling these

models into a target model according to its

process architecture.

 No particular architectural elements have been

introduced/modified against well-known

horizontal models, differently than in other

application domain (e.g. see P3M3 (OGC, 2006)

and OPM3 (PMI, 2008) in the Project

Management)  there is evidence that many of

those models are still maturing and evolving (e.g.

(Beecham et al., 2003) and (Solemon et al., 2009)

have deployed only details for ML2).

 Documentation should be provided to fully

describe the requirements and project scope 

this is a point of contact with Quality

Management Systems (QMS) such as ISO 9001 or

20000-1, this is typically stressed less in CMMI

constellations (see also the results from Mutafeljia

& Stromberg’s mapping (Mutafelija, 2008)) but

thus is not the in SPICE related models (including

a specific process on Documentation: SUP.7).

Another interesting related issue concerns the

quest for reducing requirements volatility (e.g.

REAIMS) and defining a taxonomy of

requirement attributes for properly managing

them by interest groups and/or techniques (e.g.

REPM), for instance, making a clear distinction

between functional vs. non-functional product

requirements from the outset. This is a relevant

issue in the FSM (Functional Size Measurement)

community, where there is often – at the practical

level – a misconception about the roles and

relevance of NFR (Non-Functional Requirements)

against FUR (Functional User Requirements) in

the estimation process, where NFR are typically

underestimated because not properly evidenced

(and sized) from the requirement elicitation phase.

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

Table 1: Some Requirement Engineering Maturity

Models/Frameworks.

Model/

Framework

Repr.

Type

ML (#)

Architect-

Type

Comments/Notes

IBM RMM

(Heurmann,

2003)

(Sehlhorst,

2007)

Staged

6 [0-5]

Level-based

---

IAG RMM

(IAG, 2009)

Staged

6 [0-5]

Matrix-

based

6 dimensions

(process, practices

& techniques,

deliverables,

technology,

organization, staff

competency)

PRTM

CRMM

(Hepner,

2006)

Staged

4 [0-3]

Level-based

---

BTH REPM

Gorschek et al,

2002)

(Gorschek,

2011)

Contin

uous

Process-

based

7 processes

Variable number of

sub-process areas

per process

REAIMS

Process MM

(Sommerville,

2005)

Staged

3 [1-3]

Process-

based

8 process areas and

66 practices (basic,

intermediate,

advanced)

R-CMM

(Beecham et

al. 2005)

(Beecham et

al., 2003)

Staged

5 [1-5]

Process-

based

‘Processes’ =

Practices (e.g. 20

‘processes’ at ML2)

- Adaptation of

GQM for deriving

practices

R-CMMi

(Solemon et

al., 2009)

Staged

5 [1-5]

Process-

based

‘Processes’ =

Practices (e.g. 20

‘processes’ at ML2)

- Adaptation of

GQM for deriving

practices using the

CMMI process

architecture

The allowed choices for the “Architectural Type”

column are: Level-based (high-level depth, generic

description of needed actions per ML), e.g. (Ambler,

2010); Matrix-based (mid-level depth, indication of

a series of improvement drivers with a specific text

per each cell), e.g. (ISO, 2009); Process-based (low-

level depth, with a consistent process architecture

and repeatable elements per each defined process),

e.g. (SEI, 2010)(ISO, 2007).

3 EXPERIENCING LEGO TO

REQUIREMENT

ENGINEERING

3.1 The LEGO Approach

Recently we proposed a common-sense approach,

called LEGO (Living EnGineering prOcess)

(Buglione et al., 2011) for stimulating organizations to

improve their own processes, taking pieces (such as

the real LEGO bricks) from multiple, potential

information sources to be integrated to form a

unique, reinforced picture for a particular process or

set of processes. The starting point – for this paper –

is that any model/framework can represent only a

part of the observed reality, not all of its possible

views, simply because it needs to represent one

single viewpoint at a time. Thus, through handling

similar elements from different sources, we can

hopefully find more ‘fresh blood’ for improving the

organizational processes.

LEGO has four main elements, as shown in

Figure 1:

Figure 1: The four elements of the LEGO approach.

1. a ‘Maturity & Capability Models’ (MCM)

repository (www.gqs.ufsc.br/mcm), from

relevant processes or MMs (meaning also the

other dimensions – not yet the process

dimension) can be identified;

2. knowledge about the process architecture of each

model, for understanding how to transform

desired elements from a certain model into the

target format, especially when considering that

the source models may have different

architectures that need to be integrated into a

single model;

3. mapping(s) & comparisons between relevant

models, in order to understand the real

differences or the deeper level of detail from

‘model A’ to import into ‘model B’;

4. a process appraisal method (PAM) to be applied

on the target BPM (Business Process Model).

LEGO has also a related four-step process:

Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for

Improving Estimates

1. Identify your informative/business goals:

clearly identify your needs, moving from the

current BPM version and content.

2. Query the MCM repository: browse the MCM

repository, setting up the proper filters in order to

obtain the desired elements (processes; practices;

etc.) to be inserted in the target BPM.

3. Include the selected element(s) into the target

BPM: include the new element(s) in the proper

position in the target BPM (e.g. process group,

maturity level, etc.).

4. Adapt & Adopt the selected element(s):

according to the process architecture of both

process models (the target and the source one), the

selected elements may need to be adapted,

tailoring such elements as needed.

3.2 Applying LEGO to Requirement

Engineering

One of the main requirements for improving

estimates is to reinforce the management of

requirements from an overall viewpoint, from their

elicitation through to the day-to-day management.

The focus of this work is exclusively on external

models as opposed to actual (living and active)

organizational practices, so that any reader can

easily access to the original sources and fully

understand the LEGO process, that could

(eventually, if interested) be replicated in his/her

own organization through forward moving from

their existing organizational Business Process

Model (BPM). Our aim is to show how to hybridize

ideas for obtaining a better and more comprehensive

final result. Thus, we list the preconditions, process

and main results from the application of the LEGO

process to the Requirements Engineering (RE)

domain, in order to propose a better RE process that

may be applied in an organization:

1. Identify your informative/business goals:

improve the estimation capability and results by a

refinement in the overall management of

requirements (business, technical):

2. Query the MCM repository: in this paper we

consider CMMI-DEV RE processes (RD; RM) as

the baseline for working upon, adding eventual

practices from the other RE models/frameworks

listed in Table 1. After a detailed analysis, we

discarded the IBM RMM, proposing only a high-

level staged path with no detailed elements, and

focus on the remaining ones. Table 2 proposes the

list of potential elements of interest (EoI) to

consider for improving CMMI processes on RE.

Table 2: RE Maturity & Capability Models (MCM):

Elements of Interest.

Model/

Framework

Elements of Interest (EoI)

IAG RMM

 Technology: the introduction of workflow

environments for easily sharing information for

keeping requirements could be useful  CMMI-

DEV RD GP2.3 (Elaboration section in Part 1)

 Staff competency: suggested the introduction of

Bloom’s levels as informative notes for all GP

2.5, not only for those two PAs

PRTM CRMM

 Level 1: link between product and customer

requirements, using e.g. QFD (quality function

deployment)  it could be introduced also in

CMMI-DEV RD SP 3.4, not only in SP 2.1 (as

currently done) for closing the analysis

BTH REPM

 RE.SI (Stakeholders and Req. Source

Identification)  more specific practice to be

added about Requirement Elicitation to CMMI-

DEV RD SG1

 RE.GA.a2 (Qualify and Quantify Quality

Requirements)  currently missing a more clear

and direct link with CMMI-DEV PP SP 1.2

 DS.GA.a2 (Define Requirement Attributes) 

currently less stressed (e.g. FUR vs NFR for

FSM/FPA – Function Point Analysis, as

requested in CMMI-DEV PP, SP 1.4

REAIMS

Process MM

Basic practices:

 3.1 Define a standard document structure:

missing, could be added in CMMI-DEV RD

SG1, stressing the need for having an

organizational ‘standard’ for comparing different

types of requirements, having impact also on

planning (different roles, productivities and

schedules for different activities  PP SP 1.4).

Again, it’d help also PP SP 1.2 because it’d

address better the

 3.8 Make the document easy to change 

criteria for writing better requirements, could be

stressed more in CMMI-DEV RD SG1 / RM

SG1, SP 1.3

 6.2 Use language simply and concisely 

criteria for writing better requirements could be

added as a note for CMMI-DEV RD SP 1.2, sub-

practice #1

Advanced practices:

 9.8 Identify volatile requirements: suggested to

introduce the concept of ‘volatility’ also in the

RD process definition by an informative note

(e.g. “…verifying the new need will not be yet

addressed by a formalized requirement…”, with

a link to RM, SP 1.3),  see also R-CMMi P20

process, same issue

R-CMM

 ML2: P19: Agree and document technical and

organisational attributes specific to project 

CMMI-DEV RD deals with customer and

product requirements, not addressing with further

informative notes about which could be possible

‘constraints’ such as those ones from the analysis

of organizational attributes  reinforce RD SP

1.1

R-CMMi

 ML2: P20: Institute Process to Maintain Stability

within Project  always about the need to

minimize ‘volatility’, in terms of management 

same comment than for REAIMS practice 9.8

3. Include the selected element(s) into the target

BPM: looking at the analysis of potential EoI in

Table 2. The main improvements/suggestions

seem to be mainly associated with the RD

process, rather than the RM process. Table 3

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

Table 3: CMMI-DEV RD: suggestions for improvements.

CMMI-DEV v1.3

RD process

Suggested Improvements

SG 1 Develop

Customer Needs

 Introduce a new SP 1.0 about

Stakeholders Identification and

Engagement. Rationale: reinforce current

formulation, before running SP 1.1.

Nowadays, stakeholder engagement is the

sub-practice #1 within SP 1.1.

 Insert a note about possible standards (de

jure/de facto) that could be

consulted/useful for a better application of

RD process (e.g.. (AccountAbility, 2011)).

SP 1.1 Elicit Needs

 Introduce a sub-practice about the

definition of requirement attributes,

inserting a cross-link with PP SP 1.2 for

the classification of work products (by

attribute) to be sized.

 Modify the current WP into: ‘results of

requirement elicitation activities by entity

and attribute’ (see previous comment)

SP 1.2 Transform

Stakeholders needs

 Rephrase and make more general sub-

practice #2: not only functional vs. quality

(non-functional) attributes, but possibly

establish all valuable, possible

requirements taxonomies and

classifications for the organization (by

other criteria)

SG 2 Develop

Product

Requirements

 Introduce a note within the SG text about

the need and relevance of define a

(standard) document structure (in terms of

‘documentability’) and suggest – as

informative note – some possible criteria

to follow and appraise (e.g. readability,

simple and concise language for writing

requirements, etc.).

SP 2.1 Establish

Product and Product

components

 Sub-practice #3: refine the Example box,

do no mention generic quality attributes,

but be more specific about requirement

classifications (e..g ISO/IEC 14143-

1:1998  functional, quality, technical)

 cross-link with PP 1.2 about attributes

for sizing.

SP 2.2 Allocate

Product Components

 ---

SP 2.3 Identify

Interface

Requirements

 ---

SG 3 Analyze and

Validate

Requirements

 ---

SP 3.1 Establish

Operational Concepts

and Scenarios

 ---

SP 3.2 Establish a

Definition of Required

…

 ---

SP 3.3 Analyze

Requirements

 ---

SP 3.4 Analyze

Requirements to

Achieve Balance

 Introduce an informative note about the

possible usage of QFD matrices also here,

not only for eliciting and determining

requirements in SP 2.1

SP 3.5 Validate

Requirements

 ---

Table 3: CMMI-DEV RD: suggestions for improvements

(cont.).

GP 2.3 Provide

Resources

 General: stress the need and opportunity

from workflow environments for an easier

sharing of information among

stakeholders, whatever the (CMMI)

process

 Specific (RD Elaboration): specific need

because RD is the starting process for

gathering needs to be translated into

solutions

GP 2.5 Train

People

 General: introduce the application of the

six Bloom’s cognitive levels (Bloom et al.,

1956) for classifying knowledge (see also

IEEE SWEBOK –

www.computer.org/swebok)

 Specific (RD Elaboration): add

‘stakeholder engagement’

(AccountAbility, 2011) and ‘requirement

sizing’ (ISO, 2011)

GP 2.8 Monitor

and Control the

Process

 Specific (RD Elaboration): introduce at

least one measure about the effectiveness

of RD SG1 goal (e.g. % of proposed vs

validated requirements)

shows how our suggestions were introduced in the

current RD process, describing a new possible

improved process that may be mapped against

your own QMS internal process(es) covering that

subject.

4. Adapt & Adopt the selected element(s): after

adapting the original RD process, as shown in the

previous table, it should be mapped against the

related QMS internal process covering that

subject. Since many organizations adopt an ISO

management system (e.g. ISO 9001:2008), a

cross-check for validating potential improvements

from the design phase could be achieved through

re-applying the related mapping document to their

own internal process (e.g. using the N/P/L/F –

Not/Partially/Largely/Fully achieved ordinal scale

from CMMI or SPICE). In our case, moving from

CMMI-DEV, it could use Mutafeljia &

Stromberg’s mapping document (Mutafelija, 2008)

as a basis. In this paper, our focus was limited to

only the design phase. However, a case study with

the application of the hybrid-RD process will be

included in a future paper.

4 CONCLUSIONS & NEXT STEPS

Requirements are the first step for a project and if

they are not clearly and unambiguously defined this

can increase the probability that project estimates

will be incorrect because the project/activity scope

has not been clearly documented. Even, if there are

many existing requirements management models

and frameworks , each model represents only one

possible view of the inner reality that would be

Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for

Improving Estimates

captured and reused: the ‘one size doesn’t fit all’

motto could be rephrased as ‘one model doesn’t fit

all’. Thus, at least 2 (or more) models/frameworks

should be considered for improving your own

processes (whatever they are), in the areas/issues

needed.

In order to cope with this need, we recently

proposed LEGO (Living EnGineering prOcess) as

an open approach for improving the processes of a

business process model (BPM), based upon the

comparative analysis of the process architecture and

elements of several concurrent models within a

certain domain. Since estimation is one of the key

processes for determining the success of an

organization, we applied LEGO to Requirements

Engineering, with the aim to improving the CMMI-

DEV RD (Req. Development) process by integrating

it with other requirements engineering maturity

models. The final result was the design of a more

encompassing hybrid-RD process that could help

organizations to improve their estimates from the

beginning of the value chain.

In the future, we will apply this hybrid-RD

process to real case studies, proposing it as the meta-

model to be used for the performing the initial gap

analysis against the organizations’ BPM related

processes as part of an improvement initiative.

ACKNOWLEDGEMENTS

This work has been supported by the CNPq

(Conselho Nacional de Desenvolvimento Científico

e Tecnológico – www.cnpq.br), an entity of the

Brazilian government focused on scientific and

technological development.

This research is also supported in part by the

Science Foundation Ireland (SFI) Stokes Lectureship

Programme, grant number 07/SK/I1299, the SFI

Principal Investigator Programme, grant number

08/IN.1/I2030 (the funding of this project was

awarded by Science Foundation Ireland under a co-

funding initiative by the Irish Government and

European Regional Development Fund), and

supported in part by Lero (http://www.lero.ie) grant

10/CE/I1855.

REFERENCES

AccountAbility, AA1000 Stakeholder Engagement

Standard 2011, Final Exposure Draft, AA1000SES,

URL: http://goo.gl/VajaE

Ambler S., The Agile Maturity Model, Dr. Dobbs Journal,

2010/04/01, URL: http://goo.gl/nMNsH

Beecham S., Hall T., Rainer A., Defining a Requirement

Process Improvement Model, Software Quality

Journal, 13(3), 247–279, 2005

Beecham, S., Hall, T., and Rainer, A. Defining a

Requirements Process Improvement Model, Technical

Report 379, Hatfield, University of Hertfordshire,

February 2003, URL: http://goo.gl/6DvjY

Bloom, B. S., Engelhart, M. D., Furst, E. J., Hill, W. H., &

Krathwohl, D. R. (1956). Taxonomy of educational

objectives: the classification of educational goals;

Handbook I: Cognitive Domain New York,

Longmans, Green, 1956.

Boehm B., Software Engineering Economics, Englewood

Cliffs N.J., Prentice-Hall Inc., 1981, ISBN

0138221227

Buglione L., Ebert C., Estimation, Encyclopedia of

Software Engineering, Taylor & Francis Publisher,

April 2012, ISBN: 978-1-4200-5977-9

Buglione L., Gresse von Wangenheim C., Hauck J.C.R.,

McCaffery F., The LEGO Maturity & Capability

Model Approach, Proceedings of the 5th World

Congress on Software Quality

Chang S.J., When East and West Meet: An Essay of the

Importance of Cultural Understanding in Global

Business Practice and Education, Journal of

International Business and Cultural Studies, Vol.2,

February 2010, URL: http://goo.gl/OvkEw

CMMI Architecture Team, Introduction to the

Architecture of CMMI Framework, Technical Note,

CMU/SEI-2007-TN-009, July 2007, URL: http://

goo.gl/NCPUw

CMMI Product Team, CMMI-DEV (CMMI for

Development) v1.3, Technical Report, CMU/SEI-

2010-TR-033, Software Engineering Institute,

November 2010, URL: www.sei.cmu.edu/cmmi

Copeland L., The Maturity Maturity Model (M3).

Guidelines for Improving the Maturity Process,

StickyMinds, September 2003, URL: http://goo.gl/

PHovg

Gorschek T., Requirement Engineering Process Maturity

Model (Uni-REPM), version 0.9CR, Technical Report,

BTH, Sweden, January 2011, URL: http://goo.gl/

WBxos

Gorschek T., Tejle K., A Method for Assessing

Requirements Engineering Process Maturity in

Software Projects, Master Thesis in Computer

Science, BTH (Blekinge Tekniska Högskola),

Sweden, June 2002, URL: http://goo.gl/Tr5Dt

Hassan A. and Syuhada Jamaludin N., Approaches &

Values in Two Gigantic Educational Philosophies:

East and West, Online Educational Research Journal,

Vol.1, No.2, 2010, pp.1-15, URL: http://goo.gl/

XQO9u

Hepner Brodie C., Are you hearing your customers’

voices?, PRTM, 2006, URL: http://goo.gl/wTz67

Heumann J., The Five Levels of Requirement

Management Maturity, The Rationale Edge, 2003,

URL: http://goo.gl/a7Mvj

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

IAG Consulting, Requirement Maturity Attribute Table,

2009 URL: http://goo.gl/gMgxp

ISO IS 9001:2008, Quality management systems --

Requirements, International Organization for

Standardization, December 2008

ISO IS 9004:2009, Managing for the sustained success of

an organization- A quality management approach,

International Organization for Standardization,

October 2009

ISO/IEC IS 14143-x, Information Technology – Software

Measurement – Functional Size Measurement, Parts 1-

6, 2002-2011

ISO/IEC IS 15504-x, Information technology -- Process

assessment, Parts 1-7, International Organization for

Standardization, 2001-2007

Kollinger J., 7 Signs You Have a Bad Project Estimate

(and what to do about it), Presentation, 2010/01/20,

URL: http://goo.gl/fp435

Koomen, T. & Pol, M. Test Process Improvement: a

Practical Step-by-Step Guide to Structured Testing,

Addison-Wesley, ISBN 0-201-59624-5, 1999

Luo P., Analysis of Cultural Differences between West

and East in International Business Negotiation,

International Journal of Business and Management,

Vol.3, No.11, November 2008, pp. 103-106, URL:

http://goo.gl/HCzTA

McConnell S., 10 Deadly Sins of Software Estimation,

Presentation, 2002, URL: http://goo.gl/WjbGR

McConnell, Software Estimation: Demystifying the Black

Art, Microsoft Press, 2006, ISBN 978-0735605350

Mutafelija B., Stromberg H., Process Improvement with

CMMI v1.2 and ISO Standards, Auerbach, 2008,

ISBN 978-1420052831

OGC, P3M3: Portfolio,Programme & Project

Management Maturity Model, Version 1.0, February

2006, Office of Government Commerce, URL: http://

www.ogc.gov.uk/documents/p3m3.pdf

PMI, Organizational Project Management Maturity Model

(OPM3), Knowledge Foundation, Project

Management Institute, 2

ed., 2008

PMI, The Guide to the Project Management Body of

Knowledge, Project Management Institute, 4th Ed.,

2008, URL: www.pmi.org

Schauder J., 8 Reasons why Estimates are too low,

Schauderhaft website, 2010/01/17, URL: http://

goo.gl/F3T2f

Sehlhorst S., CMMI Levels and Requirements

Management Maturity Introduction, TynerBlain,

2007/01/25, URL: http://goo.gl/ARBLX

Solemon B., Sahibuddin S., Abd Ghani A.A., Re-defining

the Requirements Engineering Process Improvement

Model, Proceedings of the 16th Asia-Pacific Software

Engineering Conference (APSEC’09), Penang

(Malaysia) pp. 87-92, URL: http://goo.gl/ZpqZE

Sommerville I., Ransom J., An Empirical Study of

Industrial Requirements Engineering Process

Assessment and Improvement, ACM Transactions on

Software Engineering and Methodology, Vol. 14, No.

1, January 2005, Pages 85–117, URL: http://goo.gl/

xKIih

Standish Group, CHAOS Summary 2009. The 10 Laws of

CHAOS, URL: http://goo.gl/ONXi4

Stawicki J., Principles of connecting East and West

cultural differences in project management, XXII

IPMA World Congress, Rome (Italy), 2008, URL:

http://goo.gl/S8lTP

Stellman A., Greene J., Applied Software Project

Management, Chapter 3: Estimation, O’Reilly

Publishing, 2005, ISBN 978-0596009489

Swyngedouw, E., Neither global nor local: `glocalization’

and the politics of scale, in: K.Cox (Ed.) Spaces of

Globalization, New York: Guilford Press, 1997, pp.

137-166, URL: http://goo.gl/Lker1

Van Veenendaal, Test Maturity Model Integration

(TMMi) version 3.1, TMMi Foundation, 2010, URL:

www.tmmifoundation.org

APPENDIX - LIST OF ACRONYMS

BPM

Business Process Model

Capability Level

CMMI

Capability Maturity Model Integration

CMMI-

DEV

CMMI for Development

ENG.1

Requirement Elicitation

ENG.4

Sw Requirement Analysis

IEC

Int. Electrotechnical Commission

ISO

Int. Organization for Standardization

LEGO

Living EnGineering prOcess

MAN.3

Quality Management process

MCM

Maturity & Capability Model

Maturity Level

Maturity Model

NFR

Non-Functional Requirement

OPM3

Organizational Project Management

Maturity Model

P3M3

Portfolio, Programme, and Project

Management Maturity Model

PAM

Process Assessment Model

PMBOK

Project Management Body of Knowledge

PMI

Project Management Institute

Project Planning

PRM

Process Reference Model

QMS

Quality Management System

RCA

Root-Cause Analysis

Requirement Development

Requirement Engineering

REAIMS

Requirements Engineering adaptation and

improvement for safety and dependability

REPM

Requirements Engineering Process Model

Requirement Management

SEI

Software Engineering Institute

SPICE

Software Process Improvement Capability

dEtermination (ISO/IEC 15504)

TMMi

Test Maturity Model Integration

TPI

Test Process Improvement

Hybriding CMMI and Requirement Engineering Maturity & Capability Models - Applying the LEGO Approach for

Improving Estimates