Modeling challenges: Compliance (1/2) Compliance management has emerged as a major problem following major corporate governance scandals (e.g. Enron, WorldComm) and the resulting legislation (e.g. Sarbanes-Oxley Act) Cost of compliance management is very high Compliance software industry has become very large Most compliance software products are limited in functionality – primarily focusing on maintaining process transaction logs

Modeling challenges: Compliance (2/2) Compliance can be checked and enforced either at: –Run-time: By blocking non-compliant transactions, for example –Design-time: By checking design-time artefacts for compliance Can requirements models be checked for compliance, thus reducing the risk of implementing non-compliant systems? If found to be non-compliant, how can requirements models be modified to restore compliance?

Modeling challenges: Model transformation (1/2) Different modeling languages offer different sets of representational capabilities (i.e., some are good for representing certain aspects of a problem, others for different aspects and so on) Sometimes, it is useful to transform a model in one notation into a model in another notation to obtain an alternative (and possibly more useful) representation of the same information (e.g.: transforming a UML sequence diagram into a BPMN process model)

Modeling challenges: Model transformation (2/2) Co-evolution of models: Concurrent modelling in multiple notations can exploit the complementary reasoning capabilities of these notations We need to maintain a modicum of loosely-coupled consistency between these models These models can be maintained and updated by independent sets of stakeholders Changes in one model need to be reflected in the other models Consistency preservation during co-evolution involves defining mapping functions between the notations in question

Modeling challenges: Requirements negotiation Stakeholders often disagree over requirements – such disagreements must be resolved to avoid requirements inconsistency Requirements negotiation helps resolve such disagreements Several negotiation models and supporting tools exist, e.g., the WinWin model by Barry Boehm

Modeling challenges: Model merging Models are often specified from distinct viewpoints by distinct stakeholder groups These viewpoints are often conflicting We often need to merge these viewpoints into a single model Solutions: XBEL (based on multi-valued model checking – Chechik and Easterbrook, State View Merge System – Ghose and Lin)

Modeling challenges: Expressive Adequacy (1/4) Context: A requirement only makes sense when viewed within a context Representing the context of a requirement is hard.. –What are the boundaries of the context? –How should we represent the context? –How much detail should we represent? –In what notation?

Modeling challenges: Expressive Adequacy (2/4) Traceability: In an ideal setting, traceability links between artefacts are obtained directly as a consequence of a principled SE methodology that involves progressive refinement of artefacts (early-phase requirements  late-phase requirements  design etc…) In many realistic settings, multiple requirements models are created that offer alternative viewpoints on the same system. Traceability links between these models can be useful, but are hard to come by. Example: –We represent an organizational context in an i* model –We represent some high-level business processes in BPMN –How do we correlate these?

Modeling challenges: Expressive Adequacy (3/4) Rationale: For every requirement, we must be able to answer the why question. This helps us: –Understand the priority of the requirement –Help assess the implications of changing/deleting the requirement Rationale are often answered via reference to goals, to other requirements, or to assertions/assumptions about the domain.

Modeling challenges: Expressive Adequacy (4/4) Non-functional requirements (NFRs) are often vague, referring to qualitative attributes for which there are no crisp measures of achievement. NFRs cannot be represented using the “assertional” style in which functional requirements are represented. Challenges: –How can we model NFRs? –How can we assess NFR “satisfaction”? What does it mean to “satisfy” an NFR? –How can we detect and resolve inconsistencies between NFRs?