Requirements Engineering Processes

1
Requirements Engineering Processes
2
Objectives

• To describe the principal requirements
  engineering activities and their relationships
• To introduce techniques for requirements
  elicitation and analysis
• To describe requirements validation and the role
  of requirements reviews
• To discuss the role of requirements management in
  support of other requirements engineering
  processes

3
Topics covered

• Feasibility studies
• Requirements elicitation and analysis
• Requirements validation
• Requirements management

4
Requirements engineering processes

• The processes used for RE vary widely depending
  on the application domain, the people involved
  and the organisation developing the requirements.
• However, there are a number of generic activities
  common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management.

5
The requirements engineering process
6
Requirements engineering
7
Feasibility studies

• A feasibility study decides whether or not the
  proposed system is worthwhile.
• A short focused study that checks
• If the system contributes to organisational
  objectives
• If the system can be engineered using current
  technology and within budget
• If the system can be integrated with other
  systems that are used.

8
Feasibility study implementation

• Based on information assessment (what is
  required), information collection and report
  writing.
• Questions for people in the organisation
• What if the system wasnt implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed
  system?

9
Elicitation and analysis

• Sometimes called requirements elicitation or
  requirements discovery.
• Involves technical staff working with customers
  to find out about the application domain, the
  services that the system should provide and the
  systems operational constraints.
• May involve end-users, managers, engineers
  involved in maintenance, domain experts, trade
  unions, etc. These are called stakeholders.

10
Problems of requirements analysis

• Stakeholders dont know what they really want.
• Stakeholders express requirements in their own
  terms.
• Different stakeholders may have conflicting
  requirements.
• Organisational and political factors may
  influence the system requirements.
• The requirements change during the analysis
  process. New stakeholders may emerge and the
  business environment change.

11
The requirements spiral
12
Process activities

• Requirements discovery
• Interacting with stakeholders to discover their
  requirements. Domain requirements are also
  discovered at this stage.
• Requirements classification and organisation
• Groups related requirements and organises them
  into coherent clusters.
• Prioritisation and negotiation
• Prioritising requirements and resolving
  requirements conflicts.
• Requirements documentation
• Requirements are documented and input into the
  next round of the spiral.

13
Requirements discovery

• The process of gathering information about the
  proposed and existing systems and distilling the
  user and system requirements from this
  information.
• Sources of information include documentation,
  system stakeholders and the specifications of
  similar systems.

14
ATM stakeholders

• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators

15
Viewpoints

• Viewpoints are a way of structuring the
  requirements to represent the perspectives of
  different stakeholders. Stakeholders may be
  classified under different viewpoints.
• This multi-perspective analysis is important as
  there is no single correct way to analyse system
  requirements.

16
Types of viewpoint

• Interactor viewpoints
• People or other systems that interact directly
  with the system. In an ATM, the customers and
  the account database are interactor VPs.
• Indirect viewpoints
• Stakeholders who do not use the system themselves
  but who influence the requirements. In an ATM,
  management and security staff are indirect
  viewpoints.
• Domain viewpoints
• Domain characteristics and constraints that
  influence the requirements. In an ATM, an example
  would be standards for inter-bank communications.

17
Viewpoint identification

• Identify viewpoints using
• Providers and receivers of system services
• Systems that interact directly with the system
  being specified
• Regulations and standards
• Sources of business and non-functional
  requirements.
• Engineers who have to develop and maintain the
  system
• Marketing and other business viewpoints.

18
LIBSYS viewpoint hierarchy
19
Interviewing

• In formal or informal interviewing, the RE team
  puts questions to stakeholders about the system
  that they use and the system to be developed.
• There are two types of interview
• Closed interviews where a pre-defined set of
  questions are answered.
• Open interviews where there is no pre-defined
  agenda and a range of issues are explored with
  stakeholders.

20
Interviews in practice

• Normally a mix of closed and open-ended
  interviewing.
• Interviews are good for getting an overall
  understanding of what stakeholders do and how
  they might interact with the system.
• Interviews are not good for understanding domain
  requirements
• Requirements engineers cannot understand specific
  domain terminology
• Some domain knowledge is so familiar that people
  find it hard to articulate or think that it isnt
  worth articulating.

21
Effective interviewers

• Interviewers should be open-minded, willing to
  listen to stakeholders and should not have
  pre-conceived ideas about the requirements.
• They should prompt the interviewee with a
  question or a proposal and should not simply
  expect them to respond to a question such as
  what do you want.

22
Scenarios

• Scenarios are real-life examples of how a system
  can be used.
• They should include
• A description of the starting situation
• A description of the normal flow of events
• A description of what can go wrong
• Information about other concurrent activities
• A description of the state when the scenario
  finishes.

23
LIBSYS scenario (1)
24
LIBSYS scenario (2)
25
Use cases

• Use-cases are a scenario based technique in the
  UML which identify the actors in an interaction
  and which describe the interaction itself.
• A set of use cases should describe all possible
  interactions with the system.
• Sequence diagrams may be used to add detail to
  use-cases by showing the sequence of event
  processing in the system.

26
Article printing use-case
27
LIBSYS use cases
28
Article printing
29
Print article sequence
30
Social and organisational factors

• Software systems are used in a social and
  organisational context. This can influence or
  even dominate the system requirements.
• Social and organisational factors are not a
  single viewpoint but are influences on all
  viewpoints.
• Good analysts must be sensitive to these factors
  but currently no systematic way to tackle their
  analysis.

31
Ethnography

• A social scientists spends a considerable time
  observing and analysing how people actually work.
• People do not have to explain or articulate their
  work.
• Social and organisational factors of importance
  may be observed.
• Ethnographic studies have shown that work is
  usually richer and more complex than suggested by
  simple system models.

32
Focused ethnography

• Developed in a project studying the air traffic
  control process
• Combines ethnography with prototyping
• Prototype development results in unanswered
  questions which focus the ethnographic analysis.
• The problem with ethnography is that it studies
  existing practices which may have some historical
  basis which is no longer relevant.

33
Ethnography and prototyping
34
Scope of ethnography

• Requirements that are derived from the way that
  people actually work rather than the way I which
  process definitions suggest that they ought to
  work.
• Requirements that are derived from cooperation
  and awareness of other peoples activities.

35
Requirements validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really wants.
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error.

36
Requirements checking

• Validity. Does the system provide the functions
  which best support the customers needs?
• Consistency. Are there any requirements
  conflicts?
• Completeness. Are all functions required by the
  customer included?
• Realism. Can the requirements be implemented
  given available budget and technology
• Verifiability. Can the requirements be checked?

37
Requirements validation techniques

• Requirements reviews
• Systematic manual analysis of the requirements.
• Prototyping
• Using an executable model of the system to check
  requirements. Covered in Chapter 17.
• Test-case generation
• Developing tests for requirements to check
  testability.

38
Requirements reviews

• Regular reviews should be held while the
  requirements definition is being formulated.
• Both client and contractor staff should be
  involved in reviews.
• Reviews may be formal (with completed documents)
  or informal. Good communications between
  developers, customers and users can resolve
  problems at an early stage.

39
Review checks

• Verifiability. Is the requirement realistically
  testable?
• Comprehensibility. Is the requirement properly
  understood?
• Traceability. Is the origin of the requirement
  clearly stated?
• Adaptability. Can the requirement be changed
  without a large impact on other requirements?

40
Requirements management

• Requirements management is the process of
  managing changing requirements during the
  requirements engineering process and system
  development.
• Requirements are inevitably incomplete and
  inconsistent
• New requirements emerge during the process as
  business needs change and a better understanding
  of the system is developed
• Different viewpoints have different requirements
  and these are often contradictory.

41
Requirements change

• The priority of requirements from different
  viewpoints changes during the development
  process.
• System customers may specify requirements from a
  business perspective that conflict with end-user
  requirements.
• The business and technical environment of the
  system changes during its development.

42
Requirements evolution
43
Enduring and volatile requirements

• Enduring requirements. Stable requirements
  derived from the core activity of the customer
  organisation. E.g. a hospital will always have
  doctors, nurses, etc. May be derived from domain
  models
• Volatile requirements. Requirements which change
  during development or when the system is in use.
  In a hospital, requirements derived from
  health-care policy

44
Requirements classification
45
Requirements management planning

• During the requirements engineering process, you
  have to plan
• Requirements identification
• How requirements are individually identified
• A change management process
• The process followed when analysing a
  requirements change
• Traceability policies
• The amount of information about requirements
  relationships that is maintained
• CASE tool support
• The tool support required to help manage
  requirements change

46
Traceability

• Traceability is concerned with the relationships
  between requirements, their sources and the
  system design
• Source traceability
• Links from requirements to stakeholders who
  proposed these requirements
• Requirements traceability
• Links between dependent requirements
• Design traceability
• Links from the requirements to the design

47
A traceability matrix
48
CASE tool support

• Requirements storage
• Requirements should be managed in a secure,
  managed data store.
• Change management
• The process of change management is a workflow
  process whose stages can be defined and
  information flow between these stages partially
  automated.
• Traceability management
• Automated retrieval of the links between
  requirements.

49
Requirements change management

• Should apply to all proposed changes to the
  requirements.
• Principal stages
• Problem analysis. Discuss requirements problem
  and propose change
• Change analysis and costing. Assess effects of
  change on other requirements
• Change implementation. Modify requirements
  document and other documents to reflect change.

50
Change management
51
Key points

• The requirements engineering process includes a
  feasibility study, requirements elicitation and
  analysis, requirements specification and
  requirements management.
• Requirements elicitation and analysis is
  iterative involving domain understanding,
  requirements collection, classification,
  structuring, prioritisation and validation.
• Systems have multiple stakeholders with different
  requirements.

52
Key points

• Social and organisation factors influence system
  requirements.
• Requirements validation is concerned with checks
  for validity, consistency, completeness, realism
  and verifiability.
• Business changes inevitably lead to changing
  requirements.
• Requirements management includes planning and
  change management.