chernak - 2009 - building a foundation for structured requirements, part 1
TRANSCRIPT
-
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
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
2/7
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
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
92 BETTER SOFTWARE JANUARY/FEBRUARY 2009 www.StickyMinds.com
Figure 2: Tangling rate of core features
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
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
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
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-
94 BETTER SOFTWARE JANUARY/FEBRUARY 2009 www.StickyMinds.com
Table 1: List of common crosscutting concerns
Figure 4: Separation of concerns in requirements analysis
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
6/7
-
8/7/2019 Chernak - 2009 - Building a Foundation for Structured Requirements, Part 1
7/7
96 BETTER SOFTWARE JANUARY/FEBRUARY 2009 www.StickyMinds.com
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