Advance Information Systems Development (SD3043) Lecture 3: Requirements Elicitation /...
-
Upload
berenice-bates -
Category
Documents
-
view
217 -
download
1
Transcript of Advance Information Systems Development (SD3043) Lecture 3: Requirements Elicitation /...
Advance Information Systems Development (SD3043)Lecture 3: Requirements Elicitation / Analysis/Design
Dr. Haris [email protected]
10th October 2006
© H. Mouratidis 2006 2
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 2006 3
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 2006 4
Lecture Layout
Software Lifecycle Requirements Engineering
Requirements Elicitation Activities, Scenarios
Requirements Analysis models
Design Refinement of analysis
Conclusions
© H. Mouratidis 2006 5
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 2006 6
Object Oriented Software Engineering activities
Application
Domain Objects
SubSystems
class...class...class...
Solution Domain Objects
SourceCode
Test Cases
?
Expressed in Terms Of
Structured By
Implemented
ByRealized By Verified By
SystemDesign
ObjectDesign
Implemen-tation
Testing
class....?
RequirementsElicitation
Use CaseModel
RequirementsAnalysis
Requirements Engineering Design
© H. Mouratidis 2006 7
Requirements Engineering
RequirementsAnalysis
systemspecification
analysis
model
Problem StatementGeneration
RequirementsElicitation
ProblemStatement
© H. Mouratidis 2006 8
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 2006 9
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 2006 10
Requirements Elicitation Activities
Identifying actors Identifying scenarios Identifying use cases Refining use cases Identifying relationships among use cases Identifying non functional requirements
© H. Mouratidis 2006 11
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 2006 12
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 2006 13
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 2006 14
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 2006 15
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 2006 16
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 2006 17
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 ModelDescribed in the language of the developerInternal view of the systemStructured by classes and packagesUsed primarily by developers to understand how to design the systemShould not contain inconsistencies or redundancies between requirementsOutlines a first-cut designDefines use case realisation
© H. Mouratidis 2006 18
O-O Analysis activities
Identify classes Data Driven Responsibility Driven
Identify associations aggregates, attributes, inheritance
Review the model
© H. Mouratidis 2006 19
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 2006 20
Identifying Entity Classes
(Data Driven) Natural language analysis
Limitations Depends on the style of writing More nouns than relevant classes
Part of speech Model Component Examples
Proper noun Instance Alice
Common noun Class FieldOfficer
Doing verb Operation Creates, selects
Being verb Inheritance Is a kind of
Having verb Aggregation Has, consists of
Modal verb Constraints Must be
Adjective Attribute Incident description
© H. Mouratidis 2006 21
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 2006 22
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 2006 23
Responsibility Driven
Identify responsibilities in the system Class, Responsibilities, Collaborators (CRC) cards
© H. Mouratidis 2006 24
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 2006 25
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 2006 26
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 2006 27
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 2006 28
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 2006 29
System Design
System Design
2. System
Layers/PartitionsCohesion/Coupling
5. Data
1. Design Goals
DefinitionTrade-offs
4. Hardware/
Special purpose
Software
Buy or Build Trade-offAllocationConnectivity
3. Concurrency
Data structure
Persistent ObjectsFilesDatabases
ManagementAccess controlSecurity
6. Global Resource Handling
8. BoundaryConditions
InitializationTerminationFailure
Decomposition
Mapping
7. Software Control
Identification of Threads
MonolithicEvent-DrivenThreadsConc. Processes
© H. Mouratidis 2006 30
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 2006 31
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 2006 32
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 2006 33
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 2006 34
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 2006 35
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 2006 36
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 2006 37
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 2006 38
Analysis vs Design Class (agilemodeling.com)
© H. Mouratidis 2006 39
Analysis vs Design Class Diagram (Mouratidis, 2005)
TournamentControl
Player
players1..*
Tournament
name
1
1
applyForTournament()
Match
playMove()getScore()
matches1..*
startstatus
selectSponsors()advertizeTournament()acceptPlayer()announceTournament()
startend
11
1..*
matches 1..*
TournamentForm
1..*
1..*
acceptPlayer()removePlayer()schedule()
Advertiser
sponsors 1..*1..*
1..*
1..*
1..*
© H. Mouratidis 2006 40
Analysis vs Design Class Diagram (Mouratidis, 2005)
TournamentControl
Player
players1..*
Tournament
1
1
+applyForTournament()
Match
+playMove(p,m)+getScore():Map
matches1..*
+start:Date+status:MatchStatus
+name:String+start:Date+end:Date
11
1..*
matches 1..*
TournamentForm
1..*
1..*
+acceptPlayer(p)+removePlayer(p)+schedule()
Advertiser
sponsors 1..*1..* 1..*
1..*
1..*
+selectSponsors(advertisers):List+advertizeTournament()+acceptPlayer(p)+announceTournament()+isPlayerOverbooked():boolean
© H. Mouratidis 2006 41
Class Diagram (Booch, 1999)
© H. Mouratidis 2006 42
Object Diagram (Booch, 1999)
© H. Mouratidis 2006 43
Conclusions
Software Lifecycle Requirements Engineering
Requirements Elicitation Requirements Analysis
Reading: Chapters 4, 5 (essential)
© H. Mouratidis 2006 44
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.