Agile requirements engineering

27
1

description

 

Transcript of Agile requirements engineering

Page 1: Agile requirements engineering

1

Page 2: Agile requirements engineering

2

Page 3: Agile requirements engineering

www.danradoiu.ro

Study: 68 percent of IT projects fail!

Source: www.techrepublic.com

3

Page 4: Agile requirements engineering

Facts and Figures

www.danradoiu.ro

17% of large IT projects go so badly that they can

threaten the very existence of the company.

On average, large IT projects run 45% over budget, while

delivering 56% less value than predicted.

A truly stunning 78% of respondents reported that the

“Business is usually - or always! - out of sync with project

requirements”.

Source: Why Projects Fail

4

Page 5: Agile requirements engineering

Agile Requirements Engineering

A practical approach

Page 6: Agile requirements engineering

Yours truly :)

www.danradoiu.ro 6

Page 7: Agile requirements engineering

Agenda

Seven Questions Analysis.

The Now, The Work and The Goal.

Navigational Mockups.

F.U.R.P.S. Requirements.

User Stories and Usage Scenarios.

www.danradoiu.ro 7

Page 8: Agile requirements engineering

What do we search to achieve

when performing

requirements engineering?

www.danradoiu.ro 8

Page 9: Agile requirements engineering

To describe that product or service

(a great one, if it’s possible)

that will put a smile on our

customer’s face.

www.danradoiu.ro 9

Page 10: Agile requirements engineering

Each question reveals a different dimension

The Product

What?

Conceptual

Who?

Organizational

Why?

Motivational

How?

Functional When?

Temporal

Where?

Geographical

How Much?

Quantitative

www.danradoiu.ro 10

Page 11: Agile requirements engineering

In every job that must be done,

there is an element of fun.

You find the fun, and - SNAP - the

job's a game!

- Mary Poppins, A Spoonful Of Sugar -

www.danradoiu.ro 11

Page 12: Agile requirements engineering

A little customization…

How did you get the idea?

How will a success story

(the perfect one, if it’s possible),

will unfold in your case?

What?

Conceptual

www.danradoiu.ro 12

Page 13: Agile requirements engineering

Invoice you or being

invoiced by you

The City Hall,

Governmental

Institutions etc.

A little customization…

Who are they? Those entities that will:

Give you different permits

and approvals

Keep the system

running

Use the product

Invest their money

Try to make you fail

Who?

People and Organizations

Customers

Investors

Competition

Commercial

Partners

IT Ops

www.danradoiu.ro 13

Page 14: Agile requirements engineering

A little customization…

What do they need?

Things that can be acted upon (real-life objects,

services, functionalities).

For what purpose?

Motivations attached to these real-life objects, services,

functionalities.

Who?

People and Organizations

Why?

Motivational

www.danradoiu.ro 14

Page 15: Agile requirements engineering

Dig beyond the surface

Don’t take the first given reason. Look for something meaningful for the business.

The marketing manager needs a sales report.

Why?

To see the sales figures.

To what end?

To check if the company products are in demand.

And then?

If necessary, to initiate corrective measures (as marketing campaigns).

Why?

Motivational

www.danradoiu.ro 15

Page 16: Agile requirements engineering

All of them in one place

After collecting their needs and whys, we need to see if

the envisioned functionalities satisfy them.

www.danradoiu.ro 16

Page 17: Agile requirements engineering

A little customization…

How will the envisioned product fulfill their needs?

A clickable Happy-Path.

Navigational and UI Mockups.

How?

Functional

Main Page Inbox Login

Editing Message

Viewing Message

Deleting

Message

Warning

Compose

Delete message

View Message

www.danradoiu.ro 17

Page 18: Agile requirements engineering

A little customization…

Take a look to a real calendar to identify those special

days or periods in the product lifecycle.

And then, go deeper: When is the most busy hour of the day,

day of the week, period of the month for a product of this

kind?

When?

Temporal

www.danradoiu.ro 18

Page 19: Agile requirements engineering

A little customization…

What are those physical places that your product will

impact (or be impacted by)?

Accessed, administered, attacked from? Hosted where?

Backups stored in? Delivered at?

What about in five years from now?

Where?

Geographical

www.danradoiu.ro 19

Page 20: Agile requirements engineering

A little customization…

Now, let’s go back and challenge, from a quantitative point

of view, every answer we have received so far.

Only one portal? What it should happen in order to have two

portals?

One portal administrator? What if he gets stranded on a

tropical island, without any internet connection?

How many visitors (at minimum) per month

to keep de business running?

How Much?

Quantitative

www.danradoiu.ro 20

Page 21: Agile requirements engineering

The Now, the Work and the Goal

The Goal The "Now" The Work

Who offers the

same services now?

Who is going to work

in this project?

Who is going to use

the product?

www.danradoiu.ro 21

Page 22: Agile requirements engineering

Let's try a clickable mockup

Microsoft Word, the simplest tool to build a navigational

mockup.

www.danradoiu.ro 22

Page 23: Agile requirements engineering

Don’t forget, gathering

requirements for a product means

more than identifying its

functionalities!

www.danradoiu.ro 23

Page 24: Agile requirements engineering

F.U.R.P.S.

An acronym representing a model for classifying software quality attributes (functional and non-functional requirements):

Functionality - Feature set, Capabilities, Generality, Security.

Usability - Human factors, Aesthetics, Consistency, Documentation.

Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure.

Performance - Speed, Efficiency, Resource consumption, Throughput, Response time.

Scalability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability.

www.danradoiu.ro 24

Page 25: Agile requirements engineering

User Stories and Usage Scenarios

User Story:

A user story is a very high-level definition of a requirement,

containing just enough information so that the developers can

produce a reasonable estimate of the effort to implement it.

As a <role>, I want to <functionality>, so that I can <benefit>.

Usage Scenario:

It details a User Story, providing the necessary details for

certain situations that require so.

Given <situation>, when <event or trigger>, then <action>.

www.danradoiu.ro 25

Page 26: Agile requirements engineering

A piece of reality

www.danradoiu.ro

As a visitor I want to login so that I can access my Inbox

Given the user is authenticated,

When dials www.gulliver-e.com, Then he gets redirected to the Inbox Page.

Given the visitor is not an authenticated user,

When the visitor dials www.gulliver-e.com, Then this page is displayed.

When the visitor tries to access a member-only page, Then he gets

redirected to the Main Page.

Given the visitor entered three times in a row wrong

credentials,

When he tries for the fourth time, Then a Captcha is added to the page (to

avoid bots).

26

Page 27: Agile requirements engineering

And now, some questions for your answers

… or is the other way around? :)

www.danradoiu.ro 27