ISD Lecture 5 Requirement Analysis: Benefits & Strategies

Question 1

Benefits dependency network (BDN):

Answer 1

The BDN provides the framework for explicitly linking the overall investment objectives and required benefits (the ends) with the business changes (the ways) necessary to deliver those benefits and the essential IT capabilities (the means) that enable these changes.

Question 2

Requirements engineering (RE):

Answer 2

The broad spectrum of task and techniques that lead to an understanding of requirements (to IT systems).

Requirements engineering is the process of conforming engineering designs to a set of core software requirements. This is critically important for creating accurate results in software engineering.

Question 3

Problem-based interventions: ends drive

Answer 3

The goal is the target improvements.

Question 4

Innovation-based interventions: ways and means-driven:

Answer 4

The goal is to discover better ways of working by utilizing or new ways.

Question 5

Functional requirements

Answer 5

The calculations and information that the systems have to deliver.

Question 6

Non-funcitonal requirements:

Answer 6

it will be such as security, usability and performance etc.

Question 7

Two types of investments

Answer 7

Problembased interventions:
ends-driven because the goal is the target improvements. For example, 10% improved productivity in a business process.

Innovationbased intervention:
ways and means-driven because the goal is to discover better ways of working by utilizing IT (the means). For example, how could we benefit from using AI?

Question 8

Characteristics for Problem-Based Interventions

Answer 8

Clear targets:
When the investment is problem-driven, setting targets is appropriate. The organization can usually identify and quantify the benefits of removing known problems through new IT means and new ways of executing business processes and activities.

Question 9

Challenge with Problem-Based Interventions

Answer 9

Agreeing on the best combination of ways and means for accomplishing the improvements.

Question 10

Characteristics for Innovation-Based Interventions (Ways-Based or Means-Based)

Answer 10

• Unclear targets
• Unclear benefits
• Requires creativity
• Requires on-gong learning
• Risk – too much focus on technology

Question 11

The BDN framework

Answer 11

linking the overall investment objectives and required benefits (the ends) with the

business changes (the ways) necessary to deliver those benefits and

the essential IT capabilities (the means) that enable these changes.

Model: IT enablers (Means) -> Enabling Changes (Ways) -> Business Changes (Ways) -> Benefits (Ends) -> Investments objectives (Ends)

Question 12

Two types of requirements engineering

Answer 12

Classic requirements engineering,
and
Agile requirements engineering

Question 13

Req. engineering classic: plan-driven

Answer 13

Analysis -> design -> code -> test

We complete the requirements engineering before we move along

Question 14

Req. engineering classic: plan-driven - The basic activities

Answer 14

Inception: ask management a set of questions that establish …
• basic understanding of the problem
• the people who want a solution

Elicitation: elicit requirements from all stakeholders

Elaboration: create an analysis model that identifies data, function and behavioral requirements

Negotiation: agree on a deliverable system that is realistic for developers and customers

Specification: can be any one (or more) of the following:
• A written document
• A set of models
• A formal mathematical
• A collection of user scenarios (use-cases)
• A prototype

Validation: a review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information

Requirements management

Question 15

Inception

Answer 15

Identify stakeholders
• “who else do you think I should talk to?”
• Make a list of all the stakeholders that must be included
Recognize multiple points of view
• Different departments or roles will typically have different, sometimes conflicting requirements
Work toward collaboration
• Identify requirement that all agree on and the requirements that conflicts

Question 16

Eliciting Requirements

Answer 16

Meetings are conducted and attended by both software engineers and customers:

the goal is 
•	to identify the problem
•	propose elements of the solution
•	negotiate different approaches, and
•	specify a preliminary set of solution requirements

Typical Elicitation Work Products
a list of requirements (preferably organized by function) and the domain constraints that apply to each.

Question 17

Eliciting Functional requirements

Answer 17

Use-Cases
A collection of user scenarios that describe the thread of usage of a system

Each scenario answers the following questions:
• Who is the primary actor, the secondary actor (s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?

Use-Case diagram

Question 18

Elaboration : Building the Analysis Model

Answer 18

Building a model that describes the functions, the data, behavioral aspects in the system.

Question 19

Negotiating Requirements

Answer 19

Key stakeholders will be involved in the negotiation
Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious
Negotiate
• Work toward a set of requirements that lead to “win-win”

Question 20

Validating Requirements

Answer 20

Is each requirement consistent

Have all requirements been specified at the proper level of abstraction?

Is the requirement really necessary

Is each requirement bounded and unambiguous?

Is each requirement achievable

Is each requirement testable, once implemented

Question 21

Requirements management

Answer 21

Is the management effort focusing at:

Managing all changes to the requirements

Question 22

Req. engineering : agile

Answer 22

Each iteration contains requirement engineering activities

agile Development model, with 
short iterations 
feature planing
dynamic prioritization 
feedback and change
teamwork 
customer collaboration

Question 23

Why Agile RE

Answer 23

Rapid changes:
• Changes in: competitive threats, stakeholder preferences, software technology, time-to-market pressures etc.
• Makes requirements evolve or become obsolete: Requirements tend to evolve very quickly and become obsolete even before project completion.

Question 24

Agile req asumptions

Answer 24

The changing-requirements assumption:
Requirements always evolve

The documentation assumption:
Developing extensive documentation and models is counterproductive

The customer interaction assumption:
Customers are available for frequent interaction with the developers.

The cost-of-change assumption:
The cost of making changes to the system does not dramatically increase over time.

Question 25

Classic req assumptions

Answer 25

The assumptions underlying RE in traditional development include the following: • The customer is able to specify all his/her needs in the initial phase. • One or more stakeholders are in charge of the requirements gathering activity. • The development team can readily understand customer needs. • The structure of the organizations is hierarchical, and there is a sharp separation of the different functions.

Question 26

Agile RE practices

Answer 26

Six agile practices: • Face-to-face communication over written specifications, • iterative RE, • managing requirements change through constant planning, • extreme requirements prioritization, • prototyping, and • review meetings and tests.

Question 27

Face-to-face communication over written specifications

Answer 27

Simple techniques such as user stories are used to define high-level requirements. User story: • As a so that I can . • As a cyclist , I want to register my routes, so I can invite other cyclist to join me when training The effectiveness of this practice heavily depends on the intensive interaction between customers and developers. A short daily meeting between the team and the customer is another mechanism used to enhance communication.

Question 28

Iterative Requirements engineering

Answer 28

In agile development, requirements are not pre-defined; instead they emerge during the development process.

Question 29

Requirement prioritization

Answer 29

Prioritization is essential in requirements analysis, especially for projects that have limited resources in terms of budget, staff and schedule Requirements can be categorized from the standpoint of importance into • essential requirements, • useful capabilities and • desirable capabilities

Question 30

Managing requirements change through constant planning

Answer 30

A core principle in agile software development is to adapt and react quickly to changes demanded by the environment.

Question 31

Prototyping

Answer 31

One of the fastest ways to settle requirements specifications seems to be the development of a prioritized list of features.

Question 32

Use review meetings and acceptance tests

Answer 32

Agile approaches use frequent review meetings for requirements validation. At the end of each development cycle, a meeting that involves developers, customers, Quality Assurance (QA), management and other stakeholders is scheduled.

Question 33

Agile RE challenges

Answer 33

Problems with cost and schedule estimation: The agile approach towards RE makes the estimation of costs and schedules more difficult than with traditional methods. Inadequate or inappropriate architecture: The architecture chosen during the early cycles may become inadequate as newer requirements become known. Neglect of non-functional requirements: A major concern with iterative RE in agile development is the inadequate attention given to non-functional requirements Customer access and participation: : The effectiveness of communication between the customer and team depends on several factors, including: • customer availability; • customer consensus; and • customer trust, especially at the beginning of the project. Several customers groups: • The development team needs to spend extra effort to integrate the requirements of different segments through negotiation with each customer. Trust: • The establishment of trust between the customer and the developer can be very challenging in agile development. Prioritization on a single dimension: Inadequate requirements verification: Minimal documentation:

Question 34

How to use Requirement engieering

Answer 34

Off course both agile and plan-based approaches to RE must be tailored to the specific context. For example, in the plan-based approach you need to decide how to document requirements, and in the agile approach you need to carefully consider which users to integrate in the team. In both cases you need to integrate benefits realization (for example using BDN) into RE processes, to make sure that you actually work on the requirements that might support the creation of business benefits. The two approaches to RE (plan-driven and agile) are related to the two different ways of using BDN’s: A plan-driven approach will be extremely difficult when working with innovation-based interventions.

Question 35

Reflections and Relations

Answer 35

Relating benefits and requirements It is clear that both plan-driven and agile approaches lacks a transparent and explicit linkage between the business benefits to be achieved and the requirements to IT systems. None of the approaches are benefits driven. It is also clear that both approaches lacks transparency between the different factors in a BDN that together supports benefits delivery and value creation – it is not documented /discussed in the plan-driven or agile approaches how requirements to IT-enablers and requirements to Business changes somehow must be aligned. This is off course highly problematic.