View
226
Download
0
Category
Preview:
Citation preview
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
1/79
Software Engineering 1
The
RequirementsSpecification
TOPIC THREE
Requirements Engineering
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
2/79
Software Engineering 2
Requirements Specifications
It is in this task that the most important work product isdeveloped because it serve as a basis for design andconstruction of the software.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
3/79
Software Engineering 3
Use-Case Analysis
It is a technique where the analysis model is derived fromthe requirements model.
It identifies the initial classes, called analysis classes of the
system. It is also identifies the responsibilities of the analysisclasses
by elaborating on the collaboration done by the classes.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
4/79
Software Engineering 4
Purpose of the Use-Case
Analysis To identify the analysis classes that will do the use case's
flow of events.
To define the behavior of the analysis classes.
To identify the responsibilities, attributes and associations ofthe analysis classes.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
5/79
Software Engineering 5
Input Documents
Use-Case Model
Supplementary Specifications
Glossary
Software Architecture Document (if any)
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
6/79
Software Engineering 6
Resulting Work Product The Analysis Model
Object Model
It is created using the ClassDiagram.
It is the most important diagrambecause it serves as a majorinput at the design engineeringactivity.
It represents the static aspect ofthe system through the analysisclasses
Behavioral Model
It is created using the Sequenceand Collaboration Diagrams.
It represents the dynamicaspect of the system.
It shows interactions andcollaborations
Class Diagrams
Sequence Diagrams
Collaboration Diagrams
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
7/79
Software Engineering 7
Steps in Use-Case Analysis
1.Review and verify use-case specifications.
2.For each use-case, find the analysis classes usingthe three perspective or UML stereotypes.
3.Model the behavior of the analysis classes ascollaborating classes using the Sequence andCollaboration Diagrams.
4.For each resulting analysis classes, identify
responsibilities.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
8/79
Software Engineering 8
Steps in Use-Case Analysis
5.For each resulting analysis classes, identifyattributes.
6.Identify associations among analysis classes.
7.Unify the analysis classes in a class diagram.8.Validate the Analysis Model.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
9/79
Software Engineering 9
STEP 1: Validate the Use
Case Model If the Use Case Model has not been validated yet, check the
model for conformance with the stated requirements.
One may find that some requirements are incorrect or not
well-understood. In such a case, the original flow of eventsshould be update, ie, one needs to go back and do therequirements analysis.
As an example, which one is clear?
The selection committee gets application forms.
The selection committee retrieves the application forms of theapplicants who are scheduled for the mock try-outs from the filingcabinet drawer with the title Mock Try-out Applicants.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
10/79
Software Engineering 10
STEP 2: For each use case,
find analysis classes. A set of candidate analysis classes (model elements) isidentified. These analysis classes are capable ofperforming the behavior described by the use cases.
Analysis classes should be named and described briefly in afew sentences.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
11/79
Software Engineering 11
Class
It is a description of a set ofobjects that share the sameattributes, operations andbehavior.
It is an abstraction thatfocuses on thecharacteristics that areimportant and ignoringthose that are not.
It is represented as arectangular box with threecompartments- name,attributes and operations.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
12/79
Software Engineering 12
Analysis Classes
It represents an early conceptual model forthings in thesystem which have responsibilities and behavior.
It is used to capture the first draftof the object model.
It handles primarily functional requirements. It models the objects we want the system to support without
making a decision on how much of them to support inhardware and how much with software.
It rarely survives into the design phase unchanged. It allows one toplaywith the distribution of responsibilities,
re-allocating, as necessary.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
13/79
Software Engineering 13
Three Perspectives
The boundary between the system and its actors.
The information the system uses.
The control logic of the system.
The three perspectives are given stereotypes in UML. Theyoffer a more robust model because they isolate those thingsmost likely to change in a system, ie, interface/environment,control flow, and key system entities.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
14/79
Software Engineering 14
Boundary Classes It intermediates between
the interface and somethingoutside the system.
Types:
User-interface
System-interface
Device-interface
1 boundary class per
actor/use-case pair.
Class Name
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
15/79
Software Engineering 15
Boundary Classes
It is used to model interaction between the system'ssurroundings and its inner workings.
It clarifies system boundaries and aid design by providing agood point of departure for identifying related services.
It insulates external forces from internal mechanisms andvice versa.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
16/79
Software Engineering 16
Boundary Classes
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
17/79
Software Engineering 17
Control Classes
It provides coordinatingbehavior of the system.
It decouples boundary andentity classes from oneanother.
1 control class per use-case
Class Name
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
18/79
Software Engineering 18
Control Classes
It provides behavior that:
Is surroundings-independent.
Defines control logic and transactions within a use case.
Changes little if the internal structure or behavior of theentity classes changes.
Uses or sets the contents of several entity classes, andtherefore needs to coordinate the behavior of these entity
classes Is not performed in the same way every time it is
activated
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
19/79
Software Engineering 19
Control Classes
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
20/79
Software Engineering 20
Entity Classes
It represents the keyconcepts of the systembeing developed.
It shows the logical datastructure.
It helps in understandingwhat the system issupposed to offer.
Class Name
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
21/79
Software Engineering 21
Entity Classes
It represent stores of information in the system.
It is used to hold and update information about somephenomenon, such as an event, a person or some real-lifeobject.
It's main responsibilities are to store and manageinformation in the system.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
22/79
Software Engineering 22
Entity Classes
It can be found by:
Using use-case flow of events as input.
Getting key abstractions from use-cases.
Filtering nouns
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
23/79
Software Engineering 23
STEP 3: Model the behavior
of the analysis classes. The behavior of the analysis classes are seen through theircollaboration with one another.
It uses the Event or Interaction Diagrams:
Sequence Diagrams Collaboration Diagrams
It helps in defining the responsibilities of the analysisclasses.
When modeling the behavior of the system, object-level isused rather than the class-level to allow for scenarios andevents that use more than one instance of a class.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
24/79
Software Engineering 24
Object Modeling
Two basic elements of the objects are modeled.
Objects
Messages.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
25/79
Software Engineering 25
Objects
They are instances of aclass.
They maybe named objectsor anonymous objects.
Named
ObjectsAnonymousObjects
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
26/79
Software Engineering 26
Messages
They are a form of communication between objects.
It has the following format:
* [condition] : action( list of parameters ) :returnValueType
Examples:
submitApplication() [athleteIsHere = yes] playBasketball(athlete):void
* [for each athlete] isAthleteHere(athlete):Boolean
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
27/79
Software Engineering 27
Event/Interaction Diagrams
They model the dynamic nature of objects within a set ofclasses.
They model the behavior of the system.
How will the system respond to certain user actions?
How are objects created? changed?
How is data transformed?
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
28/79
Software Engineering 28
Sequence Diagram
The purpose is to model interactions between objects whichmaps sequential interactions to object interactions.
It shows explicit sequence of messages passed from oneobject to another.
It is better used for real-time specifications and for complexscenarios.
It shows the sequential interactions among objects.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
29/79
Software Engineering 29
Basic Sequence Diagram
Notation
1*[condition]: Action
Client Object Supplier Object
Message
Bill:Client :Supplier
This is a sample
script.
Reflexive MessageObject Lifeline
1.1[condition]: Action
Responsibility
HierarchicalMessage
NumberingReturn Message
2 : return done
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
30/79
Software Engineering 30
Enhanced Sequence Diagram
Notation The explicit addition ofreturn is not followed by alldesigners.
Object creation and termination
Customized Messages
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
31/79
Software Engineering 31
Object Creation
Placing object at top of diagram implies that the object existsbefore the scenario starts.
If object is created during the execution of the scenario,place it relative to the point when it was created.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
32/79
Software Engineering 32
Object Activation and
Termination To show an object is active: widen the object lifeline to anarrow rectangle.
Top of rectangle indicates when an object becomes active;the bottom of the rectangle indicates when an object has
become inactive. To show that an object has been terminated, place an X at
the point where the termination occurs.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
33/79
Software Engineering 33
Customized Messages
Customized messages (for common programming events)
Synchronous Messages:
Operation proceeds only when client sends a message to thesupplier and the supplier responds to the message.
The client waits until a response is received.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
34/79
Software Engineering 34
Customized Messages
Return:
Response to a synchronized message:
Data, or
Return of Control
Timeout Events:
Client abandons message if supplier does not respond with a givenperiod of time
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
35/79
Software Engineering 35
Customized Messages
Asynchronous Events:
Client continues execution after having sent a message to thesupplier
Client does not wait or rely on supplier's response.
Conditioned Message:
Sent only if certain conditions are met
Place condition in square brackets
Eg. [product available = yes ]
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
36/79
Software Engineering 36
Enhanced Sequence
Diagram
1*[condition]: Action
Timeout
Bill:Client
:Supplier
Return
2 : return done
Activation
Deactivation
Creation
X
Termination
Synchronous
Asynchronous
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
37/79
Software Engineering 37
Building A Sequence
Diagram Step 1: Line up the participating actors and objects. Step 2: Draw the actor's and object's lifeline.
Step 3: Draw the messages from one object to another.
Step 4: Draw the return messages. Step 5: Number the messages according to the
chronological order of invocation.
Step 6: Elaborate the messages.
Step 7: Optionally enhance the Sequence Diagrams.
Sample Scenario: Club Staff adds an athlete record.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
38/79
Software Engineering 38
First Step
Place the participating analysis objects at the top of thediagram.
Place control objects between boundary and entity objects.
Control objects serves as intermediary between boundaryand entity classes.
Place actors either at the beginning or ending of the line.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
39/79
Software Engineering39
Second Step
Draw a vertical dashed line below each object to representthe object's lifeline.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
40/79
Software Engineering40
Third Step
Draw the message from one object to another. As a rule, nomessages are sent between the boundary object and entityobject. They communicate indirectly with the control object.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
41/79
Software Engineering 41
Fourth Step
Draw the return messages.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
42/79
Software Engineering 42
Fifth Step
Number the messages according to its chronological orderof the invocation.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
43/79
Software Engineering 43
Sixth Step
Elaborate on the messages by specifying any of thefollowing: repetition, conditions, list of parameters, andreturn type.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
44/79
Software Engineering 44
Seventh Step
Optionally enhance the sequence diagrams using theenhanced notation.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
45/79
Software Engineering 45
Collaboration Diagram
The purpose is to model a pattern of interaction amongobjects.
It models the objects participating in the interaction by theirlinks to each other and the messages that they send to each
other. It validates the class diagram by showing the need for each
association.
It models the recipient's message effectively which defines
an interface to that object.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
46/79
Software Engineering 46
Collaboration Diagram
1: PerformResponsibility
Client Object
Supplier Object
Synchronous Message
Link
:Client
:Supplier
Return
2: PerformResponsibility
Building a Collaboration
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
47/79
Software Engineering 47
Building a CollaborationDiagram
Step 1: Draw the participating actors and objects.
Step 2: Draw a link among actors and objects.
Step 3: Write the messages on the links.
Sample Scenario: Athlete submits application form.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
48/79
Software Engineering 48
First Step
Draw the participatingactors and objects.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
49/79
Software Engineering 49
Second Step
If objects exchange messages as shown in theirsequence diagram, draw a line connecting them whichsignifies an association.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
50/79
Software Engineering 50
Third Step
Write the messages on the associated lines.
STEP 4: For each analysis
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
51/79
Software Engineering 51
class, identify
responsibilities. This steps identifies the responsibilities that each analysis
class performs or provides.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
52/79
Software Engineering 52
Responsibilities
It is a statement of something that an object can provide.
It can be:
An action that the object can perform.
A knowledge that the object maintains and provides to other objects.
It can be derived from messages obtained from the Events orInteraction Diagrams.
For each message, examine the class of the object to which themessage is sent; receiving objects own the message, therefore,the responsibility.
If the responsibility does not exists, create one that provides thebehavior.
Check also non-functional requirements for other responsibilities.
Responsibility Identification
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
53/79
Software Engineering 53
Responsibility IdentificationGuidelines
Check that classes have consistent responsibility.
Check the classes for similar responsibilities.
Better distribution of responsibilities may be evident whileworking on another interaction diagram.
There is no problem if a class has only one responsibility,perse, but it should raise question on why it is needed.
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
54/79
Software Engineering 54
Responsibilities
STEP 4: For each analysis
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
55/79
Software Engineering 55
STEP 4: For each analysisclass, identify attributes.
The purpose of this step is to identify the information that theanalysis class is responsible for maintaining.
This steps identifies the attributes of each analysis class.
A ib
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
56/79
Software Engineering 56
Attribute
It is an information that an object owns or knows about itself.
It is used to store information.
Attribute has the following format:
attribute : data_type = default_value {constraints}
Sample:
InvoiceNumber : numeric
Temperature : numeric { 4 decimal precision }
SequenceNumber : integer = 0 {assigned sequentially by the system}
Attribute Identification
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
57/79
Software Engineering 57
Attribute IdentificationGuidelines
Sources of possible attributes are system domainknowledge, requirements and glossary.
Attributes are used instead of classes when:
Only the value of the information, not it's location, is important.
The information is uniquely owned by the object to which it belongs;no other objects refer to the information.
The information is accessed by operations which only get, set orperform simple transformations on the information; the informationhas no real behavior other than providing its value.
If the information has complex behavior, or is shared by twoor more objects the information should be modeled as aseparate class.
Attribute Identification
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
58/79
Software Engineering 58
Attribute IdentificationGuidelines
Attributes are domain dependent.
Attributes should support at least one use case.
Att ib t
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
59/79
Software Engineering 59
Attributes
STEP 6: Identify
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
60/79
Software Engineering 60
STEP 6: Identifyassociations.
The purpose of this step is to identify other classes on whichthe analysis class depend.
It defines the structural relationship of objects within the setof analysis classes.
A i ti
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
61/79
Software Engineering 61
Association
It represents the structural relationships between objects ofdifferent classes.
It connects instances of two or more classes together forsome duration.
It may be:
unary association
binary association (common)
ternary association
Association Names
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
62/79
Software Engineering 62
Association Names
Association names should reflect the purpose of therelationship. It can be:
a verb phrase
a role name
Association names can be placed on, or adjacent to theassociation path.
Avoid names likes has orcontains because they add noinformation about what relationships are between objects of
classes.
Types of Associations
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
63/79
Software Engineering 63
Types of Associations
Aggregation
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
64/79
Software Engineering 64
Aggregation
It is a special form of association that models a whole-partrelationship between an aggregate and its part.
Some situations where an aggregation is appropriate:
An object is physically composed of other objects.
An object is a logical collection of other objects.
An object physically contains other objects.
Roles
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
65/79
Software Engineering 65
Roles
It specifies the face that a class presents on each side of theassociation.
It should be unique.
It should be a noun indicating the relationship.
The use of association names and role names are mutuallyexclusive; one would not normally use both. For eachassociation, decide which conveys more information.
Aggregation and Roles
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
66/79
Software Engineering 66
Aggregation and Roles
Multiplicity
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
67/79
Software Engineering 67
Multiplicity
It is the number of objects of the class can be associatedwith one object of the other class.
It is indicated by a text expression on the association line.
It answers the following questions:
Is the association optional or mandatory?
What is the minimum and maximum number of instances that can belinked to one instance?
Multiplicity
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
68/79
Software Engineering 68
Multiplicity
There can be multiple associations between the same class,but they should represent distinct relationships, DIFFERENTROLES; they should not be just of invoking differentoperations.
Schedule
CourseOffering
add student to
remove student from
Multiplicity
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
69/79
Software Engineering 69
Multiplicity
Unspecified
Exactly one
Zero or many
One or more
Zero or one
Specified range
Multiple, disjoint ranges
2..4
0..1
1..*
0..*
*
2, 4..6
1
Multiplicity Illustrated
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
70/79
Software Engineering 70
Multiplicity Illustrated
Association Identification
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
71/79
Software Engineering 71
Guidelines Use the links of the collaboration diagrams. The indicate
that classes need to communicate.
Reflexive links do not need to be instances of a unaryassociation. An object can send a message to itself.
Unary relationship is needed when two different objects ofthe same class need to communicate with one another.
Focus only on association needed to realize the use case.DO NOT ADD!
Write a brief description of the association to indicate howthe association is used, or what relationships the associationrepresents.
STEP 7: Unify the analysis
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
72/79
Software Engineering 72
classes in a class diagram. The purpose of this step is to ensure that each analysis
class represents a single well-defined concepts with non-overlapping responsibilities.
It filters the analysis classes to ensure minimum number of
new concepts have been created.
Generalization
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
73/79
Software Engineering 73
Generalization
This concept supports reuse since hierarchies can usuallybe extended without significant effects on existingstructures.
It is usually the is a kind of relationships that are identified
and modeled into the class diagram.
Generalization Guidelines
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
74/79
Software Engineering 74
Generalization Guidelines
As a rule, only model a class as a superclass of another ifone is confident that all attributes, operations andassociation of the superclass is known.
One should not anticipate subclasses not justified in the
currently known requirements.
Unification Guidelines
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
75/79
Software Engineering 75
Unification Guidelines
The name of the analysis class should accurately capturethe role played by the class in the system. It should beunique.
Merge classes that have similar behavior.
Merge entity classes that have similar attributes, even if theirdefined behavior is different; aggregate the behaviors of themerged classes.
When one updates a class, you should update anysupplemental documentation necessary.
Evaluate the result. Be sure to:
Verify that the analysis classes meet the functional requirements
Verify that the analysis classes and their relationships are consistentwith the collaboration they support
Club MembershipM i t Obj t M d l
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
76/79
Software Engineering 76
Maintenance Object Model
Analysis Model ValidationCh kli t
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
77/79
Software Engineering 77
Checklist Object Model
Are the classes reasonable?
Does the name of each class clearly reflect the role it plays?
Does the class represent a single well-defined abstraction?
Are all attributes and responsibilities functionally coupled?
Does the class offer the required behavior?
Are all specific requirements on the class addressed?
Analysis Model ValidationCh kli t
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
78/79
Software Engineering 78
Checklist Behavioral Model
Have all the main and/or sub-flows been handled, includingexceptional cases?
Have all the required objects been found?
Has all behavior been unambiguously distributed to the participatingobjects?
Has the behavior been distributed to the right objects?
Where there are several interaction diagrams, are their relationshipsclear and consistent?
Summary
7/29/2019 MELJUN CORTES JEDI Slides-3.3 Requirements Specifications
79/79
Software Engineering 79
Su a y
Requirements ModelUse-Case Model
Use-case Diagram Use-case Specification
Supplementary SpecificationGlossary
Analysis ModelObject Model
Class Diagram of AnalysisClasses
Behavioral Model Sequence Diagrams Collaboration Diagrams
Recommended