iwsm2014 cosmic masterclass part 2 - dealing with nfr (chris woodward)
DESCRIPTION
IWSM WorkshopTRANSCRIPT
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