Managing Knowledge for Business Analysts: The Executive Information Portal

1
Dynamically Evolving Requirements
John Mylopoulos University of Toronto/Trento N
SF Workshop on Design Requirements Case Western
Reserve University June 3-6, 2007
2
Dynamically Evolving Requirements

• It is well-documented that "changing
  requirements" constitute a major cause for
  software development failures.
• But these usually refer to design-time changes
  caused by stakeholder indecision/ignorance/disagre
  ement.
• There is an equally important and harder/costlier
  problem to address in run-time requirements
  changes, I.e., changes that occur after the
  system is deployed.
• Little attention has been paid to this problem,
  though things are changing thanks to growing
  interest in autonomic/adaptive/ software.

3
Towards a Research Agenda

• Simple idea characterize classes of changes on
  the basis of their source, develop specialized
  techniques for dealing with each class.
• Example Consider requirements derived from
  regulatory changes (new/different laws)
• Develop techniques for generating requirements
  from regulations
• Hopefully, these requirements have some common
  features that enable us to develop generic
  techniques for dealing with them by (a)
  reengineering an operational system, OR (b)
  having the system adapt to a new behaviour.

4
Obstacle

• The very nature of requirements is changing too.
  Consider
• Traditional view There are functional and
  non-functional requirements.
• Post-GORE view
• The problem Design a specification that will
  satisfy requirements when domain properties hold.
• (Credits to Steve Easterbrook for content and
  artistic merit)

5
Futuristic View of Requirements

• Hard requirements Goals, Global Constraints
• Preferences
• Goals -- Would like to visit Montreal
• Constraints -- Prefer to travel on a Tuesday
• Soft constraints -- Prefer to travel as close as
  possible to a Tuesday
• Criteria/Softgoals -- satisficed through design
  decisions
• Priorities on preferences
• Now the problem is Design a specification that
  will satisfy hard requirements and "do best" wrt
  preferences.
• Then changes can be classified according to this
  ontology and techniques can be developed for
  dealing with each class.
• Assumption Hard requirements are stable,
  preferences change often, priorities change very
  often.