Elicitation of standards for Non-Functional requirements of a
software system
Presented by:Sweety YadavaElicitation of standards for
Non-Functional requirements of a software systemNon Functional
RequirementsNon Functional requirement is a term which limns those
requirements that generally focus on quantifying the quality of the
software than those requirements which are essential entities for
its operation such as usability, performance, interoperability,
security and flexibilityIt is necessary to elicit levels of non
functional requirements to keep a balance between the benefits of
the quality attributes and the cost of the software system being
developed it is necessary maintain the non functional quality
attributes within optimum levels.Background ISO/IEC 9126: It is a
standard developed by International Standards Organization which
represents a software quality model and distinguishes 4 types of
quality levels:1. Quality in Use2. External Quality3. Internal
Quality4. Process Quality Software Quality Tree: The
classifications of quality levels can be in made in several schemes
with the help of a software quality tree. It helps us to identify
key non functional requirements an their various possible
correlations.
Literature ReviewF. Fotrousi et al. In this paper levels of good
enough quality were identified for telecommunications system.The
quality of experience (QOE) by a user is affected by the quality of
services (QOS) provided by the supplier which is measured on the
basis of the service level agreements (SLA) between the system
supplier and the customer.The methodology comprised of a 4 step
inquiry cycle process which can be iteratively applied until the
stakeholder satisfaction is attained for the quality attribute
under investigation.
Literature ReviewB. Regnell, et al.In this paper a new model was
proposed and termed as QUPER to identify and categorize quality
attributes. It is proposed to view quality in a continuous and non
linear approach that can be depicted through different shades on a
sliding scale. The QUPER model quantifies the levels of quality
attributes in three general views based on two basic concepts of
breakpoint and barrier.Benefit Viewa) Utility breakpointb)
Differentiation breakpointc) Saturation breakpointCost View a)
BarriersRoadmap Viewa) Barriersb) BreakpointSix steps of QUPER
model
Identify Quality AttributesEstimation of Breakpoints and
Barriers Estimation of Current Quality Attributes with respect to
Competitors Set Targets for New Quality Attributes. Approving and
Communicating the Roadmap. Revising and Finalising of Roadmap
Literature ReviewJ. Boegh In this paper detailed explanation of
ISO/IEC 25030 is given which the revised version of ISO/IEC
9126.The ISO/IEC 9126 software quality model lags in interpreting
the software functional abilities and handling the size of the data
of software quality requirements by the model was complex. Since
software is a part of the system the software quality requirements
are related directly to system quality requirements.The system
model includes the computer system, mechanical parts and the human
processes which satisfactorily describes software quality
requirements in the system perspectives.The newly introduced
ISO/IEC 25030 standard does not provide a specific elicitation
method but instead provide a general applicable guideline to be
used in specific approaches.This standard is subjected to both
acquirers and suppliers to provide requirements and recommendations
for specifying quality requirements of the software and the
system.
Scope of Future WorkThe future work should be aimed at
validating the available different models for elicitation of levels
of quality requirements of a software system in large scale
requirement engineering situations. Several different combinations
of the software quality attributes should be studied to evaluate
the quality impact and understand the inter-relationships among the
attributes. The easy to use model like QUPRA should be considered
in the standards which directly relate the benefits of the system
attributes to the cost of the software system.The further studies
are required to understand the effects of system quality attributes
to the software quality attributes.
ReferencesJ. Boegh, "A New Standard for Quality Requirements,"
IEEE Software, vol. 25, pp. 57-63, 2008.B. Regnell and J.
Brinkkemper, Market-Driven Requirements Engineering for Software
Products, Engineering and Managing Software Requirements, A. Aurum
and C. Wohlin, eds., Springer, pp. 287308, 2005.B. Regnell, R.
Berntsson Svensson, and S. Olsson, "Supporting Roadmapping of
Quality Requirements," IEEE Software, vol. 25, pp. 42-47, 2008.B.
Paech, D. Kerkow, Non- Functional requirements engineering- quality
is essential, Proceedings of the 10th Anniversary International
Workshop on Requirements Engineering: Foundation of Software
Quality (REFSQ'04), pp. 237-250, 2004. ISO/IEC 9126-1:2001(E),
Software Engineering - Product Quality - Part 1: Quality Model,
2001. B. W. Boehm, J. R. Brown, H. Kaspar, M. Lipow, G. J. MacLeod,
M. J. Merritt, Characteristics of Software Quality. North-Holland,
Amsterdam (1978)C. Irvine and T. Levin, "Quality of Security
Service," presented at the 2000 Workshop on New Security Paradigms
(NSPW'00), New York, NY, USA, 2000.A. I. Antn and C. Potts, "The
use of goals to surface requirements for evolving systems," in
International Conference on Software Engineering, Kyoto, Japan,
pp.157-166, 1998.F. Fotrousi, S. A. Fricker, M. Fiedler, Quality
Requirements Elicitation Based on Inquiry of Quality-Impact
Relationships, 22nd international Requirements engineering
conference, IEEE, Karlskrona, pp. 303-312, 2014.M. Fiedler, T.
Hossfeld, and P. Tran-Gia, "A generic quantitative relationship
between quality of experience and quality of service," Network,
IEEE, vol. 24, pp. 36-41, 2010.
