Chapter 6: Requirements Engineering

1
Chapter 6 Requirements Engineering

• It is a process that involves all the activities
  required to create and maintain a system
  requirements document

2
The requirements engineering process
3
Feasibility studies

• A feasibility study decides whether or not the
  proposed system is worth doing
• A short focused study that checks
• If the system contributes to organizational
  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

4
Feasibility studypeople involved

• Technical feasibility
• Engineering management
• Engineering tech leads
• Consultants
• Business feasibility
• Product manager
• Marketing
• Sales
• Customer support
• Key customers

5
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

6
Problems of requirements analysis

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

7
The requirements analysis process
8
Methods of elicitation and analysis

• Viewpoint-oriented elicitation (VORD)
• Analysis of different stakeholders viewpoints
• Replaced with analysis of actors in use cases
• Ethnography observe user behavior
• Valuable for usability requirements
• Analysis of how people actually work
• Scenarios a subset of Use case analysis
• Use case analysis is discussed here

9
Requirements Elicitation with use cases

• Requirements formulated in terms of use cases and
  scenarios
• Make easier the communication between
  requirements engineers and stakeholders
• Help understand the domain
• Requirements collection based on interviews and
  discussions with stakeholders
• Use cases need to be detailed enough to expose
  conflicts
• Validate use cases in discussions with
  stakeholders

10
Requirements validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really needs
• 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

11
Requirements checking

• Important qualities
• Understandable to the user does the system
  provide the functions which best support the
  customers needs?
• Verifiable can the requirements be tested?
• Independent of implementation
• Consistent are there any requirements
  conflicts?
• Complete are all functions required by the
  customer included?
• Realistic can they be implemented given
  available budget, technology and staff?
• Validity. Does the system provide the functions
  which best support the customers needs?
• Precise are the requirements unambiguous?

12
Requirements validation techniques

• Requirements reviews
• Systematic manual analysis of the requirements
• Use case review with customers and requirements
  engineering
• Prototyping
• Using an executable model of the system to check
  requirements. Covered in Chapter 8
• Test-case generation
• Developing tests for requirements to check
  testability
• Automated consistency analysis
• Checking the consistency of a structured
  requirements description (in case it is expressed
  in some formal notation)

13
Requirements reviews

• Regular reviews should be held while the
  requirements definition is being formulated
• Must check the 8 qualities listed before
• 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

14
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 stakeholders have different
  requirements and these are often contradictory

15
Requirements evolution
16
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

17
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

18
A traceability matrix
M o d u l e s
Req_ID A B C D E F G H
1.1 X
1.2 X
1.3 X
2.1 X
2.2 X
3.1 X
3.2 X
3.3 X
19
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

20
Scenarios

• Scenarios are descriptions of how a system is
  used in practice
• A scenario is a sequence of steps describing an
  interaction between a user and a system (Chapter
  3 of Fowler)
• Steps indicate how the system operates
• They are helpful in requirements elicitation as
  people can relate to these more readily than
  abstract statement of what they require from a
  system

21
Use cases

• A use case is a set of scenarios describing a
  common user goal
• Primary and alternate scenarios
• Alternate scenarios are variations of the primary
  (main) scenario
• A set of use cases should describe all possible
  interactions with the system
• Visualized in a UML use case diagram
• Non-functional requirements may not always be
  expressed in use cases.

22
Use case buy a product (from Fowler)

• Primary scenario
• Customer browses through catalog and selects
  items to buy
• Customer goes to check out
• Customer fills in shipping information
• System presents full pricing information,
  including shipping
• Customer fills in credit card information
• System authorizes purchase
• System confirms sales immediately
• System sends confirming email to customer
• Alternative Authorization failure
• At step 6, system fails to authorize credit
  purchase
• Allow customer to re-enter credit card
  information and retry

23
Use case diagram

• Oval for each use case
• Stick figures for external entities (actors)
• Actors dont need to be human e.g, database,
  network, browser
• Arrows from actors to use cases
• Not essential
• Types of relationships between use cases
• Include common use case to other use cases
• Generalization use for representing alternate
  scenarios
• Extend a controlled form of generalization

24
Lending use-case diagram
User
25
Library use-cases
26
Identification of use cases

• Some questions to ask
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• What other systems interface with this system?
• Who provides information to the system?
• Who extract information from the system?
• Does the system do anything automatically at
  present times?
• For each use case identify goal, actors, set of
  scenarios, and pre- and post-conditions

27
Use case goal and conditions

• Use case goal short statement of what the
  primary actor is trying to do
• Different goals ? different use cases
• Pre-conditions
• System state before the use case begins
• Post-conditions
• System state after the use case ends