• Requirements engineering process :

Feasibility studies, Requirements elicitation and

analysis, Requirements validation, Requirements
management.
• System models : Context Models, Behavioral
models, Data models, Object models, structured
methods.
 REQUIREMENTS ENGINEERING PROCESS
• To create and maintain a system requirement document
• The overall process includes four high level requirements
engineering sub-processes:
1.Feasibility study
-Concerned with assessing whether the system is useful to
the business
2.Requirements Elicitation and analysis
-Discovering requirements
3.Requirements Specifications
-Converting the requirements into a standard form
4.Requirements Validation
- Checking that the requirements actually define the
system that the customer wants
 THE REQUIREMENTS ENGINEERING
PROCESS
Requir ements
Feasibility elicitation and
stud y anal ysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document
 SPIRAL REPRESENTATION OF REQUIREMENTS
ENGINEERING PROCESS

• Process represented as three stage activity

• Activities are organized as an iterative process around a
spiral.
• Early in the process, most efforts will be spent on
understanding high-level business and the user requirement.
• Later in the outer rings, more effort will be devoted to system
requirements engineering and system modelling
• Three level process consists of:
1. Requirements elicitation
2. Requirements specification
3. Requirements validation
Requirements engineering Process
 FEASIBILITY STUDIES
• Starting point of the requirements engineering process
• Input: Set of preliminary business requirements, an outine description of
the system and how the system is intended to support business processes.
• Output: Feasibility report that recommends whether or not it is worth
carrying out further
• Feasibility report answers a number of questions:
1.Does the system contribute to the overall objective of the organization?
2.Can the system be implemented using the current technology and
within given cost and schedule constraints?
2.Can the system be integrated with other system which are already in
place?
• Feasibility Study in Software Engineering is a study to evaluate feasibility
of proposed project or system.
• Feasibility study is one of stage among important four stages of
Software Project Management Process.
• As name suggests feasibility study is the feasibility analysis
or it is a measure of the software product in terms of how
much beneficial product development will be for the
organization in a practical point of view.
• Feasibility study is carried out based on many purposes to
analyze whether software product will be right in terms of
development, implementation, contribution of project to the
organization etc.
• Types of Feasibility Study :
The feasibility study mainly concentrates on below five
mentioned areas. Among these Economic Feasibility Study
is most important part of the feasibility analysis and Legal
Feasibility Study is less considered feasibility analysis.
1. Technical Feasibility.
2. Operational Feasibility. ...
3. Economic Feasibility. ...
4. Legal Feasibility. ...
5. Schedule Feasibility
• Technical Feasibility –
• In Technical Feasibility current resources both hardware software along with
required technology are analyzed/assessed to develop project.
• This technical feasibility study gives report whether there exists correct required
resources and technologies which will be used for project development.
• Along with this, feasibility study also analyzes technical skills and capabilities of
technical team, existing technology can be used or not, maintenance and up-
gradation is easy or not for chosen technology etc.
• Operational Feasibility –
• In Operational Feasibility degree of providing service to requirements is
analyzed along with how much easy product will be to operate and maintain
after deployment.
• Along with this other operational scopes are determining usability of product,
Determining suggested solution by software development team is acceptable
or not etc.
• Economic Feasibility –
• In Economic Feasibility study cost and benefit of the project is analyzed. Under
this feasibility study a detail analysis is carried out what will be cost of the project
for development which includes all required cost for final development like
hardware and software resources required, design and development cost and
operational cost and so on.
• After that it is analyzed whether project will be beneficial in terms of finance for
organization or not.
Legal Feasibility –
In Legal Feasibility study project is analyzed in legality point of view. This
includes analyzing barriers of legal implementation of project, data protection
acts or social media laws, project certificate, license, copyright etc. Overall
it can be said that Legal Feasibility Study is study to know if proposed project
conform legal and ethical requirements.

Schedule Feasibility –
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for
proposed project which includes how many times teams will take to complete
final project which has a great impact on the organization as purpose of project
may fail if it can’t be completed on time.

Feasibility Study Process :

The below steps are carried out during entire feasibility analysis.
• Information assessment
• Information collection
• Report writing
• General information
• Need of Feasibility Study :
Feasibility study is so important stage of
Software Project Management Process as after completion of feasibility
study it gives a conclusion of whether to go ahead with proposed project as
it is practically feasible or to stop proposed project here as it is not
right/feasible to develop or to think/analyze about proposed project again.
• Along with this Feasibility study helps in identifying risk factors involved
in developing and deploying system and planning for risk analysis also
narrows the business alternatives and enhance success rate analyzing
different parameters associated with proposed project development.
 REQUIREMENTS ELICITATION AND ANALYSIS
• This activity involves a variety of people in an organization (The Stakeholders)
working together to find out about the domain, what services to be offered and
the required performance of system and its hardware constraints etc.
• Stakeholder
-- Refers to any person or group who will be affected by the system directly or
indirectly i.e. End users, Engineers, business managers, domain experts.
• Problems in understanding the requirements of the System /Reasons why
eliciting is difficult :
• Unrealistic Expectations :
• Stakeholder often don’t know what they want from the computer system.
• Requirements Engineer does not understand the customers requirements.
• Stakeholder expression of requirements in natural language is sometimes
difficult to understand.
• Differences in requirements :
• Different stakeholders express requirements differently .
• Economic & Business Environment :
• The dynamic nature of this environment may lead to changes in requirements
or stakeholders which may effect the RE process
• Influences of political factors can lead to huge changes n requirements or
stakeholders
Requirements Elicitation Process
REQUIREMENTS ELICITATION PROCESS
• Each organization will have its own version of instantiation of
this general process, depending on local factors such as the
expertise staff the type of system being developed and the
standards used.
Process activities :
1. Requirements Discovery
-- Interaction with stakeholder to collect their requirements
including domain and documentation.
2. Requirements classification and organization.
-- Coherent clustering of requirements from unstructured
collection of requirements.
3. Requirements prioritization and negotiation
-- Assigning priority to requirements.
--Resolves conflicting requirements through negotiation
4. Requirements Specification.
-- Requirements be documented and placed in the next round of
spiral.
 Requirements Discovery

» Other sources include the application

domain and other systems that interact
with the current system.
 REQUIEMENTS DICOVERY
• These different requirements sources can all be represented as System View points with
each viewpoint showing a subset of the requirements for the system.
• Viewpoint provides the perspective to the system using which requirements can be
discovered.
• Stakeholders can be classified into different viewpoints.
• Different viewpoints on a problem see the problem in different ways but their perspectives
are not completely independent but usually overlap so that they have common
requirements.
• Recognizes multiple perspectives and provides a framework for discovering conflicts in the
requirements proposed by different stakeholders.
Three Generic types of viewpoints
1. Interactor viewpoint
--Represents people or other system that interact directly with the system.
ex: bank’s customers and the bank’s account database.
2. Indirect viewpoint
--Stakeholders who influence the requirements, but don’t use the system.
ex: Management of the bank and the bank security staff.
3. Domain viewpoint
--Domain characteristics and constraints that influence the system requirements.
ex: the standards that have been developed for interbank communications.
 REQUIREMENTS DISCOVERY TECHNIQUES
1. Interviewing
2. Observations(Ethenography)
3. Scenarios
4. Usecases
5. Prorotyping

6. Interviewing
--Puts questions to stakeholders about the system that they use and the system
to be developed.
--Requirements are derived from the answers
Two types of interview
7.Closed interviews where the stakeholders answer a pre-defined set of questions.
8.Open interviews discuss a range of issues with the stakeholders for better
understanding their needs.
Effective interviewers have two characteristics.
a) Open-minded: avoid pre-conceived ideas
b) Prompter: prompt the interviewee to start discussion with a question
or a proposal
REQUIREMENTS DISCOVERY TECHNIQUES
2. Ethnography:
•It is an observational technique that can be used to understand social
and organisational requirements.
•The value of ethnography is that it helps analysts discover implicit
system requirements that reflect the actual rather than the formal
processes in which people are involved.
•Ethnography is particularly effective at discovering two types of
requirements.
– Requirements that are derived from the way in which people
actually work rather than the way in which process definitions say
they ought to work.
– Requirements that are derived from cooperation and awareness
of other people’s activities.
• Can be combined with prototyping
• Not good technique for discovering organisational or domain
requirements
• Cannot identify new features that should be added to a system
REQUIREMENTS DISCOVERY TECHNIQUES
3. Scenarios
--Easier to relate to real life examples than to abstract description.
--Starts with an outline of the interaction and during elicitation,
details are added to create a complete description of that
interaction.
--Scenario includes:
1. Description at the start of the scenario.
2. Description of normal flow of the event.
3. Description of what can go wrong and how this is handled.
4.Information about other activities parallel to the scenario.
5.Description of the system state when the scenario finishes.
 LIBSYS scenario: Downloading an Article

• Initial assumption: The user has logged on to the LIBSYS system and has
located the journal containing the copy of the article.
• Normal flow of Events: The user selects the article to be copied. He or she
is then prompted by the system to either provide subscriber information for
the journal or to indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an organisational account
number.
• The user is then asked to fill in a copyright form that maintains details of
the transaction and they then submit this to the LIBSYS system.
• The copyright form is checked and, if OK, the PDF version of the article is
downloaded to the LIBSYS working area on the user’s computer and the
user is informed that it is available. The user is asked to select a printer and
a copy of the article is printed
 LIBSYS scenario
• What can go wrong:
• The user may fail to fill in the copyright form correctly. In this case, the
form should be re-presented to the user for correction. If the
resubmitted form is still incorrect then the user’s request for the article
is rejected.
• The payment may be rejected by the system. The user’s request for the
article is rejected.
• The article download may fail. Retry until successful or the user
terminates the session..
• Other activities: Simultaneous downloads of other articles.
• System state on completion:
• User is logged on.
• The downloaded article has been deleted from LIBSYS workspace if it
has been flagged as print-only.
REQUIREMENTS DISCOVERY TECHNIQUES

4. Use cases
-- scenario based technique for requirement
elicitation.
-- A fundamental feature of UML, notation for
describing object-oriented system models.
-- Identifies a type of interaction and the
actors involved.
-- Sequence diagrams are used to add
information to a Use case.
 Article printing use-case

Library User Article printing

Actor- user/other sytem Action
 LIBSYS use cases

Ar ticle search

Library Article printing

User

User administration Library

Staff

Supplier Catalogue services

» Scenarios and use cases are good for
eliciting requirements from stakeholders
who interact directly with the system .
» Not effective for eliciting constraints or high
level business and non functional
requirements or for domain requirements .
 REQUIREMENTS VALIDATION
• Requirements Validation is the process of checking that requirements actually define
the system that the customer really wants.
• It is Concerned with finding problems with the requirements .
• Important because errors in requirements can lead to extensive rework costs
when discovered in development or after the system is in service.
• During the requirements validation , the following checks should be carried out on the
requirements in the SRS:
Validation checks:
• 1.Validity checks
• --Verification that the system performs the intended function by the user.
• 2.Consistency check
• --Requirements should not conflict. Should not contain different descriptions of the
same function.
• 3. Completeness checks
• --Includes requirements which define all functions and constraints intended
by the system user.
• 4. Realism checks
• --Ensures that the requirements can be actually implemented according to budget
and technology.
• 5. Verifiability
• — Are the requirements testable?To avoid disputes between customer and
developer, the written system requirements should be verifiable.
 VALIDATION TECHNIQUES
1. REQUIREMENTS REVIEWS : Requirements are analysed systematically by a
team of reviewers.
• Team of Reviewers check for errors and inconsistencies in requirements
• Review Checks:
(a) Verifiability: Testable
(b) Comprehensibility
(c) Traceability
(d) Adaptability

2. PROTOTYPING: An executable system model is demonstrated to end-users and

customers to see if it meets their real needs.

3. TEST-CASE GENERATION: Requirements should be testable. It often reveals

the requirements problems.
• Tests for requirements should be devised part of validation process to reveal the
problems.
• If a test is difficult or impossible to design then it implies the requirements too
are difficult to implement and should be reconsidered.
Types of reviews
There are two types of reviews:
• Informal reviews
• Formal reviews

Informal reviews
Informal reviews take place between two or three people. The review conference is
scheduled at their convenience.
• This meeting is generally scheduled during the free time of the team members.
• There is no planning for the meeting.
• If any errors occur, they are not corrected in the informal reviews.
• There is no guidance from the team.
• This review is less effective compared to the formal review.

Formal reviews
Formal reviews take place among a team of three to five members. In the formal review,
the members discuss the software model.
• This meeting is scheduled beforehand. This gives the team members time to prepare.
• This meeting consists of a professional team that identifies and corrects errors in the
model.
• This meeting does not exceed two hours.
» Two-tier Reviews: First round is a informal
review with small team second a formal
review
» Rules of reviewing :
» Encourage criticism
» Every suggestion is a gift
» Choose your best reviewer
» Allow adequate time
 REQUIREMENTS MANAGEMENT
Requirements evolution

Initial Changed
understanding understanding
of pr ob lem of prob lem

Initial Changed
r equir ements r equir ements

Time
 REQUIREMENTS MANAGEMENT
• Requirements are likely to change for large software systems during
requirements engineering process.so there is a need for requirements
management process is required to handle changes.
• Requirement management is the process of understanding and
controlling changes to system requirements during requirements
engineering process and system development.
• Reasons for requirements changes
• (a) Diverse Users community where users have different requirements
and priorities
• (b) System customers and end users are different
• (c) Change in the business and technical environment after installation.
• Two classes of requirements
(a) Enduring requirements: Relatively stable requirements..
Derived from core, slow to change activities of the organization
Depend on application domain
(b) Volatile requirements: Likely to change during system
development process or during operation
Volatile Requirements Types
 Requirements management planning
An essential first stage in requirement management process is Planning .
Planning process consists of the following
1.Requirements identification
-- Each requirement must have unique tag for cross reference and
traceability
2.Change management process
-- Set of activities that assess the impact and cost of changes
3.Traceability policy
-- A matrix showing links between requirements and other elements of
software development
4.Tool support
—Automatic tool to improve efficiency of change management process.
—Automated tools are required for requirements storage, change
management and traceability management
 Traceability

• Maintains three types of traceability information.

1.Source traceability
--Links the requirements to the stakeholders.
2. Requirements traceability
--Links dependent requirements within the
requirements document.
3. Design traceability
-- Links from the requirements to the design
module.
 REQUIREMENTS CHANGE MANAGEMENT
• Requirement change management is defined
as a process of managing changing
requirements during the requirements
engineering process and system
development.
• Having a requirements change management
system and process in place is crucial since it
ensures that changes are made
systematically, changes are documented for,
and the requirements change management
document is updated
Requirements Change management

Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation

• Consists of three principal stages:

1. Problem analysis and change specification
-- Process starts with a specific change proposal and analysed to
verify that it is valid
2.Change analysis and costing
--Impact analysis in terms of cost, time and risks.
3. Change implementation
--Carrying out the changes in requirements document, system
design and its implementation
 SYSTEM MODELS
• Model is an abstraction of the system being studied.
• System modelling is the process of developing abstract
models of a system, with each model representing
different view or perspective of that system.
• These Exclude low level details of the system
• Uses graphical notation based on UML to represent
the system.
• These models are used
• To help derive the requirements during the
requirements engineering process.
• To describe the system to engineers implementing
the system during the design phase
• To document the system structure and operation after
implementation .
• Models of existing system are used during requirements engineering
to clarify what the system does and its strengths and weaknesses.
• These may lead to obtain requirements for the new system.
• Models of new system are used during requirements engineering to
help explain the proposed requirements to the other system
stakeholders.
• Complete or partial system implementation can be generated from
the system models
Benefits of System Modeling :
1. Ease project management tasks.
2. Can provide complete views of a system, as well as detailed
views of subsystems.
3. Clarify structures and relationships.
4. Offer a communication framework for ideas within and between
teams.
5. Can generate new ideas and possibilities.
6. Allow quality assurance and testing scenarios to be generated.

7. Are platform independent.

Models can explain the system from different perspectives:
• An external perspective, where you model the context or environment of
the system.
• An interaction perspective, where you model the interactions between a
system and its environment, or between the components of a system.
• A structural perspective, where you model the organization of a system
or the structure of the data that is processed by the system.
• A behavioral perspective, where you model the dynamic behaviour of
the system and how it responds to events.
Five types of UML diagrams that are the most useful for system modeling:
• Activity diagrams, which show the activities involved in a process or in
data processing.
• Use case diagrams, which show the interactions between a system and its
environment.
• Sequence diagrams, which show interactions between actors and the
system and between system components with respective time.
• Class diagrams, which show the object classes in the system and the
associations between these classes.
• State diagrams, which show how the system reacts to internal and
external events.
System Models Representation
1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
*** Model-driven engineering- Structured
methods.
 CONTEXT MODELS
• A type of architectural model
• Consists of sub-systems that make up an
entire system.Represent the high level
architectural model as simple block diagram
• First step is to identify the subsystems
• Depict each sub system as a named rectangle
• Lines between rectangles indicate associations
between subsystems.
• System boundaries are established to define
what is inside and what is outside the system.
They show other systems that are used or
depend on the system being developed.
Disadvantages
• Context models simply show the other systems in the
environment, not how the system being developed is used
in that environment.
• Concerned with system environment only, doesn't take into
account other systems, which may take data or give data
to the model.
• Hence Context models can be used along with the process
models to show the relations between various systems
and how flow of activities take place inside the system.
• Process models reveal how the system being developed
is used in broader business processes.
• UML activity diagrams may be used to define business
process models.
Activity Diagrams
• Activity diagrams are intended to show the activities that make
up a system process and the flow of control from one activity
to another.
• The start of a process is indicated by a filled circle; the end
by a filled circle inside
another circle.
• Rectangles with round corners represent activities, which are
subprocesses that must be carried out.
• A solid bar is used to indicate activity coordination.
• When the flow from more than one activity leads to a solid bar
then all of these activities must be complete before progress is
possible.
• When the flow from a solid bar leads to a number of activities,
these may be executed in parallel.
• Arrows may be annotated with guards that indicate the
condition when that flow is taken.
Activity Diagram notations
process of involuntary detention
and the role of MHC-PMS
(mental healthcare patient
management system)
 Static models

Dynamic models

System architecture
 OBJECT MODELS
• An object oriented approach is commonly used for interactive systems
development.
• Expresses the systems requirements using objects and developing the
system in an object oriented PL such as java or c++.
• A object class: An abstraction over a set of objects that identifies common
attributes and services or operations that are provided by each object.
• Objects are instances of object class.
• Many objects may be created from a single class.
• Analysis process
-- Identifies objects and object classes.
• Object class in UML
--Represented as a vertically oriented rectangle with three sections
(a) The name of the object class in the top section
(b) The class attributes in the middle section
(c) The operations associated with the object class are in lower section.
 OBJECT MODELS
INHERITANCE MODELS
•A type of object oriented model which involves in
object classes attributes.
•Arranges classes into an inheritance hierarchy with the
most general object class at the top of hierarchy.
•Specialized objects inherit their attributes and services.
•UML notation
-- Inheritance is shown upward rather than
downward.
--Single Inheritance: Every object class inherits its
attributes and operations from a single parent class
--Multiple Inheritance: A class of several parents.
 OBJECT MODELS

OBJECT AGGREGATION
-- Some objects are grouping of other objects.
-- An aggregate of a set of other objects.
-- The classes representing these objects may be modelled
using an object aggregation model.
-- A diamond shape on the source of the link represents the
composition.
OBJECT-BEHAVIORAL MODEL
-- to model the behavior of objects, you have to show how the
operations provided by the objects.
-- Sequence diagram of UML can be used for behavioral
modeling that show the sequence of actions involved .
 Hierarchy of class
Library item
Catalogue number
Acquisition date
Cost
Type
Status
Number of copies
Acquire ()
Catalogue ()
Dispose ()
Issue ()
Return ()

Pub lished item Recorded item

Title Title
Publisher Medium

Book Magazine Film Computer

program
Author Year Director
Edition Date of r elease Version
Issue
Publication date Distributor Platform
ISBN
 Object aggregation
Study pack
Course title
Number
Year
Instructor

Assignment OH P slides Lecture Videota pe

notes
Credits Slides Text Tape ids .

Exercises Solutions
#Pr ob lems Text
Description Diagrams
 Object behavioural model
Sequence diagram
Student
OBJECT BEHAVIORAL MODEL
Ecat: Lib1:
:Library Item
Catalog NetServer

:Library User

Lookup

Display

Issue
Issue licence

Accept licence

Compress

Deliver
 Behavioural Models
• Behavioural models are models of the dynamic behaviour
of a system as it is executing.
• They show what happens or what is supposed to
happen when a system responds to a stimulus from its
environment.
• Two types of stimuli:
• Some data arrives that has to be processed by the
system.
• Some event happens that triggers system processing.
Events may have associated data, although this is not
always the case.
• Two types of behavioural model based on the stimuli :
1. Data Flow models
2. State machine models/ Event driven models
 Data Flow Diagram
Insulin pump DFD

Blood
Blood parameters
Blood sugar Blood sugar Blood sugar
sensor analysis level

Insulin
requir ement
computa tion
Pump contr ol
Insulin commands Insulin Insulin
Insulin deli very requir ement
pump contr oller
 Behavioural Model
Data Flow Diagram
Data flow diagram is graphical representation of flow of data in an
information system. It is capable of depicting incoming data flow, outgoing
data flow and stored data. The DFD does not mention anything about how
data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart
depicts flow of control in program modules. DFDs depict flow of data in the
system at various levels. DFD does not contain any control or branch
elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
• Logical DFD - This type of DFD concentrates on the system process,
and flow of data in the system.For example in a Banking software
system, how data is moved between different entities.
• Physical DFD - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the
implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data
using the following set of components -

• Entities - Entities are source and destination of information data.

Entities are represented by a rectangles with their respective
names.
• Process - Activities and action taken on the data are represented
by Circle or Round-edged rectangles.
• Data Storage - There are two variants of data storage - it can
either be represented as a rectangle with absence of both smaller
sides or as an open-sided rectangle with only one side missing.
• Data Flow - Movement of data is shown by pointed arrows. Data
movement is shown from the base of arrow as its source towards
head of the arrow as destination.
Levels of DFD
• Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level
0 DFDs are also known as context level DFDs.
» Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD.
Level 1 DFD depicts basic modules in the system and flow of data among
various modules. Level 1 DFD also mentions basic processes and sources of
information.

» Level 2 - At this level, DFD shows how data flows inside the
modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower
level DFDs with deeper level of understanding unless the desired
level of specification is achieved
 Control flow diagram
• The CFD contains the same processes as the DFD, but shows
control flow, rather than data flow.
• Instead of representing control processes directly within the flow
model, a notational reference (a solid bar) to a control
specification (CSPEC) is used.
• In essence, the solid bar can be viewed as a "window" into an
"executive" (the CSPEC) that controls the processes (functions)
represented in the DFD based on the event that is passed
through the window.
• The CSPEC, is used to indicate
• (1) how the software behaves when an event or control signal
is sensed and
• (2) which processes are invoked as a consequence of the
occurrence of the event.
• A process specification(PSPEC) is used to describe the inner
workings of a process represented in a flow diagram.
• The control specification (CSPEC) denoted with
a solid bar can represent a number of important
modelling tools.
• A process activation table is used to indicate
which processes are activated by a given event.
• For example, a process activation table (PAT) for
the above figure might indicate that the above
pressure event would cause a process reduce
tank pressure (not shown) to be invoked.
• In addition to the PAT, the CSPEC may contain a
state transition diagram.
 Behavioural Model
State Machine Models /Event Driven Models
• Describe how a system responds to internal or external
events.
• Shows system states and events that cause transition from
one state to another.
• Does not show the flow of data within the system.
• Used for modelling of real time systems because these systems
are often driven by stimuli from the system’s environment.
– Ex:Microwave oven
• Assumes that at any time, the system is in one of a number of
possible states.
• Stimulus triggers a transition from on state to another state .
Disadvantage
• Number of possible states increases rapidly for large system
models.
State Diagram Of a Microwave
Owen
 Data Models
• Used to describe the logical structure of data processed by the system. These are
sometimes called semantic data models.
• The most widely used data modelling technique is Entity-Relation-Attribute modelling,
which shows the data entries, their associated attributes and the relations between
these entities.
• These are Widely used in database design. The relational database schemas derived
from these models are naturally in third normal form.Can readily be implemented
using relational databases.
• No specific notation provided in the UML but objects and associations can be used.
Data Objects, Attributes, and Relationships
Data objects.
• A data object is a representation of composite information that has a number of different
properties or attributes
• A data object can be an external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or
event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., account-
ing department), a place (e.g., a warehouse), or a structure (e.g., a file)
• The data object description incorporates the data object and all of its attributes.
• Data objects are related to one another.
• A data object encapsulates data only—there is no reference within a data object to
operations that act on the data
Attributes
• Attributes define the properties of a data object and take on one of three different
characteristics.
• They can be used to
(1) name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another table.
• In addition, one or more of the attributes must be defined as an identifier—that is,
the identifier attribute becomes a "key" when we want to find an instance of the data
object
Relationships.
• Data objects are connected to one another in different ways.
• Consider two data objects, book and bookstore.
• A connection is established between book and bookstore because the two objects
are related .We can define a set of object/relationship pairs that define the relevant
relationships.
• A bookstore orders books.
• A bookstore displays books.
• A bookstore stocks books.
• A bookstore sells books.
• A bookstore returns books.
Cardinality and Modality
Cardinality.
• The data model must be capable of representing the number of occurrences objects in a
given relationship
• It is the specification of the number of occurrences of one [object] that can be related to the
number of occurrences of another [object]. Cardinality is usually expressed as simply 'one' or
'many.'
• One-to-one (l:l)—An occurrence of [object] 'A' can relate to one and only one occur-
rence of [object] 'B,' and an occurrence of 'B' can relate to only one occurrence of 'A.'
• One-to-many (l:N)—One occurrence of [object] 'A' can relate to one or many occur-
rences of [object] 'B,' but an occurrence of 'B' can relate to only one occurrence of 'A.' For
example, a mother can have many children, but a child can have only one mother.
• Many-to-many (M:N)—An occurrence of [object] 'A' can relate to one or more occur-
rences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of 'A.' For
example, an uncle can have many nephews, while a nephew can have many uncles.
• Cardinality defines “the maximum number of objects that can participate in a relationship”.
• It does not, however, provide an indication of whether or not a particular data object must
participate in the relationship. To specify this information, the data model adds modality to
the object/relationship pair.

Modality.
• The modality of a relationship is 0 if there is no explicit need for the relationship to occur or
the relationship is optional. The modality is 1 if an occurrence of the relationship is
mandatory.
Student Enrolment system
 Contents of Data Dictionary
• Name—the primary name of the data or control
item, the data store or an external entity.
• Alias—other names used for the first entry.
• Where-used/how-used—a listing of the processes
that use the data or control item and how it is
used (e.g., input to the process, output from the
process, as a store, as an external entity.
• Content description—a notation for representing
content.
• Supplementary information—other information
about data types, preset values (if known),
restrictions or limitations, and so forth.
Data dictionary entries
• A structured method includes a design process model, notations to represent
the design, report formats, rules and design guidelines.
• Structured methods may support some or all of the following models of a
system:
• An object model that shows the object classes used in the system and their
dependencies.
• A sequence model that shows how objects in the system interact when the
system is executing.
• A state transition model that shows system states and the triggers for the
transitions from one state to another.
• A structural model where the system components and their aggregations
are documented.
• A data flow model where the system is modelled using the data
transformations that take place as it is processed. This is not normally used
in object-oriented methods but is still frequently used in real-time and
business system design.
• A use-case model that shows the interactions between users and the
system.
• Function-oriented methods use functions as their central design abstraction
and often start by identifying the data-flow through a system.
• By contrast, object-oriented methods use objects as their abstraction and they
rely on use-cases to describe the processes in the system's environment.