RequirementsDriven Information System Engineering

1
Requirements-DrivenInformation System Engineering
John Mylopoulos University of Toronto Workshop
on Agent-Based Information Systems Conference on
Advanced Information Systems Engineering
(CAiSE99) Heidelberg, June 14-15 1999
2
Abstract

• Information Systems Engineering has traditionally
  been implementation-driven in the sense that the
  programming paradigm of the day (structured
  programming, object-oriented programming)
  dictated the design and requirements analysis
  techniques widely used (structured analysis and
  design, object-oriented analysis and design).
• We speculate on what an information systems
  engineering methodology might look like if it was
  founded on early requirements analysis
  techniques. For our purposes, we adopt i as
  modeling framework. i supports concepts such as
  those of actor, agent, position and role, also
  resource, task and goal dependencies among
  actors. The presentation suggests elements of
  late requirements analysis, architectural and
  detailed design through examples, and notes a
  number of areas where such a methodology might
  break new ground with respect to traditional
  information systems engineering, as well as
  agent-oriented programming.

3
Information System Engineering

• Information System (hereafter IS) Engineering is
  concerned with concepts, tools and methods for
  building information systems.
• Traditionally, IS Engineering has been
  implementation-driven.
• This means that the programming paradigm of the
  day dictated the design and requirements
  paradigms.
• So, structured programming led to structured
  design and (requirements) analysis, while
  object-oriented programming led to
  object-oriented design and analysis.
• Aligning the paradigms used for requirements,
  design and implementation makes perfect sense.
  But why start with implementation?
• What would requirements-driven
• IS Engineering look like??

4
Why Requirements-Driven?

• Requirements analysis is arguably the most
  important phase of information system
  development thats where the most and the
  costliest errors are introduced in software
  systems.
• The importance of detailed design and
  implementation will wear off over time, thanks to
  software reuse, COTS and the like requirements
  analysis will always be there and will always be
  important.
• Requirements analysis is the phase where
  technology meets the real world, where technical
  considerations have to be balanced against
  personal, organizational and social ones this
  calls for special skills on the part of the
  requirements engineer, and makes the phase
  particularly challenging.

5
Requirements Analysis

• ...Requirements Engineering is the branch of
  systems engineering concerned with real-world
  goals for, services provided by, and constraints
  on software systems. Requirements Engineering is
  also concerned with the relationship of these
  factors to precise specifications of system
  behaviour and to their evolution over time and
  across system families... Zave94
• This activity traditionally boils down to three
  tasks
• Context analysis -- the reasons why the system is
  to be created and why certain technical
  operational and economic feasibilities are the
  criteria that form boundary conditions for the
  system
• Functional requirements -- what will the system
  is to do
• Non-functional (quality) requirements -- global
  constraints on how the system is to be
  constructed and function

6
Early vs Late Requirements

• We need to distinguish between early phases of
  requirements analysis, when the analyst is trying
  to understand an organizational setting, from
  late phases when the analyst formulates a solution

Organization
Organizational model
Requirements
Contractual requirements
System
7
Early vs Late Requirements

• Early requirements amount to the definition of a
  search space (scoping) and a search among
  alternatives within that space.
• Late requirements amount to refining,
  disambiguating and completing the description of
  the chosen alternative.
• Structured and object-oriented analyses are OK
  for late requirements.
• Goal-oriented analysis is more appropriate for
  early requirements analysis because it focuses on
  the definition and exploration of a space of
  alternatives

8
Goal-Oriented Analysis

• Goal-oriented analysis focuses on early
  requirements phases, when alternatives are being
  explored and evaluated.
• During goal-oriented analysis, we start with
  initial goals such as Higher profits, Faster
  time-to-market, Schedule meeting, Easily
  maintainable system, Good performance etc. and
  keep decomposing them until we have reduced them
  to alternative collections of design decisions
  each of which can satisfy the initial goals.
• Initial goals may be organization- or
  system-oriented they may also be contradictory,
  so the analysis must facilitate the discovery of
  tradeoffs and the search of the full space of
  alternatives, rather than a subset.

9
Goal-Oriented Analysis is not New!

• Specification of composite systems -- Feather87
  
• Goal-oriented elaboration of requirements --
  ALBERT Dubois94
• Goal-oriented requirements acquisition -- KAOS
  Dardenne93
• Knowledge representation and reasoning in the
  design of composite systems -- Critter Fickas92
• Goal-oriented requirements analysis -- Potts,
  Anton
• I and Non-Functional Requirements framework --
  Yu, Chung
• NATURE -- Jarke93
• F3 -- Bubenko93
• ...and many others...

10
The i Framework
Maximize profits
Insurance Company
Customer
Settle claim
Car repaired
Customer happy
Goals are relative, fulfillment is collaborative
11
Means-Ends Analysis
Handle claim
Verify policy
Claims Handling
Settle claim
Prepare offer
Settlement cost?
Whose fault?
Determine fault
Get accident info
Actor boundary
Determine cost to settle
D
D
Minimal repairs
D
D
Accident info
Sufficient treatment
D
Injury info
Police
Appraise damage
Doctor
Appraiser
Witness
12
Strategic Dependency Models
Claims payout
Car repaired
D
D
D
D
Premium payment
D
Pay repairs
D
Insurance Company
D
D
Repairs covered
D
Body Shop
D
Owner
D
Maximize estimate
D
D
D
D
Customer happy
D
D
Appraise damages
D
D
Minimize repairs
Continue business
D
Secure employment
Fair repair appraisal
D
D
Goal
Resource
Appraiser
Task
Softgoal
13
Where Are We??
Agent-oriented programming
i
KAOS
Z
UML
Detailed design
Early requirements
Architectural design
Late requirements
Implementation
14
Where Do We Want To Be??
Agent-oriented programming
i
Detailed design
Architectural design
Late requirements
Early requirements
Implementation
Guiding Principle Push concepts as far down as
possible (and see what happens!)
15
Late Requirements with i

• The system is now represented as one or more
  actors which participate in a strategic
  dependency model.
• Resource, task and softgoal dependencies
  correspond naturally to functional and
  non-functional requirements.
• Leaving (some) goal dependencies between software
  system actors and other actors is a novelty.
  Traditionally, functional goals are
  operationalized during late requirements, and
  quality softgoals are either operationalized or
  metricized.
• Leaving goal dependencies with system actors as
  dependees makes sense whenever there is a
  foreseeable need for flexibility in the
  performance of a task on the part of the system.

16
The System as a Cluster of Actors
Troubleshooting done
D
D
Claims manager
System
Information
Insurance company
D
D
Reporting actor
Tracking actor
D
D
Information
17
Goals Mean Flexibility

• Consider a goal laid out during early
  requirements communicate(x,y).
• Conventionally, such goals are operationalized
  during late requirements into constraints for
  the system-to-be, such as having a user
  interface, also supporting a dialogue during
  which information x is communicated to person y.
• Such operationalizations lead to fragile
  systems what if y doesnt engage in dialogue
  with the system? y doesnt understand the
  message? the system crashes during the
  dialogue? etc.
• Leaving the communication goal as part of the
  late requirements spec, or even the design means
  that the system-to-be will be designed with
  several alternative strategies for satisfying the
  goal, including getting help from outside

D
D
Customer
Reporting actor
Communicate(x)
18
Architectural Design with i

• Now we focus on actors that are part of the
  system.
• Add actors, in addition to those inherited from
  requirements to meet the obligations of existing
  (system) actors.
• Decide whether actors will be agents, positions,
  or roles.
• Actor lt-gt agent if the fulfillment of its
  obligations requires unique skills (e.g.,
  troubleshooting).
• Actor lt-gt position if there are generic agents
  which have suitable skills for example,
  information management might use a DBMS agent,
  tracking might employ () a workflow agent.
• Actor lt-gt role if another actor (agent, position)
  within the system has the skills to meet assigned
  obligation for example, a DBMS agent holding an
  information management position can play the role
  of information provider for a particular project

19
Architectural Design with i
Claims manager
D
Clerk
Information
D
D
Information
Information
D
D
D
Interface manager
D
D
Reporting actor
D
Transformer
Tracking actor
D
D
Information
20
Actor Assignments
agent
ContributeToMtg
assignedTo
Sally
Initiator
role
UsefulMtg
ScheduledMtg
CalendarInfo
Scheduler
Participant
assignedTo
assignedTo
AttendMtg
Michael
DeptChair
SuitableTime
position
21
Detailed Design

• The skills of all actors and their input/output
  data are refined using some specification
  technique.
• Agent infrastructure is defined, including
  communication and collaboration protocols.
• Infrastructure actors are introduced, such as
• Hiring actors, i.e., ones for filling positions
• Headhunters, i.e., actors who look for agents to
  fill positions at run time
• Dependency managers who supervise dependencies
  and determine whether they remain viable.

22
Implementation with i

• Agents are implemented.
• Implement positions and roles, given assigned
  agents.
• If there are dangling goal dependencies, build
  into the responsible agent skills for meeting
  these goals.
• E.g., a communication goal might be met through
  repeated email, asking a third party to
  communicate etc.
• If there are dangling softgoal dependencies,
  build into the responsible agent skills for
  addressing such softgoals.
• E.g., a security agent would have a number of
  ways of meeting security goals

23
Forms of Analysis

• Each IS development paradigm encourages different
  types of analysis. Structured techniques focused
  on information transformations, OO ones on types
  of information and the behaviours of each type.
• Actor-oriented techniques encourage answers to
  the following questions
• Who are the relevant actors and what are their
  goals?
• Who can satisfy/satisfice a goal/softgoal?
• How do we establish an obligation for an actor to
  deliver on a dependence?
• Does this process have the right effects?
• more...

24
Remarks

• There are three mechanisms that are interesting
  here from a Information Systems perspective
• Goals stay around until after early requirements
  and as long as run-time
• Position and role filling may take place
  somewhere between architectural design and
  run-time
• Dependencies may be created during requirements
  analysis and design time, or at run-time, and
  they need to be managed.
• None of these is novel to agent programming what
  is novel from that perspective is the idea that
  these mechanisms may be exploited during early
  phases of software development to offer a whole
  new dimension to agent-based system design.

25
Conclusions

• From an Information Systems perspective, this
  proposal, however speculative, has advantages
• Leads to more flexible, robust and open
  architectures
• Offers a coherent framework which encompasses all
  phases of software development, from early
  requirements to implementation
• Is consistent with the next generation
  programming paradigm.
• As well, from an Agent-Based Systems perspective
  the proposal
• Suggests a comprehensive methodology for building
  software
• Offers a new dimension along which one decides
  flexibilityrobustness vs performance tradeoffs.
• BUT,all this is just a proposal, which needs to
  be validated and elaborated by research.

26
So

• Agent-Oriented Information Systems
• is the solution to
• Requirements-Driven
• Information Systems Engineering

27
References

• Yu94 Yu, E., Modelling Strategic Relationships
  for Process Reengineering, PhD thesis, Department
  of Computer Science, University of Toronto,
  December 1994.