Quality assurance topic under software requirements engineering.

1. TOPIC 8 QUALITY ASSURANCE
TOPIC 8
PKasyoka 1

2. QUALITY ASSURANCE
Introduction:
8.1 The Importance of Early Quality Assurance
• Requirements engineering is the initial part of
a software development process,
• All later steps of the development are
influenced by the requirements
PKasyoka 2

3. QUALITY ASSURANCE
Introduction:
8.1 The Importance of Early Quality Assurance
• Quality of the requirements an important for
the overall quality of the developed system.
• Quality assurance (QA) is an important but
elusive part of software development
PKasyoka 3

4. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• An issue that originates in the requirements
runs the risk of affecting not only other
requirements but also later phases and can
cause follow-up defects in architecture,
design, coding and testing.
PKasyoka 4

5. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
PKasyoka 5

6. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• Having no intermediate QA, i.e. a quality gate
for the intermediate work products, it is most
likely that the design and implementation are
based on the wrong requirements.
PKasyoka 6

7. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• This, in consequence, leads to high rework
effort as not only the code but most often the
overall system architecture and design have to
be revised due to requirements defects.
PKasyoka 7

8. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• Opportunistic QA leads to a stressful and
costly test and maintenance phases. Issues
should be resolved in the phase of their origin
to avoid costly testing and rework.
PKasyoka 8

9. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• Requirements deficiencies are the prime
source of project failures and that over 40% of
problems in the software development cycle
result from low quality requirements
PKasyoka 9

10. QUALITY ASSURANCE
Why it is important to detect defects as early as
possible?
• QA techniques for requirements are one of
the most promising and cost effective
techniques
• Ensures successful development and to
prevent avoidable rework in later phases.
PKasyoka 10

11. QUALITY ASSURANCE
8.2 Requirements and Quality Assurance
• Quality is hard to define -complex concept,
dependent on organizational viewpoints.
• For example, do fewer defects per lines of code
equal high quality?
• Quality has a very different meaning in different
situations.
• With requirements, notion of quality often
depends on the opinions of various stakeholders.
PKasyoka 11

12. QUALITY ASSURANCE
8.2 Requirements and Quality Assurance
• Define what is meant by a defect in the
requirements phase.
• The terms defects, errors, faults or problems
are other words used with a similar meaning.
• Example, if two stakeholders disagree on one
aspect of a requirement, this is an issue that
should be resolved, but would usually not be
referred to as a defect in the traditional sense.
PKasyoka 12

13. QUALITY ASSURANCE
QUALITY OF REQUIREMENTS
Quality views
• Transcendental view:
• User view:
• Manufacturing view:
• Product view:
• Value-based view:
PKasyoka 13

14. QUALITY ASSURANCE
Quality Attributes for Requirements:
• Correctness-IEEE user view
• Unambiguity-IEEE product view
• Consistency-IEEE pruduct, manufacturing
• Ranked for importance-IEEE product, value
based user view
PKasyoka 14

15. QUALITY ASSURANCE
• Verifiability-IEEE product view
• Modifiability-IEEE product view
• Traceability-IEEE manuafacturing view
• Comprehensibility-IEEE manufacturing, user,
value-based
• Feasibility-IEEE value based, product
• Right level of detail-IEEE manufacturing, value
based
PKasyoka 15

16. QUALITY ASSURANCE
REQUIREMENTS QUALITY STRATEGY
PKasyoka 16

17. QUALITY ASSURANCE
There are five context elements relevant for QA
strategies:
1. The quality of requirements
2. The available resources
3. Risks
4. Time Schedule:
5. Organizational Aspects:
PKasyoka 17

18. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
PKasyoka 18

19. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
8.3 Constructive approaches:
• Mistakes are minimized during the creation of a work
product (e.g. the requirements specification).
• These approaches are called constructive as they are
applied while developing the requirements.
1) Elicitation Techniques
• During the elicitation step, requirements are captured
from various sources, such as the customer, the users,
earlier projects market studies etc.
PKasyoka 19

20. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
8.3 Constructive approaches:
2) Specification Techniques
• The output of the specification activity is a
requirements document that captures the relevant
aspect of the system to be built (i.e. functional, non-
functional aspects, restrictions, etc.)
3) Prototyping
• A prototype is an executable version of the system
under development, though restricted in one way or
another.
PKasyoka 20

21. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
8.4 Analytical Approaches
• The analytical quality assurance approaches
assess the requirements specification to check
whether the requirements specified in there
fulfill the quality criteria specified.
PKasyoka 21

22. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
8.4 Analytical Approaches
1) Requirements Inspections
• Inspections are a valuable means to ensure
the quality of a software product right after its
creation.
PKasyoka 22

23. QUALITY ASSURANCE
QUALITY ASSURANCE APPROACHES FOR
REQUIREMENTS
8.4 Analytical Approaches
2) Requirements-Based Testing
• Test cases are usually defined and run on the
system to validate whether the system fulfills
its specification
PKasyoka 23

24. TOPIC 9 MODELING GOALS
PKasyoka 24

25. Modeling Goals and Reasoning
Introduction
• Goals have long been recognized to be an
essential component involved in the RE
process
• Typically, the current system is analyzed;
problems are pointed out and opportunities
are identified;
PKasyoka 25

26. Modeling Goals and Reasoning
Introduction
• high level strategic goals are elicited and
refined to address such problems and meet
such opportunities; requirements are then
elaborated to meet these goals.
• Goals are thus the driving force of the
requirements engineering process.
PKasyoka 26

27. Modeling Goals and Reasoning
Introduction
• Goal-driven approaches have proved to be an
effective way to elicit requirements and also to
support a systematic exploration of design
choices to check requirements completeness
• The leading role played by goals in the RE process
led to a whole stream of research on goal
modeling, goal specification/formulation and
goal-based reasoning for the multiple
aforementioned purposes.
PKasyoka 27

28. Modeling Goals and Reasoning
9.2 State-of-the-Art Review
RE is “concerned with :
• the identification of goals to be achieved by
the envisioned system,
• the operationalization of such goals into
services and constraints,
• and the assignment of responsibilities of
resulting requirements to agents as humans,
devices, and software”.
PKasyoka 28

29. Modeling Goals and Reasoning
9.2 State-of-the-Art Review
Goals drive the RE process which focuses on
goal centric activities such as:
• Goal elicitation,
• Goal modeling,
• Goal operationalization and
• Mapping goals onto software objects, events
and operations.
PKasyoka 29

30. Modeling Goals and Reasoning
What Are Goals?
• A goal corresponds to an objective the system should
achieve through the cooperation of agents in the
software to be and in the environment”.
• Refer to intended properties of envisioned system or of
its environment.
• Can be formulated at different levels of abstraction
ranging from high-level, e.g. strategic results that an
enterprise wants to achieve, down to low-level, e.g.
technical concerns on precise situations that a system
component should help to reach
PKasyoka 30

31. Modeling Goals and Reasoning
What Are Goals?
• Unlike requirements, goals are usually
achieved by the cooperation of multiple
agents.
• A goal under the responsibility of a single
agent in the software becomes a requirement.
• One important decision in the RE process is
therefore to decide which goals will be
automated and which ones will not.
PKasyoka 31

32. Modeling Goals and Reasoning
Discuss the roles of Goals
1) Requirements elicitation:
• Goal modeling proved to be an effective way to
elicit requirements.
2) Exploration of design choices:
• RE assumes that the envisioned system might
function and interact with its environment in
many alternative ways.
• Alternative goal refinement proved helpful in the
systematic exploration of system choices.
PKasyoka 32

33. Modeling Goals and Reasoning
Discuss the roles of Goals
3) Requirements completeness is a major RE issue.
• Goals provide a criterion for requirements
completeness: if the requirements are sufficient to
achieve the goal they refine.
4) Requirements traceability:
• Goals provide a means to ensure requirements pre-
traceability.
5) Requirements negotiation:
• Stakeholders provide useful and realistic viewpoints
about the system to be.
PKasyoka 33

34. Modeling Goals and Reasoning
What are Contributions of Goal Modeling
Approaches?
a) Modeling Goals
• Goal Taxonomies:
• Goal Links:
PKasyoka 34

35. Modeling Goals and Reasoning
What are Contributions of Goal Modeling
Approaches?
b) Formulating Goals:
• Goal formulation is necessary to document the
goal model and to support some form of
reasoning.
• Goal formulation can be informal, semi-formal or
formal.
• Goal statements are often texts in natural
language.
PKasyoka 35

36. Modeling Goals and Reasoning
What are Contributions of Goal Modeling
Approaches?
c) Reasoning with Goals:
• Eliciting Goals by Reuse:
• Eliciting Goals from Scenarios:
• Eliciting Goals by Refinement:
• Obstacle Driven Elaboration:
• Conflict Resolution:
PKasyoka 36

37. Modeling Goals and Reasoning
Weaknesses of Goal-Driven Approaches
1. Mitigating goal abstractness:
2. Finding the right goal:
3. Removing goal fuzziness:
4. Guiding alternative goals discovery:
PKasyoka 37

38. THE END
PKasyoka 38