RE PROCESSES

What RE process do we follow?

Lecture 9

Some slides in this lecture adapted from https://www.ifi.uzh.ch/en/rerg/courses/hs23/re-i.html

Announcements

• Thursday’s lecture (5/9) will be pre-recorded and posted
• No in-person lecture that day
• HW4 due Thursday 11:59pm
• HW4 peer eval (optional) closes Friday 11:59pm
• EXAM #2 is next Tuesday
• Covers lectures 7-10

Text questions to (562) 684-8307

2

Mid-quarter Feedback – The Good

• Attendance quizzes/kahoots
• Recorded lectures
• Homeworks
• Homework examples
• Group work
• Lectures/slides
• Revise/resubmit opportunity
• Experience of elicitation in discussion

3

Mid-quarter Feedback – Suggestions

• More organized/less confusing elicitation sessions
• More kahoots
• Switch the order of HW3 and HW2
• HW examples for all HWs
• Close elicitation question google docs for editing before discussion starts
• Make discussions online

4

Mid-quarter Feedback – Misunderstandings

• Lectures are all recorded and posted in the modules
• Study guides for each exam are given in the slides the lecture before the exam

5

Canvas Quiz

​

​

​

Lecture 9: Lecture 8 Review

Text questions to (562) 684-8307

6

Last Time – How can we specify requirements with natural language effectively?

• Major problems with NL specs: ambiguities/misinterpretation, incompleteness, and contradictions
• Natural language tips:
• Use shall/will/should carefully
• Avoid imprecise terminology
• Make it measurable!
• Requirements templates help by adding structure
• User stories are the most common way to express requirements in agile processes
• Follow a specific template

Text questions to (562) 684-8307

7

Today’s Lecture – What RE process do we follow?

• Influencing factors
• Process facets
• Configuring an RE process
• Further RE process considerations

​

Text questions to (562) 684-8307

8

Process: What and why

• DEFINITION. Process – A set of interrelated activities performed in a given order to process information or materials.
• An RE process organizes how to carry out RE tasks, using appropriate practices and producing needed work products

Text questions to (562) 684-8307

9

The principal tasks

Requirements Specification

• Elicitation & Analysis
• Documentation
• Validation

​

Requirements Management

• Identification and metadata
• Requirements prioritization
• Change and release management
• Traceability

Text questions to (562) 684-8307

10

Pre-work: Ideal RE Process for GGSM?

• Elicit, document, analyze, validate
• Also:
• Determine goals/scope
• Prototype
• Observe
• Stakeholder identification
• Document study
• Develop user stories
• Iterate

11

Today’s Lecture – What RE process do we follow?

• Influencing factors
• Process facets
• Configuring an RE process
• Further RE process considerations

​

Text questions to (562) 684-8307

12

Influencing factors

There is no “one size fits all” process

​

Many influencing factors:

• Development context
• Stakeholder availability and capability
• Shared understanding
• Complexity and criticality
• Constraints
• Time and budget available
• Volatility of requirements
• Experience of requirements engineers

Text questions to (562) 684-8307

13

Today’s Lecture – What RE process do we follow?

• Influencing factors
• Process facets
• Configuring an RE process
• Further RE process considerations

​

Text questions to (562) 684-8307

14

Process facets

There are three process facets, from which an RE process can be configured:

• Time facet: Linear vs. Iterative
• Purpose facet: Prescriptive vs. Explorative
• Target facet: Customer-Specific vs. Market-Oriented

​

• Selection criteria indicate how to configure the process in each facet

Text questions to (562) 684-8307

15

Time facet: Process structure

Text questions to (562) 684-8307

16

Time facet: Linear

Requirements are specified up front in a single phase of the

Process

​

Selection criteria:

• System development process is plan-driven and mostly linear
• Stakeholders can specify their requirements up front
• Comprehensive requirements specification required as a contractual basis for outsourcing design and implementation
• Regulatory authorities require a requirements specification

Text questions to (562) 684-8307

17

Time facet: Iterative

Requirements are specified incrementally, starting with

general goals and then adding or modifying requirements in

every iteration

​

Selection criteria:

• System development process is iterative and agile
• Evolving requirements – not known up front
• Stakeholders are available such that short feedback loops established for mitigating risk
• Duration of project allows for more than 1-2 iterations
• Ability to change requirements easily is important

Text questions to (562) 684-8307

18

Purpose facet: Prescriptive

Requirements specification is a contract: All requirements are binding and must be implemented

​

Selection criteria:

• Customer requires fixed-price contract
• Functionality determines cost and deadlines
• Design and implementation tendered or outsourced

Text questions to (562) 684-8307

19

Purpose facet: Explorative

Only goals known, concrete requirements have to be explored

​

Selection criteria:

• Stakeholders only have a vague idea about their requirements
• Stakeholders strongly involved, provide continuous feedback
• Deadlines and cost take precedence over functionality
• Customer is satisfied with a framework contract
• Not a priori clear which requirements shall actually be implemented and in which order
• Prioritization needed

Text questions to (562) 684-8307

20

Target facet: Customer-Specific

System is ordered by a customer and developed by a

supplier for this customer

​

Selection criteria:

• System will be mainly used by the organization that has ordered the system and pays for its development
• Important stakeholders are mainly associated with the customer’s organization
• Individual persons can be identified for the stakeholder roles
• The customer wants a requirements specification that can serve as a contract

Text questions to (562) 684-8307

21

Target facet: Market-Oriented

System is developed as a product or service for a market

​

Selection criteria:

• Developing organization (or one of its clients) intends to sell the system as a product or service in some market segment
• Prospective users not individually identifiable
• Requirements engineers have to design the requirements so that they match the envisaged needs of the targeted users
• Product owners, marketing people, digital designers and system architects are primary stakeholders

Text questions to (562) 684-8307

22

Canvas Quiz

​

​

​

Lecture 9: Process Facets

Text questions to (562) 684-8307

23

Hints and caveats

• Linear RE processes only work if a sophisticated process for changing requirements is in place
• Linear RE processes imply long feedback loops: intensive validation of requirements must be performed
• Market-oriented RE processes depend on fast feedback from pilot users
• In an agile setting, an iterative and explorative RE process fits best

Text questions to (562) 684-8307

24

Facet combinations

• Linear and prescriptive are frequently chosen together
• Explorative processes are typically also iterative
• Market-Oriented does not combine well with linear and prescriptive

Text questions to (562) 684-8307

25

Today’s Lecture – What RE process do we follow?

• Influencing factors
• Process facets
• Configuring an RE process
• Further RE process considerations

​

Text questions to (562) 684-8307

26

Configuring an RE process

1. Analyze the influencing factors
2. Assess the facet criteria
3. Configure
• Select one of the subsequent typical configurations where appropriate
• Otherwise choose what is most appropriate with respect to value and risk
4. Determine main work products to be produced
5. Select appropriate practices for the tasks to be performed according to the chosen process

Text questions to (562) 684-8307

27

Typical RE process configurations (1)

Participatory: Iterative & Explorative & Customer-Specific

• Main application case: Supplier and customer closely collaborate; customer stakeholders strongly involved both in specification and development processes
• Typical work products: Product backlog with user stories and/or task descriptions, vision, prototypes, use cases, various models
• Typical information flow: Continuous interaction between stakeholders, product owners, requirements engineers, and developers

Text questions to (562) 684-8307

28

Typical RE process configurations (2)

Contractual: Typically Linear (sometimes Iterative) & Prescriptive & Customer-Specific

• Main application case: Specification constitutes contractual basis for development of a system by people not involved in the specification and with little stakeholder interaction after the requirements phase
• Typical work products: Classic system requirements specification, consisting of textual requirements and models
• Typical information flow: Primarily from stakeholders to requirements engineers

Text questions to (562) 684-8307

29

Typical RE process configurations (3)

Product-oriented: Iterative & Explorative & Market-Oriented

• Main application case: An organization specifies and develops software in order to sell/distribute it as a product or service
• Typical work products: Product backlog with user stories and/or task descriptions, vision, prototypes, user feedback, use cases, various models
• Typical information flow: Interaction between product owner, marketing, requirements engineers, digital designers, and developers plus feedback from customers/users

Text questions to (562) 684-8307

30

Today’s Lecture – What RE process do we follow?

• Influencing factors
• Process facets
• Configuring an RE process
• Further RE process considerations

​

Text questions to (562) 684-8307

31

Further RE process considerations

• What if none of the typical process configurations fits?
• Try to tailor the configuration with the closest fit
• Get help from an RE process expert for building a process from scratch
• RE in agile development?
• Is there something like an “ideal” RE process?

Text questions to (562) 684-8307

32

RE processes in agile development

Short feedback cycles are key

​

For small to medium, single-team projects:

• Goals and vision established upfront
• Requirements loosely specified as stories (with details captured in acceptance criteria)
• Using prototypes (both exploratory and evolutionary) for validating the vision
• Customer and/or product owner prioritizes requirements at the beginning of each iteration

Text questions to (562) 684-8307

33

Characteristics of an “ideal” RE process

• Strongly interactive: iterative and explorative
• Close and intensive collaboration between
• Stakeholders (know the domain and the problem)
• Requirements engineers (know how to specify)
• Very short feedback cycles
• Risk-aware and feasibility-aware
• Technical risks/feasibility
• Deadline risks/feasibility
• Careful negotiation / resolution of conflicting requirements
• Focus on establishing shared understanding
• Strives for innovation

Text questions to (562) 684-8307

34

RE Problems

• Natural language problems
• Domain understanding
• Business needs not adequately considered
• Dealing with complexity
• Incompleteness
• Inconsistency
• Incorrectness
• Over-completeness (gold-plating)
• Limited user/stakeholder involvement/communication
• Poor requirements management

35

Sources: Kotonya and Sommerville, 1998; LaPlante, P.A.: Requirements Engineering for Software and Systems, 2018.

36

Source: Fernandez, DM: “Supporting Requirements Engineering Research that Industry Needs,” IEEE Software 35(1), Jan/Feb 2018.

Requirements Engineer Desired Skills

• Organized
• Experienced throughout the SE lifecycle
• Understands the problem domain
• Mature enough to know when to be general/specific
• Able to stand up to the customer when necessary
• Good manager, listener, negotiator

37

Source: LaPlante, P.A.: Requirements Engineering for Software and Systems, 2018

Summary – What RE process do we follow?

• There is no “one size fits all” RE process
• Many influencing factors exist
• An RE process can be configured based on three facets: time (linear/iterative), purpose (prescriptive/explorative), and target (customer/market)
• Some typical RE process configurations are participatory, contractual, and product-oriented

Text questions to (562) 684-8307

38

For Next Time

• Complete Lecture 10 Pre-Work: “Story” of GGSM

39