capturing early requirements for...
TRANSCRIPT
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)
Mission statement, goals
ReqtsSpecification
WHY ?
WHAT ?
Goal operationalisation
Goal Oriented RE (GORE)
Transport passengers safely
Keep doors closed while moving
Model objects (doors), events(start train),constraints(unblock doors onlyat stop)
Train transportation system
Mission statement, goals
ReqtsSpecification
WHY ?
WHAT ?
Goal operationalisation
Goal Oriented RE (GORE)
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
Mission statement, goals
ReqtsSpecification
WHY ?
WHAT ?
Goal operationalisation
Goal Oriented RE (GORE)
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 RE (GORE)
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
Basics of Goal Modeling
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
Basics of Goal Modeling
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
Basics of Goal Modeling
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!!
Basics of Goal Modeling
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;
…