Namdeo Kapale Sanjivani College of Engineering KopargaonUNIT 2 PPT FORMATED.pdf

UNIT 2: Requirement Engineering
Requirement Engineering,Collaborative Requirements Gathering, Quality Function Deployment,Elicitation Work Product,
Developing use cases,Building the requirement model, Validating requirements,Analysis: Scenario Based Modeling,
UML Models, Class-Based Modelling,Requirements Modeling Strategies: Flow oriented modelling, SRS plan, Case study

1. Prof.N. D. Kapale
Department of E&CEngineering
1
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: Introduction

2. Contents
Prof. N. D. Kapale Department of E&TcEngineering
2
Requirement Engineering,
Collaborative Requirements Gathering,
Quality Function Deployment,
Elicitation Work Product,
Developing use cases,
Building the requirement model,
Validating requirements,
Analysis: Scenario Based Modeling,
UML Models, Class-Based Modelling,
Requirements Modeling Strategies: Flow oriented modelling,
SRS plan, Case study

3. Requirement Engineering
Prof. N. D. Kapale Department of E&TcEngineering
3
•Requirements engineering provides the appropriate
mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution
unambiguously, validating the specification, and
managing the requirements as they are transformed into
an operational system.
•Def1: Requirement Engineering is a process of
discovery, refinement,modeling, and specification.

4. The requirements engineering process can be described in six
distinct steps
Prof. N. D. Kapale Department of E&TcEngineering
4
1. RequirementsElicitation —determining what the customer requires
2. RequirementsAnalysis & negotiation—understanding the relationships among
various customer requirements and shaping those relationships to achieve a
successful result
3. Requirements specification—building a tangible model of requirements
4. System Modeling —building a representation of requirements that can be
assessed for correctness, completeness, and consistency
5. RequirementsValidation —reviewing the model
6. RequirementsManagement —identify, control and track requirements and the
changes that will be made to them

5. What Are the Real Problems?
Prof. N. D. Kapale Department of E&TcEngineering
5
•The customer has only a vague idea of what is required
•The developer is willing to proceed with the"vague idea"
on the assumption that "we'll fill inthe details as we go"
•The customer keeps changing requirements
•The developer is "racheted" by these changesmaking errors
in specifications and development,and so it goesdificult.

6. REQUIREMENTSELICITATION FOR SOFTWARE
Prof. N. D. Kapale Department of E&TcEngineering
6
1. Initiating the Process:conduct a meeting or interview asking
context-free questions (informal)
•Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
2. better understanding of the problem
•How would you characterize "good" output that would be generated
by a successful solution?
• What problems will this solution address?
• Can you describe the environment in which the solution will be used?
• Will special performance issues or constraints affect the way the
solution is approached?

7. 3. The final set of questions focuses on the
effectiveness of the meeting
Prof. N. D. Kapale Department of E&TcEngineering
7
•Are you the right person to answer these questions? Are your answers
"official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

8. Facilitated Application Specification
Techniques (FAST)
Prof. N. D. Kapale Department of E&TcEngineering
8
•Communicates through a series of memos,formal position
papers, documents, and question and answer sessions-
Doesnot work very well
•FAST-Creation of a joint team ofcustomers and developers
who work together to
-identify the problem,
-propose elements of the solution,
-negotiate different approaches ,
-specify a preliminary setof solution requirements.

9. 9
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

10. Prof.N. D. Kapale
Department of E&CEngineering
10
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: FAST

11. FAST....
Prof. N. D. Kapale Department of E&TcEngineering
11
•A meeting is conducted at a neutral site and attended by both software
engineers and customers.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important
pointsbut informal enough to encourage the free flow of ideas.
• A "facilitator" (can be a customer, a developer, or an outsider) controls
themeeting.
• A "definition mechanism" (can be work sheets, flip charts, or wall
stickers oran electronic bulletin board, chat room or virtual forum) is
used.

12. Example: Safe home system
Prof. N. D. Kapale Department of E&TcEngineering
12
•Initial meetings between the developer and customeroccurs.
-to establish the scope of the problem and overall perception of a solution.
-the developer and customer write a one-or two-page "product request."
-A meeting place, time, and date for FAST are selected and a facilitator is chosen.
-Attendees from development and customer organizations are invited to attend.
-The product request is distributed.
each FAST attendee is asked to make a
-list of objectsthat are part of the environment that surrounds the system, other
objects that are to be produced by the system, and objects that are used by the system
to perform its functions.
-list of services(processes or functions) that manipulate or interact with the objects.
-lists of constraints(e.g., cost, size, business rules) and performance criteria (e.g.,
speed, accuracy)

13. Product description
Prof. N. D. Kapale Department of E&TcEngineering
13
•Our research indicates that the market for home security systems is
growing at a rate of 40percent per year.
We would like to enter this market by building a microprocessor-based
home security system that would protect against and/or recognize a
variety of undesirable"situations" such as illegal entry, fire, flooding, and
others.
The product, tentatively calledSafeHome, will use appropriate sensors to
detect each situation, can be programmed by thehomeowner, and will
automatically telephone a monitoring agency when a situation isdetected.

14. Prof. N. D. Kapale Department of E&TcEngineering
14
•List of Objects:SafeHome might include smoke detectors, window and door
sensors,motion detectors, an alarm, an event (a sensor has been activated), a
control panel,a display, telephone numbers, a telephone call.
•The list of services :setting the alarm, monitoring the sensors, dialing the phone,
programming the control panel, reading the display.
•Lists of constraints :manufactured cost of less than Rs 5000, must be user-
friendly, must interface directly to a standard phone line and performance criteria
( a sensor event should be recognized within one second)
•Everyone should agree that the product is justified(Need )
•Each participant presents his lists for discussion.
•The lists can be pinned to the walls of the room using large sheets of paper, stuck
to the walls using adhesive backed sheets, or written on a wall board.
•Posted in chat room environment for review prior to the meeting.
•Combined list is created by the group. The combined list eliminates redundant
entries, adds any new ideas that come up during the discussion.

15. Mini-Specifications
Prof. N. D. Kapale Department of E&TcEngineering
15
•SafeHome objectcontrolpanel_x0002_
•Mounted on wall
• Size approximately 9 x5 inches
• Contains standard 12-key pad and special keys
• Contains LCD display
• Customer interaction occurs through keys
• Used to enable and disable the system
• Connected to all sensors
Each FAST attendee makes a list of validationcriteria for the
product/system and presents list to the team.
Finally writing the complete draft specification

16. FAST Guidelines
Prof. N. D. Kapale Department of E&TcEngineering
16
•Participants must attend entire meeting
•all participants are equal
•Preparation is as important .
•all pre-meeting documents are to be viewed as “proposed”
•off-site meeting location is preferred
•Set an agenda and maintain it
•Don’t get mired in technical detail

17. 17
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

18. Prof.N. D. Kapale
Department of E&CEngineering
18
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: QFD

19. Quality Function Deployment(QFD)
Prof. N. D. Kapale Department of E&TcEngineering
19
•Aquality management technique that translatesthe needs of the
customer into technical requirements for software.
•Emphasizes anunderstanding of what is valuable to the customer and
then deploys these valuesthroughout the engineering process.
•QFD identifies three types of requirements
1. Normal 2. Expected 3. Exciting
•Normal requirements.
If these requirements are present, the customer is satisfied.
Ex-requested types of graphical displays, specific system functions, and
defined levels of performance.

20. QFD....
Prof. N. D. Kapale Department of E&TcEngineering
20
•Expected requirements. These requirements are implicit to the
product . That the customer does not explicitly state them.Their
absence will be a cause for significant dissatisfaction.
Examples: ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.
•Exciting requirements. These features go beyond the customer’s
expectations and prove to be very satisfying when present.
For example, word processing software is requested with standard
features. The delivered product contains a number of page layout
capabilities that are quite pleasing and unexpected.

21. Quality Function Deployment
Prof. N. D. Kapale Department of E&TcEngineering
21
•Function deploymentdetermines the “value” (as
perceived by the customer) of each function required of
the system
•Information deploymentidentifies data objects and events
•Task deployment examines the behavior of the system
•Value analysisdetermines the relative priority of
requirements

22. 22
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

23. Prof.N. D. Kapale
Department of E&CEngineering
23
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: USE CASE

24. Use-Cases
Prof. N. D. Kapale Department of E&TcEngineering
24
•Aset of scenarios that identify a thread of usagefor the system to be constructed.
Provide a description of how the system will be used.
•Identify the different types of people that use the system or product. These actors
actually represent roles that people (or devices) play as the system operates.
•An actor is anything that communicates with the system or product and that
is external to the system itself.
•User may plays no of roles while using system. while actor plays single role.
Ex-consider a machine operator (a user) who interacts with the control computer
for a manufacturing cell that contains a number of robots and CNC machines.
Software for the control computer requires four different modes (roles) for
interaction. Programming mode, test mode, monitoring mode, and troubleshooting
mode.

25. Use-Cases
Prof. N. D. Kapale Department of E&TcEngineering
25
•Once actors have been identified, use-cases can be developed.
•The use-casedescribes the manner in which an actor interacts with the
system.
What are main tasks or functions are performed by the actor?
What system information will the actor acquire, produce, or change?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?

26. Prof. N. D. Kapale Department of E&TcEngineering
26
Thethree actors:
•The homeowner (the user)
•Sensors(devices attached to the system),
•The monitoring and response subsystem
(the central station that monitors SafeHome).
The homeownerinteracts with the product in a
number of different ways:
•enters a password to allow all other
interactions
• inquires about the status of a security zone
• inquires about the status of a sensor
• presses the panic button in an emergency
• activates/deactivates the security system

27. A use-case for system activation
Prof. N. D. Kapale Department of E&TcEngineering
27
1. The homeowner observes aSafeHome control panel to determine if
the system is ready for input. If the system is not ready,
the homeowner must physically close windows/doors so that the ready
indicator is present.
2. The homeowner uses the keypad to enter password. The password is
compared with the valid password stored in the system. If the password
is incorrect, the control panel will beep once and reset itself for
additional input. If the password is correct, the control panel awaits
further action.
3. The homeowner selects stay or away to activate the system. Stay
activates only perimeter sensors (inside motion detecting sensors are
deactivated). Awayactivates all sensors.
4. When activation occurs, a red alarm light can be observed by the
homeowner.

28. 28
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

29. Prof.N. D. Kapale
Department of E&CEngineering
29
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: Software Requirement Analysis

30. Software Requirements Analysis
Prof. N. D. Kapale Department of E&TcEngineering
30
•Identify the “customer” and work together to negotiate
“product-level” requirements
•Build an analysis model
focus on data
define function
represent behavior
•Prototype areas of uncertainty
•Developea specification that will guide design
•Conduct formal technical reviews

31. The Analysis Process
Prof. N. D. Kapale Department of E&TcEngineering
31
the problem
requirements
elicitation
build a
prototype
create
analysis
models
develop
Specification Review

32. RequirementsAnalysis Guidelines
Prof. N. D. Kapale Department of E&TcEngineering
33
•Understand the problem before you begin to create the
analysis model.
•Develop prototypes that enable a user to understand how
human-machine interaction will occur.
•Record the origin of and the reason for every requirement.
•Use multiple views of requirements(Models).
•Prioritize(rank)requirements.
•Work to eliminate ambiguity.

33. Analysis Modeling
Prof. N. D. Kapale Department of E&TcEngineering
34
The Information Domain
•software applications can be collectively called data
processing.
•process data, to transform data from one form to another;
that is, to accept input, manipulate it in some way, and
produce output.

34. Analysis Modeling
Prof. N. D. Kapale Department of E&TcEngineering
35
1. Functional models.
Software transforms information,
-it must perform at least three generic functions: input, processing, and
output.
-functional models the software engineer focuses on problem specific
functions.
-The functionalmodel begins with a single context level model (i.e., the
name of the softwareto be built).
Over a series of iterations, more and more functional detailsare provided,
until all system functionality is represented.

35. Modeling
Prof. N. D. Kapale Department of E&TcEngineering
36
2. Behavioral models.
•Most software responds to events from the outsideworld.
•This stimulus/response characteristic forms the basis of the behavioral model.
•A computer program always exists in some state—(e.g., waiting, computing,
printing, polling) thatis changed only when some event occurs.
For example, software will remainin the wait state until
(1) an internal clock indicates that some time intervalhas passed,
(2) an external event (e.g., a mouse movement) causes an interrupt, or
(3) an external system signals the software to act in some manner.
Abehavioral model creates a representation of the states of the software andthe
events that cause a software to change state.

36. Use of Models created during requirements analysis
Prof. N. D. Kapale Department of E&TcEngineering
37
•The model aids the analyst in understanding the
information, function, andbehavior of a system, thereby
making the requirements analysis task easierand more
systematic.
•The model becomes the focal point for review and,
therefore, the key to a determination of completeness,
consistency, and accuracy of the specifications.
•The model becomes the foundation for design, providing
the designer with an essential representation of software
that can be "mapped" into an implementation context

37. Partitioning
Prof. N. D. Kapale Department of E&TcEngineering
38
•Partitioning decomposes a problem into its constituent parts.
•Hierarchical representation
•Partition the uppermost element by (1) exposing increasing detail by
moving vertically in the hierarchy (2) functionally decomposing the
problem by moving horizontally in the hierarchy .

38. 40
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

39. Prof.N. D. Kapale
Department of E&CEngineering
41
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: Software PROTOTYPING

40. SOFTWARE PROTOTYPING
Prof. N. D. Kapale Department of E&TcEngineering
42
•In some cases it is possibleto apply operational analysis principles and
derive a model of software from whicha design can be developed.
•In other situations, requirements elicitation (via FAST,QFD, use-cases,
techniques is conducted, analysisprinciples are applied, and a model of
the software to be built.Prototype
•Prototype is constructed for customer and developer assessment.
•In some Circumtances ,construction of a prototype at the beginning of
analysis, since the model is the only means through which
requirements can be effectively derived.

41. Prototyping Approach
Prof. N. D. Kapale Department of E&TcEngineering
43
•The prototyping paradigm can be either close-ended or open-ended
•The close-endedapproach is often called throwaway prototyping.
•Rough demonstration of requirements.It is then discarded.
•An open-endedapproach, called evolutionary prototyping, uses the
prototype as the first part of an analysis activity that will be
continued into design and construction.
•The prototype of the software isthe first evolution of the finished
system.

42. Selecting theappropriateprototypingapproach
Prof. N. D. Kapale Department of E&TcEngineering 44
Question Throwaway
prototype
Evolutionary
prototype
Additional
preliminary
work required
Is the application domain understood?Yes Yes No
Can the problem be modeled? Yes Yes No
Is the customer certain of basic system
requirements?
Yes Yes No
Are requirements established and
stable?
No Yes Yes
Are any requirements ambiguous?Yes No Yes
Are there contradictions in the
requirements?
Yes No Yes

43. Prototyping Methods and Tools
Prof. N. D. Kapale Department of E&TcEngineering
45
•Software prototyping to be effective, a prototype must be developed
rapidly.
1. Fourth generation techniques(4GT):
-Enable the software engineer to generate executable code quickly.
-Encompass a broad array of database query and reporting languages,
program and application generators, and other very high-level
nonprocedural languages.
2. Reusable software components:
-To assemble, rather than build, the prototype by using a set of existing
software components.
-Program component reuse will work only if a library system is
developed.
-Existing software product can be used as a prototype for a "new,
improved" competitive product.

44. Prototyping Methods and Tools......
Prof. N. D. Kapale Department of E&TcEngineering
46
•Formal specification and prototyping environments:
-Number of formal specification languages and tools have been
developed as a replacement for natural language specification
techniques.
-formal languages and Interactive environments
(1) Enable an analyst to interactively create language-based
specifications of a system or software.
(2) Invoke automated tools that translate the language-based
specifications into executable code.
(3) Enable the customer to use the prototype executable code to refine
formal requirements.

45. Requirements Validation
Prof. N. D. Kapale Department of E&TcEngineering
47
•Requirements are assessed for quality during a validationstep.
•To ensure that all systemrequirements have been stated
unambiguously.
•Inconsistencies, omissions, and errors have been detected and
corrected.
Validation mechanism is the formal technical review.
The review team includes stakeholders (system engineers,
customers, users) who examine the system specification.

46. 48
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

47. Prof.N. D. Kapale
Department of E&CEngineering
49
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: Software Requirement specification

48. Checklist Questions.....
Prof. N. D. Kapale Department of E&TcEngineering
50
•Are requirements stated clearly? Can they be misinterpreted?
•Is the source of the requirementidentified?
•Has the final statement of the requirement been examined by or
against the original source?
•Is the requirement bounded in quantitative terms?
•What other requirements relate to this requirement? Are they clearly
notedvia a cross-reference matrix or other mechanism?
•Does the requirement violate any domain constraints?

49. Checklist Questions......
Prof. N. D. Kapale Department of E&TcEngineering
51
•Is the requirement testable? If so, can we specify tests (sometimes
called validationcriteria) to exercise the requirement?
•Is the requirement traceable to any system model that has been
created?
•Is the system specification structured in a way that leads to easy
understanding, and easy translation into more technical work
products?
•Has an index for the specification been created?
•Have requirements associated with system performance, behavior,
and operationalcharacteristics been clearly stated? What requirements
appear to beimplicit?

50. Software Requirement Specification
Prof. N. D. Kapale Department of E&TcEngineering
52
•Representationguidelines:software requirements may be specified in a variety of
ways.
1. Representation format and content should be relevant to the problem.
-representation forms contained within the specification are likely to vary with the
application area.
For example, a specification for a manufacturing automation system might use
different symbology, diagrams and language than the specification for a programming
language compiler.
2.Information contained within the specification should be nested.
-Representations should reveal layers of information so that a reader can move to the
level of detail required.
-Paragraph and diagram numbering schemes should indicate the level of detail that is
being presented.

51. Representationguidelines.......
Prof. N. D. Kapale Department of E&TcEngineering
53
3.Diagrams and other notational forms should be restricted
in number and consistent in use.
-Confusing or inconsistent notation, whether graphical or
symbolic, degrades understanding and fosters errors.
4. Representations should be revisable.
-The content of a specification will change. Ideally, CASE tools
should be available to update all representations that are
affected by each change.

52. Software Requirement Specification Formats
Prof. N. D. Kapale Department of E&TcEngineering
54
•Introduction:
-States the goals andobjectives of the software.
-Software scope of the planning document.
•The Information Description
-provides a detailed description of the problem to be solved.
-Information content, flow, and structure are documented.
-Hardware, software, and human interfaces are described for external
system elements and internal software functions.

53. SRS Format......
Prof. N. D. Kapale Department of E&TcEngineering
55
•Functional Description
-A description of each function required to solve the problem is
presented.
-A processing narrative is provided for each function.
-design constraints are stated and justified, performance characteristics
are stated.
-diagrams are included to graphically represent the overall structure of
the software
•Behavioral Description
-examines the operation of the software as a consequence of external
events and internally generated control characteristics.

54. SRS Format.......
Prof. N. D. Kapale Department of E&TcEngineering
56
•Validation Criteria
-Most important and, the most oftenneglectedsection
-How do we recognize a successful implementation?
-What classes of tests must be conducted to validate function,
performance, and constraints?
•Bibliography and Appendix.
-contains references to all documents that relate to the software.
-These include other software engineering documentation, technical
references, vendor literature, and standards.
-The appendix contains information that supplements the
specifications.
-Tabular data, detailed description of algorithms, charts, graphs, and
other material are presented as appendixes.

55. Software Requirement Specification Review
Prof. N. D. Kapale Department of E&TcEngineering
57
•Conductedby both the software developer and the customer.
•To ensure that the specification is complete, consistent, and accurate.
•Specifications contain “vague terms” (e.g., some, sometimes, often,
usually,mostly), the reviewer should flag the statements for further
clarification.
•The specification becomes a "contract" for software development.
•Requests for changes in requirements after the specification is
finalized will not be eliminated. But Change increase cost and/or
protract the schedule.

56. 58
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering

57. Prof.N. D. Kapale
Department of E&CEngineering
59
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: UML

58. Prof. N. D. Kapale Department of E&TcEngineering
60
Model : A picture is worth a thousand words!
UML (The Unified Modeling Language)Models
•The UML is a standard language that is used to effectively describe a
model, using both visual elements and text, just as in your map.
•General purpose modelling language
•The main aim of UML is to define a standard way to visualize the way
a system has been designed.
•UML is not a programming language.
•Rather it is a pictorial language consisting of symbols, diagrams, text,
pseudo-code or anything that describes a software system.
•UML combines techniques from data modeling, business
modeling,object modeling and component modeling.

59. UML Models.......
Prof. N. D. Kapale Department of E&TcEngineering
61
A UML model is a representation of a software in terms of it's structure,
behavior and interactions, before the actual coding process begins.
This model is usually used to describe an object oriented programming
approach.
Considering the complexity of a software product, a UML model is
made up of different types of diagrams.
Elements of UML model diagrams
Class: You would use this element to describe all the classes your
software system would have.
Contain an object's attributes and behavior.

60. UML Model Components....
Prof. N. D. Kapale Department of E&TcEngineering
62
•Object:You would use this element to describe all the objects
you would create inside your classes.
•Interface:You would use this element to create method
signatures without implementing any code, i.e you would just
describe the functions of a method. A class would then be able
to implement the interface by implementing its functionality.
•Collaboration:Using this element, you would describe the
interaction between various elements.
•Use case:Here, you would describe how a user interacts with
the software system.

61. UML Model Components....
Prof. N. D. Kapale Department of E&TcEngineering
63
•Node:This element is use to represent any physical parts of
the system , for example , a server.
•Package: You would use this element to group similar
classes or components together under a namespace.
•Note: You would use this element to add comments or
explanations in your diagrams.

62. UML diagrams represents two different views of system model
Prof. N. D. Kapale Department of E&TcEngineering
64
1. Static (Structural View): Emphasizes static
structure of system using objects, attributes,
operations and relationship
2. Dynamic (Behavioural view):Emphasizes
dynamic behaviour of system by showing
collaboration amoungst objects and changes
to the internal states of objects.

63. Prof.N. D. Kapale
Department of E&CEngineering
65
Sanjivani College of Engineering, Kopargaon
Department of Electronics & Telecommunication Engineering
(An Autonomous Institute)
Affiliated to Savitribai Phule Pune University
Accredited ‘A’ Grade by NAAC
________________________________________________________________________________________
Subject: Software Engineering Modelling & Design (EC 315)
UNIT 2:Requirement Engineering
Topic: UML Class diagram

64. CLASS DiaGRAM
Prof. N. D. Kapale
Department of E&TcEngineering
66
all objects have the similar attributes and operations.

65. Prof. N. D. Kapale Department of E&TcEngineering
67

66. Prof. N. D. Kapale Department of E&CEngineering 68

67. Contents
Prof. N. D. Kapale Department of E&TcEngineering
69
•Inheritance: from the base class you can
inherit a derived class.
-Allows to define a new class(derived class)
by extending an existing class(base class)
-Represents generalization-specialization

68. Prof. N. D. Kapale Department of E&TcEngineering
70

69. Prof. N. D. Kapale
Department of E&TcEngineering
71

70. Contents
Prof. N. D. Kapale Department of E&TcEngineering
72

71. Association Multiplicity
Prof. N. D. Kapale Department of E&TcEngineering
73

72. Class Diagram
•Association
•Dependancy
•Aggregation
(No dependancy of conained
class on container class)
•Composition(Strong dependancy
of conained class on container class)
•Generalization
Teacher Student
Teaches to
1 1..*
Consumer
supplier
Library
Books
container class
contained class
1..*
A
B
whole part

73. Generalization
Person
student teacher
Generalization
specilization

74. 76
Thank You!
Prof. N. D. Kapale Department of E&TcEngineering