Lecture 13

Failure mode: when team understands requirements but is unable to meet them.

To ensure that you are building the right systemContinually confirm that development is on trackConfirm that the development results are correctLearn how to deal with change during

development

Continually confirm that development is on track

Verification“The process of evaluating a system or component

to determine whether the products of a given phase satisfy the conditions imposed at the start of that phase”

Thus we make a verification plan (to ensure that we have done the things we need to do)Tools to help execute this plan

○ Traceability○ Process models○ Analysis

Inspection reviews

Confirm that the development results are correct

To check that the functionality that is developed works correctly and conforms to requirements.

Validating has two important aspectsShow that product conforms to requirementsTo focus on customer acceptance of the

final result.

Learn how to deal with change during development

Proper change managementproper impact analysis

○ Traceability informationIncorporate changes in a timely manner

From Requirements to Implementation Proving that requirement is fulfilled in

design and code is a non trivial effort. For some requirements this can be

easily tested e.g. “support up to an eight digit floating point input parameter”

Orthogonality ProblemFor requirements like “the system shall allow

editing based on the security set up by the system administrator”

No one to one mapping.

Orthogonality ProblemWhy

○ Requirements speak real world items, code speaks of stacks queues and algorithms.

○ Some requirements like performance requirements they have little to do with logical structures but more to do with process structures (how code pieces interact)

○ Implementation of requirement is distributed through code so have to look at whole rather than part.

○ Good design not due to does system map to requirements

Solution

Object OrientationModeling with help of real time

entities(objects)

Use Cases(user/system interaction in terms of

scenarios)

Managing the Transition

Making ModelsUnderstanding versus oversimplification

Architecture of System (Shaw and Garlan)Description of elements from which systems

are built, interaction amongst those elements, patterns that guide their composition and constraints on those patterns”

Architecture

Helps toUnderstand what the system doesUnderstand how system worksBe able to think and work on pieces of the

systemExtend the systemReuse parts of the system to build another

one.

4+1 Views of Architecture Different views for different people Philippe Kruchten

4 Views The logical view addresses the functionality of the system. This abstraction of

the design model represents the logical structure of the system in terms of subsystems and classes, which in turn are the entities that deliver the functionality to the user.

The implementation view describes the bits and pieces that are relevant to the implementation of the system: source code, libraries, object classes, and so on. This view represents the static view of these pieces, not how they interact.

Process views, generally more useful to describe operations of the system, are extremely important for systems that have parallel tasks, interfaces with other systems, and other interactions that occur during execution. Since many modern systems exhibit high degrees of parallelism and multithreading, this view allows the reviewer to determine potential problems, such as race conditions or deadlocks. You should also use the process view to examine throughput issues and other performance issues that the user specified in the nonfunctional requirements.

Because the project modules rarely exist in a vacuum, the deployment view allocates the implementation elements to the supporting infrastructure, such as operating systems and computing platforms. This view is not especially concerned with what the interactions are but rather with the fact that there are interactions and constraints where the two systems meet.

Use Case Realization Use case realization is used to achieve

requirements to design transition. Use cases are realized via collaboration

Collaboration are societies classes, interfaces, subsystems or other elements that cooperate to achieve some behavior.

Symbol of collaboration an ellipse with the name inside it.

Collaboration has a ○ Structural part (class diagram)○ Behavioral part (interaction diagram)

Role of Traceability in Requirement Verification Vertical Versus Horizontal Traceability

One to one, many to many, many to one relationship

Implicit versus explicit traceability

Validation

“The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements”

Acceptance TestsAlpha versus beta tests

TestingYour development process must plan testing

activitiesYour development process must also provide

time and resources to design the testsYour development must also provide time and

resources to execute the test.

Maintain an Audit/Trail

Validation Traceability

Do we have enough tests to cover everything that needs to be tested?

Do we have any extra tests that serve no useful purpose

Requirement Based Testing To test system against requirements

Unit testsIntegration tests

Table 32-1 page number 352

Managing Change Why Do requirements Change

External Factors○ There was change to the problem○ The user changed their mind○ The external environment changed○ The new system comes into existence

Internal Factors○ We failed to ask the right people the right

questions at the right time.○ We failed to create a practical process to

manage change

We have met the enemy and They is Us Official change Unofficial change

Enhancements mentioned by distributorsDirect customer requests to programmersMistakes that have been made and shipped and

had to be supportedHardware features that didn’t workKnee jerk change of scope reactions to

competitorsFunctionality inserted by developer, thinking

what is best for customerProgrammers “Easter eggs”

Process for Managing Change Process

Recognize that change is inevitable and plan for it.

Baseline the requirementsEstablish a single channel to control changeUse a change control system to capture

changesManage Change hierarchically

Requirement Configuration Management

THE END

ANY QUESTIONS?

THANK YOU