1. Modeling challenges: Model consistency (1) Dealing with inconsistent requirements models/specifications: –Caused by multiple sets of stakeholders (saying contradictory things) –Caused by intrinsic contradictions within stakeholder viewpoints –Caused by the (occasionally) competing pulls of functional and non-functional requirements. Managing requirements evolution –Caused by changing problem domains –Caused by stakeholders changing their minds Dealing with non-functional requirements Inconsistencies may arise within sets of functional requirements and between functional and non-functional requirements

2. Types of inconsistency Semantic vs syntactic Intra-model vs inter-model Consistency conditions: –The existence of a model in the semantic domain (e.g., “can a sequence of message exchanges exist that conforms to this UML sequence diagram”?) –The satisfaction of a set of consistency rules (example below)

3. Inconsistency: Functional requirements (1/2)

4. Inconsistency: Functional requirements (2/2)

5. Inconsistency: Non-functional requirements (1/2)

6. Goals Maintain[SecureAccessPatientRecords] and Maintain[FastAccessPatientRecords] are inconsistent

7. Inconsistency in UML sequence diagrams (1/2) Call() Respond() What’s up?() Give mtg details() [for all participants] *Remind() Prompt() Show schedule() [decision=OK] ScheduleOK’ed() Initiator :Person Participant :Person [for all participants] *Inform() Staff :Person Scheduler :Person [for all participants] *Inform() Acknowledge() Time Acknowledge

8. A consistency rule A semantic consistency rule: An acknowledgement cannot be sent without a preceding message The sequence diagram on the previous slide violates this. The following slide displays a simple resolution of this inconsistency

9. Inconsistency in UML sequence diagrams (1/2) Call() Respond() What’s up?() Give mtg details() [for all participants] *Inform() [for all participants] *Remind() Prompt() Show schedule() [decision=OK] ScheduleOK’ed() Initiator :Person Participant :Person [for all participants] *Inform() Staff :Person Scheduler :Person Acknowledge() Time

10. Exercise Draw an i* model (an SD model + an SR model) that contains semantic inconsistencies (within each model) How would you resolve these? Modify this example to show an instance of inconsistency between an SD model and an SR model

11. Modeling challenges: Model consistency (2) The ideal specification Must tolerate inconsistencies Must support a domain-independent facility to make explicit the trade- offs involved when requirements must be discarded to make a specification consistent. Must support the distinction between essential and tentative requirements. Must make explicit the connection between a requirement and the conditions/assumptions/justification s that its satisfaction is contingent on. Must include some abstractions of system behaviour to enable analysis of boundary conditions (states of the environment/system behaviour that make otherwise consistent requirements inconsistent)

12. Exercise How would you modify the i* notation to address some of the issues in the previous slide?

13. Modeling challenges: Completeness How can we tell whether a requirements model/specification says all the things that it needs to say? How much information must a model contain?

14. Strategies for completeness checking Check completeness with respect to a vocabulary –Consider a requirements specification in propositional logic: (p  q). Given a vocabulary {p, q, r} we may deem the spec. to be incomplete (because it does not refer to r. The spec.: (p  q  r) may also be viewed as incomplete with respect to this vocabulary because it makes no commitment to the truth value of p, q or r. –The vocabulary can often be obtained from a domain ontology. Check completeness with respect to other models –Does the class diagram describe all of the objects described in the sequence diagram?

15. Exercise Devise an appropriate vocabulary (ontology) for the TRMCS domain, and assess the completeness of your i* models. Can you use an SD model as a completeness yardstick for an SR model and vice versa?

16. Modeling challenges: Change management The ideal evolution management tool: Must respond to a repertoire of change requests: add a requirement, remove a requirement, modify a requirement Must ensure that evolution steps involve minimal change to specifications. Must ``discard" requirements only after rigorous trade- off analysis (which would weigh the cost of discarding the requirement against the cost of ignoring the change request) Must never really ``discard" requirements, but must retain them in a background store in anticipation of future reuse. Must support a deferred commitment strategy, i.e., it must delay as much as possible any commitment to an outcome of the change process (since premature choices might turn out to be poor ones given new information)

17. 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

18. 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?