Week 4 1

Requirements Engineering

What is the problem?

Problems with RE

1. The assumption that it only happens early in the life-cycle

2. Concern with getting ‘real work’ done

3. Too much focus on techniques

4. Too much focus on the process

5. No-one’s job and everyone’s job

6. Large gap between theory and practice

Week 4 2

The ‘Waterfall Model’ might be part of the problem

Not (necessarily) the solution either

Week 4 3

5

Explaining the LACK of transfer of RE research to RE practice

1. Lack of training of practitioners.

2. Lack of recognition of RE as a discipline.

3. Existing work patterns in software development.

4. Lack of proof that new techniques will work.

5. Lack of proof that new techniques will scale up.

6. Lack of suitable (i.e. robust) tools.

7. Lack of evaluation of new techniques.

8. Lack of validation of new techniques.

9. Lack of suitable standards.

10. Inherent complexity/difficulty of the requirements task.

Consider this: #1

Dublin Bus, the Luas and the Dart would like to (or at least they ought to) have a facility whereby passengers could buy a single ticket that would allow them to travel on any combination of the three services to get to their destination. The ticket could be a season ticket, day-ticket, return ticket, etc. and the usual discounts could be applied. It is important that no company loses revenue as a result of this facility. The three organisations get together to draw up a Request for Proposals (RFP) so that interested software providers can bid for the contract.

Week 4 4

Consider this: #2A software vendor has a niche market in the manufacturing

logistics application domain.

Logistics is concerned with planning, organising and completing the movement of goods such as raw materials and products from place to place.

All of its customers are manufacturers, but now a large courier company wants this software company to develop a product to support its business - the worldwide pickup and delivery of small packages.

The software company Marketing VP believes the existing logistics package can be re-engineered to the requirements of the courier company.

Consider this: #3

A Big Bank has three thousand branches throughout the country. Customers buy (and sell) foreign exchange such as dollars and sterling from the branches.

Each branch buys the required currency at the market price from a dealer in the Head Office of the Bank.

A new system is required to keep track of these transactions and share/allocate the profit between the branch and Head Office according to current Bank policy.

Week 4 5

Consider this: #4

A psychologist has been awarded a small business innovation research grant to develop his Brain Trainer (BT) software as a set of iPhone apps for enhancing cognition and brain function.

There are already over a thousand subscribers to the PC version of the BT product. The Android market also beckons.

The psychologist’s friend has just graduated from Computer Systems at UL and is keen to get involved in the business.

What have these four examples

got in common regarding

‘engineering the requirements’?

1. ?

2. ??

3. ???

Week 4 6

Compare and contrast

� Large organisations

� 3 big organisations

� New product

� Single-user

� Multiple platforms

� Software company selling software

� Making money from sales

� Offering better service

� Small start-up

� One big organisation

� Old product new use

� Multiple users

� Single platform

� Organisation using software products

� Being more efficient

� Saving and/or control finances

Stacey Matrix , originated by R. Stacey; this version by M. Quinn Patton

Locating the ‘requirements problem’

CertaintyClose to Far from

Clo

se t

o

SimplePlan, control

Zone of Complexity

Technically ComplicatedExperiment, coordinate expertise

SociallyComplicated

Build relationships,

create common ground

Week 4 7

Pohl’s 3 Dimensions of RE

The Representation Dimension

The Specification Dimension

The Agreement Dimension

14

The (original) Three Dimensions

1. The Specification Dimension

• From opaque to complete (KP)

2. The Representation Dimension

• From informal to formal (KP)

3. The Agreement Dimension

• From personal to a common view (KP).

Week 4 8

3-D

The Agreement Dimension Ver. 2

1. User Story as understood by the Agile team’s on-site Customer (or Business Oracle)

2. Accepted requirements: Business or user requirements as informally agreed among the in-house developers their users and any other stakeholders

3. Approved requirements: as formally agreed inside the (developer) organisation following a process of reviews

4. Contractual requirements: as formally agreed between the software supplier and the client organisation.

Week 4 9

The Specification Dimension Ver. 21. The User Story (again)

2. Use cases...

3. Completed IEEE 830 template or Volere template

4. Fully populated requirements management repository complete with forward and backward traceability links.

The Representation Dimension Ver. 21. A Use Case Diagram

2. An Entity Relationship Diagram

3. UML Model: class diagrams, etc., interaction diagrams, etc.

4. Formal model using constraints or a language such as Z, VDM, etc.

Week 4 10

The Goal Dimension� AKA the Goal Design Scale (Soren Lauesen)

1. Goal Level Requirements

2. Domain Level Requirements

3. Product Level Requirements

4. Design Level Requirements

� Going down the scale answers the Howquestion

� Going up the scale answers the Why question.

The Value Dimension (Irene Caulfield)

Week 4 11

Putting the 5 Dimensions together

Like this?

Or like this?

Week 4 12

Dimensional Profile

0

1

2

3

4

Specification

Representation

AgreementGoal

Value

Each of the previous examples 1- 4

� Has its own profile on the radar diagram

� Emphasising more or less focus (and therefore work to be done)on the different dimensions:

◦ Specification

◦ Representation

◦Agreement

◦ Value

◦Goal

Week 4 13

Comparing different Profiles

0

1

2

3

4

Specification

Representation

AgreementGoal

Value

Example A

Example B

Example C