Advance Information Systems Development (SD3043) Lecture 3: Requirements Elicitation / Analysis/Design Dr. Haris Mouratidis 10 th October 2006

© H. Mouratidis 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

© H. Mouratidis 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

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

© H. Mouratidis 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

© H. Mouratidis 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

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

© H. Mouratidis 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)

© H. Mouratidis 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

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

© H. Mouratidis 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?

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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?

© H. Mouratidis 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?

© H. Mouratidis 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?

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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

© H. Mouratidis 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 +

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

© H. Mouratidis 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 * matches 1..* TournamentForm 1..* acceptPlayer() removePlayer() schedule() Advertiser sponsors1..*

© H. Mouratidis 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 * matches1..* TournamentForm 1..* +acceptPlayer(p) +removePlayer(p) +schedule() Advertiser sponsors1..* +selectSponsors(advertisers):List +advertizeTournament() +acceptPlayer(p) +announceTournament() +isPlayerOverbooked():boolean

© H. Mouratidis Class Diagram (Booch, 1999)

© H. Mouratidis Object Diagram (Booch, 1999)

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

© H. Mouratidis 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.