1. Advance Information Systems Development (SD3043) Lecture 3: Requirements Elicitation / Analysis/Design Dr. Haris Mouratidis haris@uel.ac.uk 10 th October 2006

2. © H. Mouratidis 20062 Last Week Notation An introduction to the Unified Modeling Language (UML) An overview of UML Use Case Diagrams Class Diagrams Interaction diagrams Statechart Diagrams Activity Diagrams

3. © H. Mouratidis 20063 Learning Objectives At the end of the lecture students will be able to: Understand the concepts related to requirements elicitation/analysis/design Understand the activities involved during requirements elicitation, analysis and design stages Understand the difference between analysis and desing models

4. © H. Mouratidis 20064 Lecture Layout Software Lifecycle Requirements Engineering Requirements Elicitation Activities, Scenarios Requirements Analysis models Design Refinement of analysis Conclusions

5. © H. Mouratidis 20065 Software Lifecycle Different activities necessary to develop a software system Lifecycle model represents all these activities and the relationships to each other The main activities are: (Software Specification) Requirement Engineering Software Design Software Implementation Software Testing (validation) Software Evolution

6. © H. Mouratidis 20066 Object Oriented Software Engineering activities Application Domain Objects SubSystems class... Solution Domain Objects Source Code Test Cases ? Expressed in Terms Of Structured By Implemented By Realized By Verified By System Design Object Design Implemen- tation Testing class.... ? Requirements Elicitation Use Case Model Requirements Analysis Requirements EngineeringDesign

7. © H. Mouratidis 20067 Requirements Engineering Requirements Analysis system specification analysis model Problem Statement Generation Requirements Elicitation Problem Statement

8. © H. Mouratidis 20068 Requirements Elicitation Process of deriving the system requirements Results in a specification of a system that the client understand Very challenging activity Requires collaboration of people with different backgrounds Users with application domain knowledge Developers with solution domain knowledge (design knowledge, implementation knowledge)

9. © H. Mouratidis 20069 Requirements Elicitation concepts Requirements have to be validated Completeness All possible scenarios are described Consistency Does not contradict itself Clarity It is unambiguous Correctness It represents accurately the system to be Realistic, verifiable, traceable

10. © H. Mouratidis 200610 Requirements Elicitation Activities Identifying actors Identifying scenarios Identifying use cases Refining use cases Identifying relationships among use cases Identifying non functional requirements

11. © H. Mouratidis 200611 Identifying actors It is not easy, especially in initial stages Database Define the system boundary Useful questions Which user groups are supported by the system to perform their work? Which user groups execute main, secondary functions of the system? What other systems interact with this system?

12. © H. Mouratidis 200612 Identifying Scenarios “Narrative description of what people do and experience as they try to make use of computer systems and applications” [Carroll, 1995] Informal description of a single feature of the system used by a single actor Do not replace use cases (complementary) Focus on specific instance Describe the outcome of a decision Two scenarios

13. © H. Mouratidis 200613 Types of scenarios As-is scenarios Used to describe the current situation How the current system works? Visionary scenarios Used to describe a future system Usually contribution of both user and developers is needed Evaluation scenarios Used to describe user tasks against which the system can be evaluated Training scenarios Step by step instructions that guide a novice user through a system

14. © H. Mouratidis 200614 Identifying Use Cases A use case specifies all possible scenarios for a given piece of functionality Describe each of these use cases in more detail Participating actors Describe the Entry Condition Describe the Flow of Events Describe the Exit Condition Describe Exceptions Describe Special Requirements (Constraints, Nonfunctional Requirements

15. © H. Mouratidis 200615 Identifying non functional requirements Usability: how easy the system is to operate Conventions adopted by the user interface Reliability Acceptable mean time to failure Performance Response time, availability, accuracy Supportability: how easy is to change the system Adaptability, maintainability Security Security constraints Non-functional requirements often conflict!! Prioritise them

16. © H. Mouratidis 200616 Requirements Analysis Transition between real world and machine world Requirements elicitation is the input Analysis focuses on producing a model of the system Analysis model consistent with requirements Main question to answer: what? What functions must the system perform? Different approaches Structured Object Oriented

17. © H. Mouratidis 200617 Use Case vs Analysis Models (from Jacobson et al., 1999) Use Case Described in the language of the customer External view of the system Structured by use cases Used primarily as a contract between customers and developers May contain redundancies or inconsistencies between requirements Captures System Functionality Defines use cases that are furthered analysed during analysis Analysis Model Described in the language of the developer Internal view of the system Structured by classes and packages Used primarily by developers to understand how to design the system Should not contain inconsistencies or redundancies between requirements Outlines a first-cut design Defines use case realisation

18. © H. Mouratidis 200618 O-O Analysis activities Identify classes Data Driven Responsibility Driven Identify associations aggregates, attributes, inheritance Review the model

19. © H. Mouratidis 200619 Identifying classes Rational Unified Process approach: Entity classes Persistent information tracked by the system Boundary classes Interactions between the actors and the system Control classes Realising use cases

20. © H. Mouratidis 200620 Identifying Entity Classes (Data Driven) Natural language analysis Limitations Depends on the style of writing More nouns than relevant classes Part of speechModel ComponentExamples Proper nounInstanceAlice Common nounClassFieldOfficer Doing verbOperationCreates, selects Being verbInheritanceIs a kind of Having verbAggregationHas, consists of Modal verbConstraintsMust be AdjectiveAttributeIncident description

21. © H. Mouratidis 200621 Identifying Boundary Classes In each use case, each actor interacts with at least one boundary class “translator” between actors and classes Do not describe in detail visual aspects To find boundary classes Identify forms the user needs to enter info into the system Identify messages, notes the system uses to respond to the user Identify user interface controls that the user needs to initiate a use case

22. © H. Mouratidis 200622 Identify Control Classes Coordinate entity and boundary classes They do not have a concrete counterpart in the real world Some useful tips for control classes Identify one control class per use case Identify one control class per actor in the use case The life span of the control class should cover the extend of the use case

23. © H. Mouratidis 200623 Responsibility Driven Identify responsibilities in the system Class, Responsibilities, Collaborators (CRC) cards

24. © H. Mouratidis 200624 Identifying associations Properties Name: describe the association between two classes Role at each end: function of each class multiplicity at each end: number of instances Aggregates composition Attributes Name, type

25. © H. Mouratidis 200625 Reviewing the analysis model Several iterations required Built incrementally and iteratively Any changes should be reflected on the requirements Add/ extend use cases in requirements Two main ways to review the model Checklist Questions

26. © H. Mouratidis 200626 Ensuring the model is correct Is the glossary of objects understandable by the user? Do the classes correspond to user-level concepts? Are all descriptions in accordance with the users’ definitions? Are all error cases described and handled?

27. © H. Mouratidis 200627 Ensuring the model is complete Classes Is it needed by any use case? In which use case it is created? Attributes When is it set? What is its type? Associations Why was the specific multiplicity chosen?

28. © H. Mouratidis 200628 Is the model consistent / realistic? Consistent Are there multiple classes or use cases with the same name? Are there objects with similar attributes and associations that are not in the same generalisation hierarchy? Realistic Any novel features on the system? Feasible? Can all the requirements be met?

29. © H. Mouratidis 200629 System Design 2. System Layers/Partitions Cohesion/Coupling 5. Data 1. Design Goals Definition Trade-offs 4. Hardware/ Special purpose Software Buy or Build Trade-off Allocation Connectivity 3. Concurrency Data structure Persistent Objects Files Databases Management Access control Security 6. Global Resource Handling 8. Boundary Conditions Initialization Termination Failure Decomposition Mapping 7. Software Control Identification of Threads Monolithic Event-Driven Threads Conc. Processes

30. © H. Mouratidis 200630 Using Previous Knowledge Nonfunctional requirements => Activity 1: Design Goals Definition Functional model => Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling) Activity 8: Boundary Conditions Object model => Activity 4: Hardware/software mapping Activity 5: Persistent data management Dynamic model => Activity 3: Concurrency Activity 6: Global resource handling Activity 7: Software control

31. © H. Mouratidis 200631 Decomposition Increasing number of complex systems The best way to deal with it, decompose them Makes development easier, faster Difficult to modify / correct weak decomposition once development has started Software architecture Architectural styles

32. © H. Mouratidis 200632 Basic Decomposition Concepts Subsystem Smaller parts of the system Service Set of related operations that share a common purpose E.g. subsystem to provide notification service: defines operations to send notices Subsystem interface Set of operations of a subsystem that are available to other subsystems

33. © H. Mouratidis 200633 Coupling Number of dependencies between two subsystems Loosely coupled: almost independent Modifications on one have little impact on the other Target: as loosely coupled as possible Minimises the impact that errors or future changes might have It is not easy to reduce coupling Introduce many unnecessary layers

34. © H. Mouratidis 200634 Cohesion Number of dependencies within a subsystem High/low cohesion Target: subsystems with high cohesion Cohesion versus Coupling Increase cohesion by decomposing the system into subsystems Increase coupling

35. © H. Mouratidis 200635 Identify Boundary Conditions How the systems is started, initialised and shut down Define how to deal with major failures (e.g. data corruptions) Boundary use cases Configuration If objects are not created or destroyed in normal use cases Start-up and shutdown Exception handling How the system should react in failures

36. © H. Mouratidis 200636 Object Oriented Design Design Classes are refined versions of the analysis classes Include implementation details Full spec of attributes (visibility, type, etc) Full spec of operations (return type, exceptions, visibility, etc) Full definition of relationships (navigability, etc) Not an 1-to-1 mapping 1 analysis class could result in many design classes

37. © H. Mouratidis 200637 Visibility A mechanism that specifies whether an attribute or an operation can be used by other classes or not. Private Only in the class it is defined Denoted by - Protected In the class it is defined and any descendant of this class Denoted by # Public By any class Denoted by +

38. © H. Mouratidis 200638 Analysis vs Design Class (agilemodeling.com)

39. © H. Mouratidis 200639 Analysis vs Design Class Diagram (Mouratidis, 2005) TournamentControl Player players 1..* Tournament name 1 1 applyForTournament() Match playMove() getScore() matches 1..* start status selectSponsors() advertizeTournament() acceptPlayer() announceTournament() start end 1 1 1..* matches 1..* TournamentForm 1..* acceptPlayer() removePlayer() schedule() Advertiser sponsors1..*

40. © H. Mouratidis 200640 Analysis vs Design Class Diagram (Mouratidis, 2005) TournamentControl Player players 1..* Tournament 1 1 +applyForTournament() Match +playMove(p,m) +getScore():Map matches 1..* +start:Date +status:MatchStatus +name:String +start:Date +end:Date 1 1 1..* matches1..* TournamentForm 1..* +acceptPlayer(p) +removePlayer(p) +schedule() Advertiser sponsors1..* +selectSponsors(advertisers):List +advertizeTournament() +acceptPlayer(p) +announceTournament() +isPlayerOverbooked():boolean

41. © H. Mouratidis 200641 Class Diagram (Booch, 1999)

42. © H. Mouratidis 200642 Object Diagram (Booch, 1999)

43. © H. Mouratidis 200643 Conclusions Software Lifecycle Requirements Engineering Requirements Elicitation Requirements Analysis Reading: Chapters 4, 5 (essential)

44. © H. Mouratidis 200644 Assignment Groups Group members are allocated only by the module team! All group members need to be registered Group members must belong to the same tutorial groups If you have a preference send it by Wednesday the latest You need to do the requirements elicitation and analysis.