Capturing Early Requirements for Servicestest.hua.gr/dit/...Capturing_Early_Requirements_for_Services-_Part_I.pdf · and management explain more than 50% of project failures ... what

Colette RollandUniversité de Paris1 Sorbonne

Capturing Early Requirements for Services

Use services as fundamental elements

Reorganize a portfolio of legacy applications into self-describing,

platform agnostic computational elements (services) , accessible through

standard interfaces and that can be assembled together

Based on an interaction between three kinds of software agents

SOC/SOA Goodies….

Objectives & goals

Client

High-level service descriptions

Business requirements and goal oriented

Software Service

Intentional Level

Operational Level

Low level descriptionsFunctionality-oriented

Software vision

Service clientFind

Bind

Service registry

Publish

I-Service provider

And Limitations….

Conceptual mismatch

Objectives & goals

Client

High-level service descriptions

Business requirements and goal oriented

Software Service

Intentional Level

Operational Level

Low level descriptionsFunctionality-oriented

Software vision

Match High level viewof services

Early rqts forservices

Abstraction

Service clientFind

Bind

Service registry

Publish

I-Service provider

Attempt to Overcoming Limitations….

Conceptual mismatch

An e-government example: virtual e-Pension

Virtual e-Pensionorganization

An E-Government service

An efficient E-Government service requires acompromise between conflicting stakeholders objectivesto be found and a cooperative process to be developed

Local HealthAuthority

Disabled person

City Hall

Prefecture

• Goal Oriented Requirements Engineering (GORE)

• Modelling early requirements for services in MAPs

Outline

Capturing Early Requirements for Services

Evidences: Poor requirements capture, specification

and management explain more than 50% of project failures

Questioning the appropriateness of models: All engineeringdisciplines use models to support the systematic design ofartifacts. Software Engineering has come to adopt a model-driven view of software development (focus on UML,MDA,MDE). But, are these models the right ones?

The roots for GORE approaches

Object-Oriented Software Development

Initiator Participant

ScheduleMtg

ValidateUser

EditConstraints

ProvideConstraintsWithdraw

<<extends>>

<<uses>>

Personnameemail

0..1

0..*1

has

Meetingtimeplace

attends

RequestedMtg

Timetable

initiates

2..*

1

0..*

MtgRequirement0..*

ScheduledMtg initiator

has0..*

1

initiator:Person

staff:Person

participant:Person

scheduler:Person

1:giveDetails()8:approveSchedule()

2:inform()4:remind()9:inform()

3:acknowledge()5:sendDetails()

6:prompt()

7:sendSchedule()

Evidences: Poor requirements capture, specification

and management explain more than 50% of project failures

Questioning the appropriateness of models: All engineeringdisciplines use models to support the systematic design ofartifacts. Software Engineering has come to adopt a model-driven view of software development (focus on UML,MDA,MDE). But, are these models the right ones?

Wrong focus: conceptual modeling focusses on the WHAT

question (What the system must do?) and not enough on the

WHY question (the motivations & needs for the system)

The roots for GORE approaches

GORE focus:Towards Engineering Purposeful Systems

Understanding the purpose of the system To-Be

Capturing relevant aspects of some excerpt of the world in a model

From Function

To Intention

Mission statement, goals

RequirementsSpecification

WHY ?

WHAT ?

The RequirementsEngineering processGoal

operationalisation

Goal Oriented RE (GORE)


ReqtsSpecification

WHY ?

WHAT ?

Goal operationalisation


Transport passengers safely

Keep doors closed while moving

Model objects (doors), events(start train),constraints(unblock doors onlyat stop)

Train transportation system


ReqtsSpecification

WHY ?

WHAT ?



Automate bookingpromote loyalty

Customize booking serviceReward loyalty

Model rooms & their availabilityCumulate loyalty points

Hotel Room Booking systemUse full hotel capacityCustomers come again & again

Repeat previous booking


ReqtsSpecification

WHY ?

WHAT ?



Automate booking with minimal cost & services

Simplify booking procedure(no waiting list)

Maintain availability at hotel level

Hotel Room Booking system

Model Hotel class only (no room)

Use full hotel capacityOcasional customers

Focusing on the WHAT question poses problems :

Tackling the WHY question shall help understanding the right requirements and gives hope for more purposeful systems

to be developed

High concentration on the software functionality

specification and not enough on its rationale


Goal-oriented analysis focuses on earlyrequirements, when problems ( = stakeholderneeds) are identified, and alternative solutionsare explored and evaluated

During goal-oriented analysis, we start withinitial stakeholder goals such as “Fulfill everybook request”, or “Schedule meeting” and keeprefining them until we have reduced them toalternative collections of specifications (laterequirements) each of which can satisfy theinitial goals

Initial goals may be contradictory and may notbe defined.

Goal Oriented RE

Goals are optative statements (as opposed to descriptive), (Jackson95), expressions of intents

Ex : Transport passengers safely

Ensure customer loyalty

Basics of Goal Modeling

Goals have useful characteristics

Avoid to deal with details and help focusing of the essentials

Example : ELEKTRA project175 processes and 100kgs of paper models

250 goals in A3 format page

• functional goals (hard goals) : what the system is expected to do

• non-functional goals (soft goals) : quality of the system behavioursecurity, safety, accuracy,performance, cost, usability, adaptability,

Goals cover different types of concerns

Ubiquitous cash serviceprovidedCard kept after 3 wrong pin code entries

Serve customer quickly

Pop up windowin less than 1/2 sec

Help eliciting functional and non functional requirements


Increase the number ofcontracts by 20%

Diversify the number ofways of making offers

With a pull

strategyDirectly to the clientby Internet

MakeOffer

Through thecar vendor

Goals are expressed at different levels of abstractionHigh level,strategic,

organisation wise

Low level,tactic,

design specific

Help aligning strategy, tactics and system requirements

Ubiquitous cash serviceprovidedEnsure customer loyaltyTransport passengers safely

Card kept after 3 wrong pin code entriesKeep doors closewhen moving


Satisfy bookrequest

Provide long borrowing period

Satisfy bibliographyrequest

Manage lending books

Manage borrowership

Guarantee borrower privacy

Satisfy borrower request

Timely Mangtof loan

AND

Maintainregular

availability

Maintainas many copies

as needed

OR

• Goals provide rich structuring mechanism (AND/OR reduction)

Goals drive the RE process


Goals are roots for conflict detection & resolution

Satisfy bookrequest

Provide long borrowing period

Satisfy bibliographyrequest

Maintainregular

availability

Maintainas many copies

as needed

Satisfycustomer

request

Conflict!!


Schedulemeeting

Chooseschedule

By Person

Collecttimetables

Automatically

ManuallyCollect from usersCollect from

agents

Receiverequest

Send request

AND AND

AND AND

OR OR

OR ORBy

System

OR OR

Collect Schedule

tasks/requirements

(Functional/hard)Goals

Goal reduction leads to requirements through exploration of alternatives

As-Is Goals To-Be Goals

Current system &processes

To-Be system &

processes

AbstractingIntentional level

Operational Level

Operationalizing

By abstractingfrom the current system (earlyreqs)

Avoiding/ reducing problems & deficiencies

By refinementfrom scenarios,obstacles &conflicts (late

reqts)

Understandingneeds forchange

Bottom-up(why)

Top-down(how)

Approaches to Goal Modeling

• There are many different ways to elicit goals

A French group of ski resorts hotel managers decided to enter in a partnership and chose theColette’s students group in UP1 to develop their computerised reservation system. These are theirinitial recommendations :

The system shall treat customer requests as automatically as possible. Any request is made byeither an already known customer or by a fresh new prospect. The customer is identified by his Idwhereas personal data (name, address and telephone number) shall be captured for a prospect.The request is set in general terms : the requested hotel category, the number of rooms neededand the period that the person requests. A request relates to one single period but one or severalrooms. The stakeholders would like to make happy as many customers as possible and thereforeask you to develop a functionality for managing pending requests in an automatic way : a requestthat cannot be satisfied immediately shall be put in a waiting list and piled down as soon aspossible. When a request has been accepted, a corresponding reservation is created and related tothe customer data. If the customer cancels her reservation less than 8 days before the starting dateof the reservation, she is charged 50% of the full reservation price.Obviously, the system shall memorise information about hotels such as name, code, category,rooms, ground & mail address, and telephone number.

Room booking case study

Use hotels full capacity

Delegate to CRS generation ofbooking Develop

customer loyalty

Respond to bookingrequest

Ensure equityamong hotels

Offer waitinglist

Maintain resourcesstatus over time

By customer By system

Offerbooking

‘matching’ similar customised

Maintainbookings overtime

R1.1 R1.2R1.3

R1.4 R2

R4

R3

1

2

2

33

4’

4

4’

5

5 5

5Customisebooking service

By preferencesBy repeating

5

R5

R8

R7

5

5’ 5’

R1 : Respond to requester demands automatically and in real time : R1.1 : by generating a booking matching the demand, R1.2 : by proposing a similar booking but not exactly matching R1.4 : offering insertion in waiting list, R1.3 : by proposing a personalized booking. R2 : pile down the waiting list asap. R3 : Ensure equity in the distribution of bookings among hotels of the

pool . R4 : Take cancellation demands into account and invoice late

cancellations (less than 8 days) by 50% of amount R5 : Take anticipated departure or ‘no show’ into account. R7 : Keep track of bookings and their evaluations in an historical

mode. R8 : offer the same booking as in the past (if positive evaluation of the

stay).

Case study: requirements (1)

Use hotels full capacity

Delegate to CRS generation Of booking

Developcustomer loyalty

At roomlevel

Maintain resourcesstatus over time

Maintainroom availability

Update hotelinformation

At hotel level

With privileges

R6

1

3

68

Rewarding loyalty

With prospectWith client

5

R13

6

7 7R9

Keepcontact

By measuring

Byupgrading

Bypriority

R10

8

9 9

99

10 10

R11 R12

R1 : Respond to requester demands automatically and in real time :R1.1 : by generating a booking matching the demand, R1.2 : by proposing a similar booking but not exactly matchingR1.4 : offering insertion in waiting list,R1.3 : by proposing a personalized booking.R2 : pile down the waiting list asap.R3 : Ensure equity in the distribution of bookings among hotels of the pool .R4 : Take cancellation demands into account and invoice late cancellations (less than 8 days) by 50% of amount R5 : Take anticipated departure or ‘no show’ into account.

R6 : Maintain room availabilities accurately and timely.R7 : Keep track of bookings and their evaluations in an historical mode.R8 : offer the same booking as in the past (if positive evaluation of the stay). R9 : Maintain information about hotels accurately and in real time.R10 : Install a loyalty point based system :R10-1 register loyalty levels R10-2 register the credit/debit formula R11 : Upgrade/propose upgrade to a loyal customer demand that cannot be treated instantaneously else prioritize on waiting listR12 : Give/withdraw points to loyal customers for any booking/upgradeR13 : Maintain information on customers and prospects

Case study: requirements (2)

Soft Goals for Dealing with non-functional requirements

Programmability

+

+

++SupportChange of

ColorsSupport

Change ofState

SupportChange ofLanguage

ErrorAvoidance

InformationSharing

Ease of Learning

User Tailorability

Usability

Allow User-Defined Writing Tool

Modularity

UseComponents

UserFlexibility

Allow Change ofSettings

+

+

+

ANDAND ANDAND

ANDAND

Change color Change

stateChange language

Schedule meeting

Collect timetables

Choose schedule

By Person By System

Manually Automatically

Minimal effort

Collection effort

Matching effort

Good quality schedule

Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

Evaluatingalternatives with softgoals

Y requirements elicitation

Y exploration of system choices

Y requirements completeness

Y requirements pre-traceability

Y detection & resolution of conflicts

Y documentation

Y negotiation

Y evolution & change

Goals proved to play useful roles in RE

Contributing to the purposefulness of systems

Basics of goal modeling

Credits

Many other researchers worked with goals adecade ago, including:

– Martin Feather and Steve Fickas;

– Axel van Lamsweerde et al;

– Colin Potts and Annie Anton;

– Janis Bubenko;

– John Mylopoulos & team;

– Periklis Loucopoulos and Evangelia Kavakli;

– Klaus Pohl, Matthias Jarke;

…

Documents

Capturing Early Requirements for Servicestest.hua.gr/dit/...Capturing_Early_Requirements_for_Services-_Part_I.pdf · and management explain more than 50% of project failures ... what