Towards Improving Requirements Engineering Processes: Prioritizing Requirements Engineering Process

1
Towards Improving Requirements Engineering
Processes Prioritizing Requirements Engineering
Process Problems for Elimination

• Bhavani Palyagar
• PhD Student, ICS

2
Contents of this Presentation

• Research Motivation and Problem
• Tested Solution
• Results

3
Research Motivation

• An important sub problem of the main research
  Framework for validating RE process improvement
• If we eliminate RE process problems, we can
  eliminate poor quality requirements
• We may not have resources to eliminate all the
  process problems, as a result we may eliminate
  some of them (x1, x8, x17)
• Which are the key process problems to eliminate?
• What benefits is this improvement exercise going
  to provide?

Requirements Engineering (RE) Process Problems
x1, x2, x3xn
Software defects y1, y2, y3yn
Poor quality requirements R1, R2, R3..Rn
4
Research Collaboration in Industry

• Organization 1-Large and complex software
  projects for government departments in Australia
  and USA, with distributed setup USA ? Australia
  ? India (Tested the problem and the solution)
• Organization 2 Complex human health systems
  (Tested the problem)

5
Failure Analysis

• RE process improvement could not measure the
  benefits
• Accountability of RE process improvement could
  not be established
• RE processes was no more a Key Process Area (KPA)
  for improvement
• Code review process was chosen as a KPA in one
  organization

6
Research Problem

• How to correctly prioritize (1,2,3n) identified
  RE process gaps (PG1, PG2, PG3PGn) for
  elimination?
• Correct priority is based on improvement benefit
• Improvement benefits
• Reduced defects delivered to the customer against
  RE process improvement effort
• Reduced SDLC time

7
Contents of this Presentation

• Research Motivation and Problem
• Tested Solution
• Results

8
Solution

• Measure the RE process (Not in terms of the
  number of issues in the issues log, and their
  severity) in terms of its product
• Measure the RE product Requirements
• However, count of requirements may not convey any
  meaningful measurement (Project A has 10
  requirements/3000 and Project B has 20
  requirements/3000. RE of Project B is not better
  than Project A)
• Measurement failures indicated by
• Any one would write a spec
• Spec was not used by SDLC staff

9
Requirement Unit (RU)

• A set of requirements involved to perform a unit
  of work by a user who represents a role, by a
  device, by a data file or by another computer
  program that can be outside of the software or
  part of it
• An RU can not change unless business context
  changes
• How many RUs/unit cost is a measure of RE
• RU is a better measure because RU indicates unit
  of work (Project A has 10 RUs/3000 and Project
  B has 20 RUs/3000. RE of Project B is better
  than Project A)
• The above indicate that interplay of RE, Risk
  Management (RM) and Change Management (CM) is
  important to improve RE
• Success factors Spec was was written by skilled
  resources who understood business, spec was used
  by most SDLC staff, UI design was easier,
  establishing QFD was not a nightmare anymore

10
Prioritization

11
Queue
12
Priority

Benefits considered
Cost factors considered
13
Contents of this Presentation

• Research Motivation and Problem
• Proposed Solution
• Results

14
Results

• RU appears to be a measure of an RE process
• Measurement of defects to customer and cancelled
  defects established
• With RM1, RM3, RE6, CM3 and RE 4 closed,
  measurement indicates
• Requirement defects/KLOC is reduced by 38
• Cancelled requirement defects/KLOC (works as
  intended and configuration errors) reduced by 41

15

• Thank you