Requirements Engineering and Management INFO 627

INFO 627 Lecture #8 1

Requirements Engineeringand ManagementINFO 627

Building the Right System

Glenn Booker


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


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


Verification versus Validation

SystemCustomer

NeedsDefined

Requirements

Verification Validation


Verification Should Prove 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


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


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


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


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 End of life cycle phases, end of iterations, etc.


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


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


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


Implementing Requirements Implementing requirements is sometimes

straightforward Easily implemented requirements often

written with detail to guide the developer, and may invoke familiar concepts Task progress status Role or organization-based security modeling Citing specific math concepts or algorithms


Tough Requirements The toughest requirements to implement are

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


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 Artistic & creative thought vs. logical & linear How do you give driving directions?


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)


Tools for Tough Requirements Key ways to address tough requirements

are through using proven design patterns or metaphors Bringing Design to Software, by Terry Winograd

et al, ISBN 0201854910 Design Patterns, Erich Gamma et al,

ISBN 0201633612 And WWISA recommendations


OO Helps Too Use of object-oriented methods can help

resolve some orthogonality issues, by combining data structure with process-oriented methods

Beware that direct mapping of functions to objects can result in non-OO structures


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


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


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!


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 Extension or expansion of the system Reuse of the system


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.


The 4+1 View The 4+1 views are

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


The 4+1 View The +1 part are scenarios or use cases, which

tie all of the parts together

Logical

Process

Implementation

Deployment

Use Cases


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.


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


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


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


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


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


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


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


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 One feature may trace to many requirements


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


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 Feature X traces to requirements X.1, X.2,

and X.3 Don’t need to state implicit traces


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!


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


What Can Be Traced?

Needs Features Requirements

Use CasesDesign Models

Test CasesCode

Releases

Actors

(not a complete list!)


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)


Verification Using Traceability Every column should have at least one “X”

That requirement doesn’t correspond to a known feature (excess verification); maybe a superfluous requirement?

Every row should have at least one “X” That feature never got mapped to a requirement

(omitted verification); oops! Many “X”s is usually acceptable


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


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

Documents

Requirements Engineering and Management INFO 627