Requirements Engineering and Management INFO 627

Requirements Engineeringand ManagementINFO 627 Building the Right System Glenn Booker Lecture #8

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 Lecture #8

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 Lecture #8

Verification Validation Defined Requirements System Customer Needs Verification versus Validation Lecture #8

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 Lecture #8

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 Lecture #8

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

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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? Lecture #8

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) Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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! Lecture #8

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 Lecture #8

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. Lecture #8

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 Lecture #8

Logical Implementation Use Cases Process Deployment The 4+1 View • The +1 part are scenarios or use cases, which tie all of the parts together Lecture #8

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. Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

Need A Feature B Req’t C 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? Lecture #8

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 Lecture #8

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! Lecture #8

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 Lecture #8

Needs Features Requirements Use Cases Design Models Actors Code Test Cases Releases (not a complete list!) What Can Be Traced? Lecture #8

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) Lecture #8

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 Lecture #8

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 Lecture #8

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 Lecture #8

Requirements Engineering and Management INFO 627