iwsm2014 cosmic masterclass part 2 - dealing with nfr (chris woodward)

IWSM 2014, Rotterdam

COSMIC MasterclassAlain Abran, ETS, Montreal, Canada

Jaroslaw Swierczek, 300D&C, Warsaw, PolandCharles Symons, UK

Chris Woodward, CW Associates, UK

The Common Software Measurement International Consortium

© COSMIC 2014

2

Agenda

09:00 Version 4.0 of the COSMIC Method

09:45 The COSMIC approach fordealing with Non-Functional Requirements (NFR)

10:20 (Break)

10:40 Automatic COSMIC sizing of requirements held in UML

11:15 Project estimating with COSMIC

12:00 Close2

Aims of this session

• Provide an overview of emerging COSMIC NFR Guideline

• Jointly identify/consider matters for further attention

3

Guideline on managing‘Non-Functional Requirements’ for software

• Purposes:

– to help understand and define NFRs in a more precise way and …

– to provide practical guidance (to COSMIC users) on how to deal with NFRs, as well as FUR, in project performance measurement and estimating

4

Constraints and Requirements

5

ConstraintsConstraints

RequirementsRequirements

e.g. staff numbers and experiencee.g. staff numbers and experience

e.g. use JAVA 2e.g. use JAVA 2

DEFINITION – Non-Functional Requirement (NFR)

Any or constraint on, including requirement for, a hardware/software system or software product, or a project to develop or maintain such a system or product, except a functional user requirement for software

6

EnvironmentEnvironment

The scope of NFRs

7

Project

System

Software product

Technology infrastructure

Other deliverables

“Measuring” NFRs

• Challenge in dealing with diversity of NFR

• Previous/other approaches:– IFPUG Value Adjustment Factor– MkII Technical Complexity Adjustment– IFPUG Software Non-functional Assessment

Process (SNAP points)

– All are “fabricated” and not focused on what is actually delivered

8

What do projects deliver?

• New and enhanced hardware/software systems, composed of:

• New and changed software product• New and changed technology infrastructure• Other deliverables

E.g. documentation, training

9

Our focus

• The “detailed” FUR implemented in the software product

– … measured in a uniform manner, in CFPs

10

Ready to Build

11

ConstraintsConstraints

Detailed FUR for software

Detailed FUR for software

True NFR’s for system

True NFR’s for system

System demographics (context)System demographics (context)

Project constraintsProject constraints

Ready to Build

12

NFRNFR

Detailed FUR for software

Detailed FUR for software

True NFR for system

True NFR for system

Evolution of requirements with project progress

13

Implemented System

Project

Require-ments

AnalysisDesign & Definition

Build, Test & Implement

(May apply to)

Approx-imate FUR

Archi-tecting

(May evolve to)

Software

Hardware

Other deliverables

OutlineFUR

Outline NFR

Detailed FUR

True NFR

An example: a ‘security’ NFR

• The application A will require its own user identification and password sign-on procedure. Only employees authorized by the System Administrator will be allowed access’

• Possible ‘detailed’ FUR:– Create, List, Display, Delete employee record

Create to generate an e-mail to send initial password to newly-authorized employee

– Send a new PW to an employee who has forgotten his/her password

– Force an employee to change PW every three months

14

Evolution of measurement with project progress

15

Implemented System

Project

Require-ments

AnalysisDesign & Definition

Build, Test & Implement

(May apply to)

Approx-imate FUR

Archi-tecting

(May evolve to)

Software

Hardware

Other deliverables

OutlineFUR

Outline NFR

Detailed FUR

True NFR

Size by analogy or expert

judgement

Approx. COSMIC size

measurement

Precise COSMIC size

measurement

Sizing issues

• Our aim is for software-delivered aspects of NFRs to be measured in CFPs, BUT …

• … it is still important to be able to distinguish between:

– CFPs derived from originally ‘outline’, and ‘approximate’, FUR) and

– CFPs derived from NFRs

16

Sizing issues (continued)

• It would also be informative to be able to separate pre- “build” effort used on:

– defining detailed FUR, from ‘approximate’ FUR

– designing and detailing FUR, and true NFR, from ‘outline’ NFR

17

Sizing issues (continued)

• Need common (standard) set of defined project constraints …

– … including their “grading”, that can be used to “tag” project measures

18

Also need consistent measures

19

Project data & benchmarks

Project data & benchmarks

Measuring project and

system sizes

Measuring project and

system sizes

Estimating for projects

Estimating for projects

Measuring project

performance

Measuring project

performance

Benchmarking projects

Benchmarking projects

Taxonomy for NFRs

• Principles (ideals):– Division: organise as a set of independent “orthogonal”

sub-taxonomies– Mutual exclusion: avoid conceptual overlap between the

different dimensions– Relevance: use division only in such a way so that it

improves understanding• Reality:

– Some of the above may be obtained, in part, and it certainly helps understanding, but in the end what matters most to ensure full scope of attention, even if at the expense of some overlap

20

NFR taxonomy, in the broad

• Quality requirements (leading to detailed FUR and true NFRs)– … mostly covered by ISO/IEC

25062:2006*

• True NFRs– Project constraints: i.e. those that the

project itself must adhere to– Technical constraints … pertaining to the

technology environment in which the system will be built and operated

– System demographics: characteristics of the broader environment in which the system is developed, maintained/supported, and used

21

Detailed FURDetailed FUR

True NFRsTrue NFRs

Technical constraintsTechnical

constraintsSystem

demographicsSystem

demographicsProject

constraintsProject

constraints

*ISO/IEC 25062:2006 Software engineering – Software product Quality Requirements and Evaluation (SquaRE)

Quality requirements

Using an NFR taxonomy

• A long list of NFR types exist in the taxonomy, BUT– In many environments many will come “free” (pre-

exist), such as service continuity requirements addressed by standard arrangements in many business computing infrastructures

• There is a growing set of documented approaches to the practice of identifying detailed FUR, or patterns, for commonly encountered NFRs, such as portability

22

Next steps

• Identify and define a standard set of ‘Project’ Constraints

• Identify and define a standard set of demographics

• …

23

24

Thank you for your attention

www.cosmicon.com

chris.woodward@btinternet.com