Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1

8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1

1/7

ISTOCKP

HOTO

90 BETTER SOFTWARE JANUARY/FEBRUARY 2009 www.StickyMinds.com


2/7


3/7

when we talk about the completeness o

the individual requirements, the meaning

o the term complete may vary de-

pending on whether a requirement is

qualifed as a core eature or a crosscut-

ting concern. In particular, a given core

eature specifcation is not complete

without analyzing and capturing details

about how other scattered eatures areinvoked and are aecting the core ea-

ture context. Correspondingly, a cross-

cutting concern specifcation is not com-

plete without analyzing and speciying

where it can be invoked and how it can

aect related core eatures. These details

are requently missing in requirements

specifcations; and this kind o omission

becomes a signifcant source o sotware

deects, where up to 75 percent o deects

can be allocated to crosscutting concerns

whose impact has not been analyzed and

documented.

Issues with RequirementsMaintainability

Requirements maintenance means

that requirements artiacts produced in

previous releases are updated or use in

uture releases. There are two main rea-

sons or doing this:

Effective impact analysis of

change requestsEach new re-

lease o a production application

starts with selecting change re-

quests (aka enhancements) to be

implemented and analyzing their

impact on the existing unction-

ality. In turn, the results o impact

analysis provide a basis or eort

estimation and release planning.

Commonly or business applica-

tions, most change requestsrom 60 percent to 85 percent on

averagerelate to the existing

unctionality. Hence, to make the

impact analysis o change requests

eective, we need to have a com-

plete and structured inventory o

requirements accurately reecting

the current unctionality.

Lower cost of requirements de-

velopmentTo speciy sotware

requirements or a new release, it

is much cheaper to maintain the

existing documents than to create

new ones when changes relate to

the existing unctionality. In addi-

tion, i requirements are well struc-

turede.g., each concern is encap-

sulated to remove redundancythe

cost o requirements maintenance

can be urther reduced.

However, in practice, project teams

requently do not maintain their specif-

cations o sotware requirements devel-

oped in prior releases. Instead, they keep

developing new specifcations or each

new release. This presents one more

issue in addition to the higher cost o de-

veloping requirements. In this case, even

i we combine all requirements specif-

cations rom all prior releases, still they

cannot represent a complete view o theapplication unctionality as requirements

in later releases can overwrite require-

ments in the previous releases. Moreover,

in this case we do not even know which

requirements rom previous releases are

still valid and which are not.

When I analyzed the experience o

such projects, I ound that the main

reason why sotware requirements are

not maintained is the difculty in per-

orming impact analysis o change re-

quests. This stems rom two actors:

Lackofrequirementsstructure

e.g., the majority o such projects

did not even defne a high-level

unctional decomposition to

structure their requirements

Incomplete view of the existing

unctionality when requirements

in later releases overlap and over-

ride requirements in prior re-

leases

Thus, a good structure and modu-

larization o requirements is critical ortheir maintainability and lower cost o

development. Correspondingly, the act

that impact analysis o change requests

is not perormed and existing require-

ments are not maintained is a common

symptom o poorly structured and in-

complete requirements.

The need to improve requirements

completeness, structure, and maintain-

ability was recognized in the sotware

industry long ago, and all existing meth-

odologies provided techniques to resolve

these issues with various degrees o suc-

cess. In the ollowing section we will dis-

cuss the major methodologies rom this

point o view.

Overview of the MajorMethodologies

Over the past thirty to orty years,

a number o sotware methodologies

emerged that addressed techniques to

develop sotware requirements. Among


Figure 2: Tangling rate of core features


4/7

them the ollowing our methodologies

represent the most undamental schools:

Structured analysis and design

(SAD)

Object-oriented analysis and de-

sign (OOAD)

Agilesoftwaredevelopment(ASD)

Aspect-orientedsoftwaredevelop-

ment (AOSD)

Even though these methodologies

provide dierent techniques rom the

requirements perspective, all o them

ollow the same conventional require-ments process, defned as three phases

requirements elicitation, requirements

analysis, and requirements specifca-

tionas shown in fgure 3. Another in-

teresting point about these methodolo-

gies is that only SAD and OOAD are

truly mutually exclusive. In contrast,

the agile methodology oers a light

way to develop requirements regardless

o whether you ollow SAD or OOAD.

Likewise, the aspect-oriented method-

ology is not a replacement or any o the

other methodologies. It oers specifc

techniques to analyze and speciy re-

quirements that can complement any o

the existing methodologies, including the

agile methodology. Below I discuss these

methodologies in more detail.

structuredanalysIsanddesIgn

The SAD methodology emerged in

the 1970s and introduced unctional

decomposition and data-ow-analysis

techniques to model requirements. These

techniques enabled us to better structure

requirements according to unctional

areas, which have in turn improved re-

quirements analysis and maintainability.

On the other hand, while improving

the requirements structure, the SAD tech-

niques were not eective in dealing with

redundancy in requirements, such as

when the same requirements are present

in dierent unctional areas or when di-

erent requirements have common parts,

etc. As a result, requirements models

developed based on the SAD techniques

were prone to redundancy that nega-tively aected their cost o development

and maintenance.

object-orIentedanalysIsanddesIgn

The OOAD methodology emerged in

the late 1980s and was widely adopted

by the mid 1990s. It introduced use cases

and the Unifed Modeling Language

(UML) to model requirements. UML

defned specifc relationships among use

casesor example, the include and ex-

tendrelationships. As a result, we could

encapsulate and remove parts o the ap-

plication behavior common to dierent

use cases and then present these parts as

separate use cases having include or ex-

tend relationships with their respective

base use cases. Thus, use case modeling

can help us better structure require-

ments, in particular remove redundancy

that resolves the main limitation o the

SAD methodology.

However, conventional use case mod-

eling still has a signifcant shortcoming.

www.StickyMinds.com JANUARY/FEBRUARY 2009 BETTER SOFTWARE 93

Figure 3: AORE vs. other methodologies

In particular, use cases do not provide

a complete view o the applications

unctionality when supplementary re-

quirements are scattered across the ap-

plication and tangled with the context

o many use cases. Moreover, i a ew

supplementary requirements aect the

same step in a use case scenario, they canconict with each other. In this situation,

use case specifcations are not complete

without analyzing and capturing the

impact o scattered requirements. Thus,

the main limitation o use case modeling

was that it did not provide techniques to

analyze that impact and speciy it in use

case scenarios.

agIlesoftwaredevelopment

The ideas o ASD emerged at the end

o the 1990s and rapidly gained popu-

larity in the sotware industry ater its

concepts were defned in the Agile Mani-

esto in 2001. ASD introduced a light

way to model requirements in the orm

o user stories, which are intended to

capture customer needs and are used to

plan releases and estimate eort. How-

ever, while developing user stories in a

light way, we still cannot avoid the issue

o requirements scattering and tangling.

This means that scattered eatures can

impact user stories, and without an un-

derstanding o this impact we cannotsee the whole story. Thus, rom the re-

quirements process point o view ASD

inherits the limitations o the SAD and

OOSD methodologies. In particular, it

lacks techniques to deal eectively with

requirements scattering and tangling to

produce a complete view o the applica-

tion behavior in the context o user sto-

ries.

aspect-orIentedsoftware

development

Finally, in the early 2000s, the AORE

methodology emerged that, in contrast

with the other methodologies, specif-

cally addressed the issue o requirements

scattering and tangling and provided

techniques to improve requirements com-

pleteness and maintainability. AORE is a

part o the aspect-oriented sotware de-

velopment discipline, where the old sot-

ware engineering principle separation

o concerns (SoC) [1] is used to improve

modularization o requirements and


5/7

source code. In brie, by ollowing the

SoC principle, we break a problem do-

main into specifc aspects and then study

each aspect in isolation or the sake o

its own consistency. In the case o sot-

ware requirements, we decompose an

applications unctionality and separate

requirements into two categories: coreeatures and crosscutting concerns. Core

eatures can be structured by application

modules and crosscutting concerns can

be structured by their specialized types,

thereby improving requirements modu-

larization. We then analyze and docu-

ment the impact o crosscutting concerns

on the context o core eatures by using

defned composition rules to improve

completeness o requirements specifca-

tions. Thus, AORE does not replace any

o the existing methodologies but rather

complements them with improved re-

quirements analysis and specifcation

techniques. As a result, we can produce

better-structured requirements and more

complete specifcations that are easier to

analyze and cheaper to maintain.

AORE Analysis TechniquesRegardless o which methodology

we ollow, it is important in the analysis

phase to defne the application decom-

position and identiy the inventory o

concerns that lay ground or modular-ization and structure o a uture require-

ments model. We can identiy core ea-

tures, or example, by ollowing SAD

and perorming top-down unctional

decomposition or by ollowing OOAD

and decomposing unctionality into use

case packages and use cases. In either

case, the application unctionality is par-

titioned along just one dimensioni.e.,

core eatures. By contrast, in AORE we

perorm two-dimensional decomposition

and separate concerns by core eatures

and crosscutting concerns (as shown in

fgure 4) thereby improving the overall

modularization o our requirements

model. In addition to two-dimensional

decomposition, some researchers in the

AORE feld study the concept o multi-

dimensional separation o concerns

(MDSoC). Because o limited space, dis-

cussing MDSoC goes beyond the scope

o this article.

Crosscutting concerns are those ea-

tures that are scattered across the ap-


Table 1: List of common crosscutting concerns

Figure 4: Separation of concerns in requirements analysis


6/7


7/7


whole application can be decomposed

into a ew modules including 01. Front

Desk. Figure 6 shows the RCT created

or this module.

Columns in this table represent the

inventory o core eatures that can be

documented lateror example, as user

stories structured by application mod-

ules or as use cases structured by use

case packages. Each core eature identi-

fes a particular business goal that the

end-user can accomplish and provides a

context to perorm the impact analysis.

Rows in the table represent a generic

list o concerns composed o core unc-

tionality, GUI eatures, and crosscuttingconcerns. Crosscutting concerns can be

documented later as supplementary re-

quirements structured by the types o

crosscutting concerns. In the simplifed

RCT example shown in fgure 6, we

have a list o seven crosscutting con-

cerns; however, or complex applica-

tions, such a list can commonly include

up to twenty crosscutting concerns.

By deault, each core eature con-

text has core unctionality. Also in this

module all core eatures have GUI; there-

ore, we enter 1 in all cells related to

these two concerns. Then we analyze

the impact o crosscutting concerns. We

take one core eature at a time and go

down the list o crosscutting concerns to

identiy which o them impact the core

context. Ater we have completed this

analysis, all the cells in the table are pop-

ulated with either 1 or 0, reecting

a complete inventory and composition

o concerns.

Thus, by separating core eatures

rom crosscutting concerns and then

identiying the impact o crosscutting

concerns on the core unctionality, we

resolve the issue with requirements scat-tering and tangling. We capture such

analysis results in an RCT that should

not be conused with a requirements

traceability matrix (RTM).

An RTMs purpose is twoold:

Toidentifyandmaintaintherela-

tionship between sotware require-

ments and their sources, which is

known as backward traceability

Toidentifyandmaintaintherela-

tionship between sotware require-

ments and other project artiacts

Composingarequirementsstructuremeansthatforeachcorefeature

context we indicate which crosscutting concerns impact this core feature

andbecomeapartofitscontext.

developed based on requirements,

which is known as orward trace-

ability

In contrast, the RCT is used to cap-

ture modularization and composition

o requirements, thereby providing a

holistic view o the application unction-

ality. Such a structured view can be used

as a rame o reerence to eectively sup-

port various tasks and can provide mul-tiple benefts discussed in the sidebar.

Thus, in this article I discuss that

requirements scattering and tangling e-

ects present challenges or producing

complete and maintainable require-

ments. AORE is a new methodology that

specifcally addresses these challenges.

Part 1 o this article gives an overview

o the AORE analysis techniques that

can help us develop a better-structured

requirements model and present it in the

orm o an RCT. An eective structure

o requirements is key to improving re-quirements maintainability and change

impact analysis. AORE can also help us

produce more complete requirements.

It provides specifcation techniques that

can help us better document the mutual

impact o requirements. Such techniques

I will discuss and illustrate with exam-

ples in Part 2.{end}

RefeRenceS:

[1] Dijkstra, Edsger W. A Discipline of Program-

ming. Englewood Clis, NJ. Prentice Hall, 1976.

Figure 6: RCT example for a hotel management system

For more on the following topics go towww.StickyMinds.com/bettersoftware.n More on AOREn Agile maniesto

StickyNotes

Documents

Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1