RVV

Requirements

Verification

Validation

Requirements

References:

• http://en.wikipedia.org/wiki/Requirement with sub-links

Requirements-types

• Business requirements describe in business terms what must be delivered or accomplished to provide value. (not an issue here)

• Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)

• Process requirements describe activities performed by the developing organization. For instance, process requirements could specify specific methodologies that must be followed, and constraints that the organization must obey. (not an issue here)

Product Requirements-categories

• Architectural requirements describe what must be done by identifying the necessary system architecture of a system.

• Functional requirements describe the functionality that the system is to execute. They are sometimes known as capabilities. ->

• Non-functional requirements describe characteristics of the system that the user cannot affect or (immediately) perceive. Nonfunctional requirements are sometimes known as quality requirements or usability requirements. ->

Architectural requirements

• Extracted from the project description – some times called the system definition –or other preliminary documents

• Captured in UML deployment diagram, which is a ‘design thing’. – UML nodes, components, communication etc.

• Parts – Hardware architecture refers to the identification of a system's

physical components and their interrelationships • UML nodes

– “Software architecture of a program or computing system is the structure or structures of the system, which comprise

• software components • the externally visible properties of those components, and • the relationships among them.” /Bass, Clements and Kazman, 1997 • UML components

Functional requirements

• Also Extracted from the project description – some times called the system definition –or other preliminary documents

• Captured in UML use case diagrams after gathering and validating a set of functional requirements. – Each use case illustrates specific behavioral scenarios

through one or more functional requirements. – Validated based on prototypes – Documented in UML activity diagrams and/or text – Test vectors are generated to be used in VV

Non-functional requirements

• Qualities of a system

• Specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. – Typically defined in design criteria

– Functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.

Non-functional requirements-categories

1. Execution qualities • such as security, usability, which are observable at run

time.

2. Evolution qualities • such as testability, maintainability, extensibility and

scalability, which are embodied in the static structure of the software system.

Verification & Validation

Verification: • "Are we building the product right”. • The software should conform to its specification. • Goal: Product quality Validation: • "Are we building the right product”. • The software should do what the user really • requires. • Goal: User satisfaction

Verification & Validation

Verification of Requirements

Verification Are we building the product right?

References: http://en.wikipedia.org/wiki/Software_verification

Verification Static verification (dynamic

verification later) • Peer review is preferred strategy • Checking that software meets requirements by doing a

physical inspection like: – Formal code verification

• Carefully walk through the code • Tool: example

– Code conventions • Coding templates • Naming convention • Documentation style • Conform to component architecture • Conform to system architecture requirements

– Well defined boundaries (java interfaces) UML Example

– Best practices detection • anti-pattern .. spaghetti code • Don’t conform to agreed patterns.

– Example: Component with public visibilities not included in any java interfaces

PMD • PMD - Programming Mistake Detector. (not Pakistan Meteorological Department !)

• Java source code analyzer that identifies potential problems. • PMD comes with rules to find potential problems such as:

– Unused local variables. Build-in Eclipse – Empty catch blocks – Unused parameters – Empty 'if' statements – Duplicate import statements – Unused private methods Build-in Eclipse – You can also add new rules to PMD.

• Typically, PMD errors are not true errors, but rather inefficient code, i.e. the application could still function properly even if they were not corrected.

• Tool: http://pmd.sourceforge.net/

• Ref: http://en.wikipedia.org/wiki/PMD_(software)

Verification Dynamic verification – using ‘button up’ test • Test in the small: a test that checks a single function or class (Unit

test) – main() operation in the class

• Test in the large: a test that checks a group of classes, such as – Module test (a single module)

• Internal test: Component white box test • External test- using component interface/Façade/Adapter/... eventually via a

jar version – Integration test (more than one module)

• Ex. a single node in the deployment diagram – System test (the entire system)

• Each Use case using test vectors. • Example ATM activity diagram in session 7. Java

• Acceptance test: a formal test defined to check acceptance criteria for a software – Continue after validation->

Validation Are we building the right product?

References:

• http://www.bizmanualz.com/blog/whats-the-difference-between-verification-and-validation.html

• http://softwaretestingfundamentals.com/acceptance-testing/

Validation test

• Ensures that any functional requirement has been met observed from user side

• It’s the system working functional correctly ? – Typically we stress the user interface to evaluate

all possible cases for usage • Hard work having prompted user interface !

• Using one or more mice?

• Using touch screen?

• ...

Acceptance Testing • A level of the software testing process where a system is tested

for acceptability.

or

• The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.

• Acceptance Testing = Validation and Non-functional test)(performance, stress test)

• Black box testing.

End

Flow verification

• visustin.exe

• demo

private void compare() {

if(readAirTemperature()>readThresholdTemperature())

openWindow();

if(readAirTemperature()<(readThresholdTemperature()-2))

closeWindow();

}

UML Example Deployment diagram

Class diagram