cen 5011 6 th lecture advance software engineering (cen-5011) instructor: masoud sadjadi...
TRANSCRIPT
CEN 5011 6th Lecture
Advance Software Engineering (CEN-Advance Software Engineering (CEN-5011)5011)
Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/Teaching/
Requirements Requirements Analysis:Analysis:
Object Modeling Object Modeling
6th LectureCEN 5011: Advanced Software Engineering 2
AcknowledgementsAcknowledgements
Dr. Bernd Bruegge
Dr. Allen Dutoit
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 3
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 4
MotivationMotivation
Ambiguity: what do you see?OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 5
ApproachApproach
From Use Cases to Objects
Top Level Use Case
A and Bare called
ParticipatingObjects
Level 1
A B
Level 3 Use Cases Level 3 Level 3 Level 3
Operations Level 4 Level 4
Level 2 Use Cases Level 2 Level 2
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 6
Our FocusOur Focus
Identification of objects
Their Behavior
Their Relationship
Their Classification
Their Organization
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 7
Object vs ClassObject vs Class
Object (instance): Exactly one thing A class describes a group of objects with
similar properties Object diagram: A graphic notation for
modeling objects, classes and their relationships ("associations"):– Class diagram: Template for describing many
instances of data. Useful for taxonomies, patters, schemata...
– Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 8
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 9
Analysis OverviewAnalysis Overview
system specification:
Model
analysis model:
Model
Problem
Statement
Requirements Analysis
Requirements Elicitation
Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 10
Req. Elicitation vs. AnalsisReq. Elicitation vs. Analsis
Developers focus on structuring and formalizing the elicited requirements.
Analysis
functionalmodel
nonfunctionalrequirements
analysis objectmodel
Requirementselicitation
dynamic model
Requirements
Analysis Model
Specification
System design
Object design
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 11
The Analysis ModelThe Analysis Model
The analysis model is composed of the functional model, the object model, and the dynamic model.
analysismodel:Model
dynamicmodel:Model
objectmodel:Model
functionalmodel:Model
use casediagram:View
classdiagram:View
statechartdiagram:View
sequencediagram:View
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 12
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 13
Analysis ConceptsAnalysis Concepts
Analysis Object Models and Dynamic Models
Entity, Boundary, and Control Objects
Generalization and Specifications
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 14
Analysis Object and Dynamic ModelsAnalysis Object and Dynamic Models
The analysis object model– focuses on the individual concepts that are
manipulated by the system, their properties, and their relationships.
– depicted by class diagrams.
The dynamic model – focuses on the behavior of the system.– depicted with sequence diagrams and with
statecharts.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 15
ExampleExample
Examples and counterexamples of classes in the analysis object model of SatWatch.
UniversalTime
TimeZone
Location
TimeZoneDatabase
GPSLocator
UserId
Software classesDomain concepts
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 16
Object Types Object Types 11
Entity Objects– Represent the persistent information tracked by the
system (Application domain objects, “Business objects”).
Boundary Objects– Represent the interaction between the user and the
system.
Control Objects: – Represent the control tasks performed by the
system.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 17
Object Types Object Types 22
Having three types of objects leads to models that are more resilient to change. – The interface of a system changes more likely than
the control– The control of the system change more likely than
the application domain
Object types originated in Smalltalk:– Model, View, Controller (MVC)
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 18
ExampleExample
Analysis classes for the 2Bwatch example
<<entity>>Year
<<entity>>Month
<<entity>>Day
<<control>>ChangeDateControl
<<boundary>>LCDDisplayBoundary
<<boundary>>ButtonBoundary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 19
Generalization and Generalization and SpecializationSpecialization
Inheritance – enables us to organize concepts.– At the top of the hierarchy is a general concept.– At the bottom are the most specialized concepts.
Generalization– is the modeling activity that identifies abstract
concepts from lower-level ones.
Specialization– is the activity that identifies more specific concepts
from a high-level one.
Generalization-specialization relationship is another name for inheritance relationship.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 20
ExampleExample
An example of a generalization hierarchy
Incident
LowPriority Emergency Disaster
EarthQuake ChemicalLeakCatInTree
TrafficAccident BuildingFire
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 21
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 22
Analysis ActivitiesAnalysis Activities
Main goal: Find the important abstractions What happens if we find the wrong
abstractions?– Iterate and correct the model
Steps during object modeling– 1. Class identification
Based on the fundamental assumption that we can find abstractions
– 2. Find the attributes– 3. Find the methods– 4. Find the associations between classes
Order of steps– Goal: get the desired abstractions– Order of steps secondary, only a heuristic– Iteration is important
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 23
From Use Cases to ObjectsFrom Use Cases to Objects
1. Identifying Entity Objects
2. Identifying Boundary Objects
3. Identifying Control Objects
4. Mapping Use Cases to Objects
5. Modeling Interactions among Objects
6. Identifying Associations
7. Identifying Aggregations
8. Identifying Attributes
9. Modeling Objects State-Dependent Behavior
10. Modeling Inheritance Relationship
11. Reviewing the Analysis Model
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 24
Identifying Entity ObjectsIdentifying Entity Objects
Participating objects form the basis of the analysis model.
Natural language analysis [Abbott, 1983].
Other heuristics– Terms that developers or users need to clarify in
order to understand the use case.– Recurring nouns in the use cases.– Real-world entities that the system needs to track.– Real-world activities that the system needs to track.– Data source or sinks.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 25
Identifying Boundary ObjectsIdentifying Boundary Objects
Boundary objects represent the system interface with the actors.
Heuristics– Identify the user interface controls that the user
needs to initiate a use case.– Identify the forms.– Identify notices and messages.– Identify actor terminals, if multiple users are
involved.– Do not model the visual aspects of the interface
(use mock-ups instead).– Always use the end user’s terms for describing
interfaces; do not use terms from solution domain.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 26
Identifying Control ObjectsIdentifying Control Objects
Control objects are responsible for coordinating boundary and entity objects.
Heuristics– Identify one control object per use case.– Identify one control object per actor in the use case.– The life span of a control object should cover the
extent of the use case or the extent of a user session.
– If difficult, then the use case is required to be refined. The entry and exit conditions are not well defined.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 27
Mapping Use Cases to ObjectsMapping Use Cases to Objects
A sequence diagram – ties use cases with objects.– It shows how the behavior of a use case (or
scenario) is distributed among its participating objects.
Heuristics– The first column is an actor initiating the use case.– The second column a boundary object creating a
control object.– The third column is a control object managing the
rest of the use case.– Boundary and control object know about each
other.– Entity objects do not know about boundary and
control objects (independency promotes sharing).
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 28
ExampleExample
FieldOfficer
ReportEmergencyButton
ReportEmergencyControl
ReportEmergencyForm
EmergencyReport
ManageEmergencyControl
press()
«create»
«create»
submit()
fillContents()
submitReport()
submitReportToDispatcher()
«create»
«destroy»
Sequence diagram for the ReportEmergency use case.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 29
Modeling Interactions among Modeling Interactions among ObjectsObjects
CRC cards– Class, Responsibilities, and Collaborators.– Initially was introduced as a tool for teaching object-
oriented concepts to novices.
CRC cards vs. Sequence Diagrams– provide different representations for supporting the
same type of activity.– Sequence diagrams are a better tool for single
modeler.– CRC cards are better for a group of developers.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 30
ExampleExample
Examples of CRC cards for the ReportEmergencyControl and the Incident classes.
ReportEmergencyControl
Responsibilities
Collects input from Field-officerControls sequence of forms during emergency reporting
Collaborators
EmergencyReportFormEmergencyReportAcknowledgementNotice
Incident
Responsibilities
rack all information related to a single inci-
Collaborators
ResourceT
dent.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 31
Identifying AssociationsIdentifying Associations
An association shows relationship between two or more classes.1. A name (optional)
2. A role
3. A multiplicity– The associations among entity objects are the
most important ones.
Heuristics– Examine verb phrases.– Name associations and roles precisely.– Eliminate any redundant association.– Do not worry about multiplicity at the beginning.– Do not define too many associations.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 32
ExampleExample
An example of association between the EmergencyReport and the FieldOfficer classes.
Eliminating redundant association.
* 1writes
author document
FieldOfficer EmergencyReport
* 1writesauthor document
1
11
1
triggersreports
FieldOfficer EmergencyReport
Incident
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 33
Identifying AggregationsIdentifying Aggregations
Aggregation – is a special type of association denoting a whole-
part relationship.
1. Composition aggregation– indicates that the existence of the parts depends of
the whole.
2. Shared aggregation– indicates that the existence of the whole and the
parts are independent.
If you are not sure, then start with a one-to-many association relationship until you are sure about the whole-part relationship.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 34
ExampleExample
Examples of aggregations and compositions.
State
County
Township
FireStation
FireFighter
FireEngine
LeadCar
Ambulance
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 35
Identifying AttributesIdentifying Attributes
Attributes – are properties of individual objects.– Consider only the ones relevant to the system.– Properties that are represented by objects are not
attributes.– A name, a brief description, and a basic type.
Heuristics– Examine possessive phrases.– Represent stored state as an attribute of the entity
object.– Describe each attribute.– Objects are not attributes. Use associations.– Do not go to details, the object structure is stable.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 36
ExampleExample
Attributes of the EmergencyReport class.
EmergencyReport
emergencyType:{fire,traffic,other}location:Stringdescription:String
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 37
Modeling State-Dependent Modeling State-Dependent BehaviorBehavior
Sequence Diagrams– used to distribute behavior across objects and to
identify operations.– represent the behavior of the system from the
perspective of a single use case.– Good for identifying missing objects.
Statechart Diagrams– represent behavior from the perspective of a single
object.– Only objects with an extended lifespan and state-
dependent behavior are worth considering.– Good for identifying missing use cases.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 38
ExampleExample
UML statechart for Incident.
Active
Inactive Closed Archived
all
when date > 1yr.
resourcessubmitted reports
Reported Assessment
DisengagementResponse
field officerarrives on site
field officerreleases resources
dispatcherallocates resources
field officer requestsadditional resources
all resourcesdeallocated
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 39
Modeling Inheritance Modeling Inheritance RelationshipRelationship
Generalization– is used to eliminate redundancy from the analysis
model.– if two or more classes share attributes or behavior,
the similarities are consolidated into a superclass.
An example of inheritance relationship.
FieldOfficer Dispatcher
PoliceOfficer
badgeNumber:Integer
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 40
Reviewing the Analysis ModelReviewing the Analysis Model
The analysis model is built incrementally and iteratively.
We say the model is stable, when the number of changes to the model are minimal.
Review– To make sure that the model is correct, complete,
consistent, unambiguous, realistic, and verifiable.– internal review
after the model is stable, it is first reviewed by the developers.
– joint review next the model is reviewed jointly by the developer
and the client.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 41
Is Our Model Correct?Is Our Model Correct?
Is the glossary of entity objects understandable by the user?
Do abstract classes correspond to user-level concepts?
Are all descriptions in accordance with the users’ definitions?
Do all entity and boundary objects have meaningful noun phrases as names?
Do all use cases and control objects have meaningful verb phrases as names?
Are all error cases described and handled?
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 42
Is Our Model Complete?Is Our Model Complete?
For each object:– Is it needed by any use case?
– In which use case is it created? Modified? Destroyed?
– Can it be accessed from a boundary object? For each attribute:
– When is it set?
– What is its type?
– Should it be a qualifier? For each association:
– When is it traversed?
– Why was the specific multiplicity chosen?
– Can association with one-to-many and many-to-many multiplicities be qualified?
For each control object:– Does it have the necessary associations to access the
objects participating in its corresponding use case?
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 43
Is Our Model Consistent?Is Our Model Consistent?
Are there multiple classes or use cases with the same name?
Do entities (e.g., use cases, classes, attributes) with similar names denote similar concepts?
Are there objects with similar attributes and associations that are not in the same generalization hierarchy?
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 44
Is Our Model Realistic?Is Our Model Realistic?
Are there any novel features in the system? Were any studies or prototypes built to ensure their feasibility?
Can the performance and reliability requirements be met? Were these requirements verified by any prototypes running on the selected hardware?
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 45
Summary of the Analysis Summary of the Analysis ActivitiesActivities
Reviewmodel
Consolidatemodel
Defineinteractions
Defineassociations
Defineattributes
Definenontrivialbehavior
Defineuse cases
Defineparticipating
objects
Defineboundaryobjects
Definecontrolobjects
Defineentityobjects
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 46
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 47
Managing AnalysisManaging Analysis
In the end, the requirements analysis document (RAD) should describe a single coherent system understandable to a single person.
Documenting Analysis Assigning Responsibilities Communicating about Analysis Iterating over the Analysis Model Client Sign-Off
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 48
Requirements Analysis Requirements Analysis DocumentDocument
1. Introduction2. Current system3. Proposed system
3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models
3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interface
4. Glossary
1. Introduction2. Current system3. Proposed system
3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models
3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interface
4. Glossary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 49
Object Models and Dynamic Object Models and Dynamic ModelsModels
Object Models Section– documents in detail all the objects we identified, their
attributes, and, when we used sequence diagrams, operations.
– As each object is described with textual definitions, relationships among objects are illustrated with class diagrams.
Dynamic Models Section– documents the behavior of the object model in terms of
statechart diagrams and sequence diagrams.
– Although this information is redundant with the use case model, it describes precisely more complex behaviors.
Once RAD is completed and published, it will be baselined and put under configuration management.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 50
Assigning ResponsibilitiesAssigning Responsibilities
Roles– Generation of Information– Integration– Review
Participants– The End User– The Client– The Analyst– The Architect– The Document Editor– The Configuration Manger– The Reviewer
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 51
Participants Participants 11
The End User– is the application domain expert.– generates information about the current system,
the environment of the future system, and the tasks it should support.
– Each user corresponds to one or more actors and helps identify their associated use cases.
The client– funds the project and coordinates the user side of
the effort.– serves as an integrator of application domain info.– defines the scope of the system based on user
requirements.– Different users may have different views of the
system.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 52
Participants Participants 22
The Analyst– is the application domain expert.– Typically a developer with broad application domain
knowledge.– models the current system and generates
information about the future system.– Each analyst is initially responsible for detailing one
or more use cases. The Architect
– has an integration role.– unifies the use case and object models from a system
point of view.– Different analyst may have different style of modeling
and different view of the parts of the systems for which they are not responsible.
– provides a system philosophy and detects omissions.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 53
Participants Participants 33
The Document Editor– is responsible for low-level integration of the
document and for the overall format of the document and its index.
The Configuration Manager– is responsible for maintaining a revision history of
the document as well as traceability information relating the RAD with other documents.
The Reviewer– validates the RAD for correctness, completeness,
consistency, and clarity.– Users, clients, developers, or other individuals may
become reviewers during requirements validations.– If an individual has not been involved with the
system, s/he may provide an excellent review.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 54
Communicating about AnalysisCommunicating about Analysis
The information communication is one of the most challenging tasks.– Participants with different backgrounds.– Stakeholders with different expectations.– New teams.– Evolving system
Approach– Clearly define territories (define roles and
responsibilities).– Clearly define objectives and success criteria.– Set up brainstorming meetings.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 55
Iterating over the Analysis Iterating over the Analysis ModelModel
Analysis occurs iteratively and incrementally. Often in parallel with other development
activities such as system design and implementation.
Steps toward a stable model:– Brainstorming
Initiated before any other activities.
– Solidification Once the client and the developers converge on a
common idea.
– Maturity Changes at the higher level are still possible but more
difficult, and thus, are made more carefully.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 56
Client Sign-OffClient Sign-Off
The client sign-off represents the acceptance of the analysis model by the client.
The client and the developers agree about the functionality and features of the system
In addition they agree on– A list of priorities– A revision process– A list of criteria that will be used to accept or reject
the system– A schedule and a budget
After the sign-off, the RAD is baselined and is used for refining the cost estimate of the project.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 57
Prioritizing requirementsPrioritizing requirements
High priority (“Core requirements”)– Must be addressed during analysis, design, and
implementation.– A high-priority feature must be demonstrated
successfully during client acceptance.
Medium priority (“Optional requirements”)– Must be addressed during analysis and design.– Usually implemented and demonstrated in the
second iteration of the system development.
Low priority (“Fancy requirements”)– Must be addressed during analysis (“very visionary
scenarios”).– Illustrates how the system is going to be used in the
future if not yet available technology enablers are available.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 58
AgendaAgenda
Motivation Analysis Overview Analysis Concepts Analysis Activities Managing Analysis Summary
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
6th LectureCEN 5011: Advanced Software Engineering 59
SummarySummary
Modeling vs. reality System modeling
– Functional model– Object model– Dynamic model
Object modeling is the central activity– Class identification is a major activity of object
modeling– There are some easy syntactic rules to find
classes/objects
Requirements Analysis Document Structure Different roles and responsibilities during
software development
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary