info 627lecture #81 requirements engineering and management info 627 building the right system glenn...
Post on 29-Dec-2015
232 Views
Preview:
TRANSCRIPT
INFO 627 Lecture #8 1
Requirements Engineeringand ManagementINFO 627
Building the Right System
Glenn Booker
INFO 627 Lecture #8 2
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 3
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 4
Verification versus Validation
SystemCustomer
NeedsDefined
Requirements
Verification Validation
INFO 627 Lecture #8 5
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
INFO 627 Lecture #8 6
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 7
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 8
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 9
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.
INFO 627 Lecture #8 10
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 11
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 12
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 13
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
INFO 627 Lecture #8 14
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
INFO 627 Lecture #8 15
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?
INFO 627 Lecture #8 16
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 17
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
INFO 627 Lecture #8 18
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
INFO 627 Lecture #8 19
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 20
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 21
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 22
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
INFO 627 Lecture #8 23
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 24
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
INFO 627 Lecture #8 25
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
INFO 627 Lecture #8 26
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 27
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 28
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 29
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 30
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 31
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 32
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 33
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 34
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
INFO 627 Lecture #8 35
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 36
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
INFO 627 Lecture #8 37
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 38
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 39
What Can Be Traced?
Needs Features Requirements
Use CasesDesign Models
Test CasesCode
Releases
Actors
(not a complete list!)
INFO 627 Lecture #8 40
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 41
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
INFO 627 Lecture #8 42
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 43
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
top related