Transcript Requirements Engineering and Management INFO 627 Building the Right System Glenn Booker INFO 627 Lecture #8

Requirements Engineering
and Management
INFO 627
Building the Right System
Glenn Booker
INFO 627
Lecture #8
1
Overview


So far we’ve been able to define equirements,
specify them clearly, and ensure they have
good quality
Now we need to ensure that the system we
create really does implement the requirements
we’ve defined
INFO 627
Lecture #8
2
Key Implementation Concepts



Need to confirm that the stated requirements
really are being implemented (verification)
Need to make sure development keeps
conforming to customer needs (validation)
Deal with change during development
INFO 627
Lecture #8
3
Verification versus Validation
Verification
Defined
Requirements
INFO 627
Validation
System
Lecture #8
Customer
Needs
4
Verification Should Prove





INFO 627
Use cases and requirements which are derived
from features really do support the intended
features
Use cases are reflected in the design
The design supports both functional and
nonfunctional aspects of the system’s behavior
Code conforms to the design
Testing covers all use cases and requirements
Lecture #8
5
Verification



Verification is often done through traceability,
which we’ll discuss shortly
Key concept for verification is that every
activity looks back to the previous step
and makes sure nothing got left behind,
or forgotten
Other verification methods include inspection
and review
INFO 627
Lecture #8
6
Verification Cost



We need to balance the amount of time spent
doing verification, so we don’t overdo it, or
miss something important
Will show next week how to use risk to guide
the right level of verification
Verification applies to all phases of the
life cycle, but is most critical early on
INFO 627
Lecture #8
7
Verification



Testing is also mostly a verification activity
Verification is done by many members of the
project team – it isn’t just a QA job
A process for verification needs to built
into the life cycle to ensure it is
consistently performed
INFO 627
Lecture #8
8
Validation



Validation is the act of proving that the system
you are creating meets the needs
of the customer (sponsor, users, etc.)
Can map user needs to product features,
another form of traceability
Validation is often done at major milestones

INFO 627
End of life cycle phases, end of iterations, etc.
Lecture #8
9
Validation


Need to demonstrate the product in the
customer’s environment to assess the
subjective “are they happy with it” criterion
Main reason for validation is to ensure the
customer needs didn’t drift from when the
requirements were captured
INFO 627
Lecture #8
10
Managing Change


Finally, we’ll discuss how to manage changes
to requirements during development – since
we can guarantee they will change
This will also be covered next week
INFO 627
Lecture #8
11
Implementing Requirements


While software development has been able to
accomplish many spiffy things, getting from
requirements to implementation is not a
simple matter
Sometimes it is hard to prove that a particular
piece of code fulfills a requirement
INFO 627
Lecture #8
12
Implementing Requirements


Implementing requirements is sometimes
straightforward
Easily implemented requirements often
written with detail to guide the developer,
and may invoke familiar concepts



INFO 627
Task progress status
Role or organization-based security modeling
Citing specific math concepts or algorithms
Lecture #8
13
Tough Requirements

The toughest requirements to implement are


INFO 627
Too vague, so there’s little idea what level of
complexity or control is desired, e.g. “allow
editing based on security defined by the
system administrator”
Non-functional requirements, which are
often process-oriented, but the code itself
is a logical structure
Lecture #8
14
Tough Requirements


Text calls the argument between process and
logic ‘orthogonality’ (which normally refers
to right angles)
Tough requirements can be like left-brain
versus right-brain thinking


INFO 627
Artistic & creative thought vs. logical & linear
How do you give driving directions?
Lecture #8
15
Tough Requirements

Tough requirements can also focus on scale
issues such as system-level requirements


Can be addressed by the systems engineering
approach we discussed earlier
Requirements which are distributed
throughout the system are also often difficult
(e.g. use of interface standards)
INFO 627
Lecture #8
16
Tools for Tough Requirements

Key ways to address tough requirements
are through using proven design patterns
or metaphors



INFO 627
Bringing Design to Software, by Terry Winograd
et al, ISBN 0201854910
Design Patterns, Erich Gamma et al,
ISBN 0201633612
And WWISA recommendations
Lecture #8
17
OO Helps Too


Use of object-oriented methods can help
resolve some orthogonality issues, by
combining data structure with processoriented methods
Beware that direct mapping of functions to
objects can result in non-OO structures
INFO 627
Lecture #8
18
Use Cases


Defining use cases can help see the big
picture of the system’s role, and keep from
focusing too closely on a particular function
So while the orthogonality problem won’t go
away, these approaches can help overcome it
INFO 627
Lecture #8
19
System Modeling



Software systems can involve thousands of
modules and millions of lines of code
To help break down their complexity we need
a good modeling tool
We need to hide the details and understand the
high level
INFO 627
Lecture #8
20
Modeling Analogies

Our need to understand software at a high
level is similar to other fields’ needs



In astronomy, cosmology tries to understand the
structure and evolution of the universe
In physics, various unified field theories try to
relate all of the electromagnetic forces
In comparison, our job is easy!
INFO 627
Lecture #8
21
System Modeling

We use system architecture to understand




What the system does
How it works
The role of each part of the system
And be able to support


INFO 627
Extension or expansion of the system
Reuse of the system
Lecture #8
22
The 4+1 View of Architecture


The 4+1 architecture view by Phillipe
Kruchten can help capture the architecture by
looking at different aspects of the system
Like a house architect might have different
drawings to capture the structure, wiring,
plumbing, external appearance, etc.
Keep in mind that the Kruchten paper was written before UML.
INFO 627
Lecture #8
23
The 4+1 View

The 4+1 views are




INFO 627
Logical view, such as the subsystems and classes
within the system
Implementation or development view, which is
the structure of the code in its environment
Process view, to capture timing and coordination
issues
Deployment or physical view, the hardware
Lecture #8
24
The 4+1 View

The +1 part are scenarios or use cases, which
tie all of the parts together
Logical
Implementation
Use Cases
Process
INFO 627
Deployment
Lecture #8
25
Logical View


The logical view is the structure of the
data and objects needed to support
system functionality
Appears as a class diagram or
entity-relationship diagram (ERD)
See my UML summary for more information on the diagrams.
INFO 627
Lecture #8
26
Implementation View



The structure of the code is often shown by
grouping modules into bigger pieces, or
different layers (think OSI reference model)
From small to large, typical names are
package, component, and subsystem
Hence it is no surprise that package,
component, and subsystem diagrams
may show this view
INFO 627
Lecture #8
27
Process View



The process view mostly helps understand
non-functional characteristics, based on the
process flows
Timing, synchronization, concurrency, and
fault tolerance are all addressed by the
process view
Sequence, collaboration, statechart, and/or
activity diagrams may show this view
INFO 627
Lecture #8
28
Deployment View



The deployment view focuses on how
the system is physically located on
computer systems
Hence this helps focus on installation
and networking issues
Shown with a deployment diagram
INFO 627
Lecture #8
29
Use Cases Tie It All Together



As the four main views are being developed,
the use cases or scenarios can help ensure the
models are all consistent with each other
Trace how each scenario appears from each
view’s perspective
This approach is also used by the Rational
Unified Process
INFO 627
Lecture #8
30
Collaborations



Collaborations are conceptual classes which
allow a direct link between a use case and the
classes which implement it (p. 328)
A collaboration may appear in a class
diagram, but does not reflect an actual class,
it represents a set of classes and behaviors
See the UML specification for more info
INFO 627
Lecture #8
31
Modeling Summary

Hence the best way to get from requirements
to code is to define a set of inter-related
models of the system, capturing its logical,
implementation, process, and deployment
characteristics, while ensuring that the use
cases can be fulfilled using those models
INFO 627
Lecture #8
32
Traceability



Traceability is a key technique for verification
of requirements
Tracing can be done from the features
in the Vision document, all the way
down to testing
Tracing can’t be automated, but tools
can help make it easier
INFO 627
Lecture #8
33
Traceability



Need to establish traceability so that when
requirements change, we can tell what was
affected by the change
Traceability shows the connection between
two things, and hence can show why
something exists in the system
One-to-many connects are common

INFO 627
One feature may trace to many requirements
Lecture #8
34
Traceability

In defining traceability, we could identify
where something traces to, or from

“From” is easier to keep track of in most cases,
e.g. “Feature B traced from Need A”; why?
Need A
Feature B
Req’t C
INFO 627
Lecture #8
35
Explicit vs. Implicit Traces


An explicit trace between two things means
that the connection is not obvious, and must
have been determined by the project team
An implicit trace is implied, such as
parent-child connections


INFO 627
Feature X traces to requirements X.1, X.2,
and X.3
Don’t need to state implicit traces
Lecture #8
36
Other Things to Trace

Might want to include other ideas in
connection with tracing requirements






Assumptions and rationale for decisions
Action items or TBD lists
Requested new features
Glossary and terminology
Bibliographic or other references
Just don’t go overboard!
INFO 627
Lecture #8
37
Traceability Tools

Major CASE tools can often help trace
relationships


Rational (IBM), Aonix, and others
They can’t tell what the relationships are, but
can help maintain the connections and make it
easier to document them
INFO 627
Lecture #8
38
What Can Be Traced?
Needs
Features
Requirements
Use Cases
Design Models
Actors
Code
Test Cases
Releases
(not a complete list!)
INFO 627
Lecture #8
39
How To Show Traceability

Any kind of traceability can be shown
using a table or matrix



Columns representing a low level thing (e.g.
requirements or use cases)
Rows represent a high level thing (e.g. features)
The presence of an “X” or check mark means
that the column (requirement) helps fulfill
whatever is in that row (feature)
INFO 627
Lecture #8
40
Verification Using Traceability

Every column should have at least one “X”


Every row should have at least one “X”


That requirement doesn’t correspond to a known
feature (excess verification); maybe
a superfluous requirement?
That feature never got mapped to a requirement
(omitted verification); oops!
Many “X”s is usually acceptable
INFO 627
Lecture #8
41
Maintaining Traceability



Traceability can be shown several ways,
such as the tree and list formats
Automated tools are very helpful in
generating these views easily
If an automated tool isn’t available, a
relational database may be needed for
projects of any significant size
INFO 627
Lecture #8
42
Correct and Complete




Just checking for “X”s in each row and
column isn’t enough
That won’t prove whether each connection is
correct and complete
Some sort of review is often needed to obtain
agreement on those issues
Reconsider links when project scope or
environment changes
INFO 627
Lecture #8
43