Requirements Analysis

Requirement analysis is significant and essential activity after elicitation. We analyze, refine,
and scrutinize the gathered requirements to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide a graphical view of the
entire system. After the completion of the analysis, it is expected that the understandability
of the project may improve significantly. Here, we may also use the interaction with the
customer to clarify points of confusion and to understand which requirements are more
important than others.
The various steps of requirement analysis are shown in fig:

(i) Draw the context diagram: The context diagram is a simple model that defines the
boundaries and interfaces of the proposed systems with the external world. It identifies the
entities outside the proposed system that interact with the system. The context diagram of
student result management system is given below:
(ii) Development of a Prototype (optional): One effective way to find out what the customer
wants is to construct a prototype, something that looks and preferably acts as part of the
system they say they want.
We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system and
increase the understanding of the requirements. When developers and users are not sure
about some of the elements, a prototype may help both the parties to take a final decision.
Some projects are developed for the general market. In such cases, the prototype should be
shown to some representative sample of the population of potential purchasers. Even
though a person who tries out a prototype may not buy the final system, but their feedback
may allow us to make the product more attractive to others.
The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.
(iii) Model the requirements: This process usually consists of various graphical
representations of the functions, data entities, external entities, and the relationships
between them. The graphical view may help to find incorrect, inconsistent, missing, and
superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship
diagram, Data Dictionaries, State-transition diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will have a better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected. The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the system. Now we
finalize the analyzed requirements, and the next step is to document these requirements in
a prescribed format.
Requirement Analysis
Requirement Analysis is a fundamental step in the software development lifecycle. It ensures
that the software being developed meets the needs and expectations of the stakeholders. It
is a crucial phase where the goals, objectives, and functionalities of the system are clearly
defined.
Requirement Analysis Tasks
1. Elicitation of Requirements: Gathering requirements from stakeholders using
interviews, questionnaires, workshops, and document analysis.
2. Analysis of Requirements: Examining the gathered requirements to ensure they are
clear, complete, consistent, and feasible.
3. Documentation of Requirements: Creating a comprehensive document that specifies
all functional and non-functional requirements.
4. Validation and Verification: Checking if the requirements meet the user’s needs and
if they are achievable within the project’s constraints.
5. Prioritization: Assigning importance to each requirement based on business value
and implementation difficulty.
6. Requirements Modeling: Using diagrams, models, and prototypes to represent how
the system will function and behave.
7. Traceability and Change Management: Maintaining a clear link between the
requirements and the final product. Managing changes effectively through the
project lifecycle.

1. Elicitation of Requirements
Requirement elicitation is the process of gathering information from stakeholders to
understand what the system should do. It's the first step in understanding the system’s
objectives and constraints.
Methods of Elicitation:
 Interviews: One-on-one meetings with stakeholders to ask specific questions and
clarify requirements.
 Questionnaires: A set of structured questions distributed to stakeholders to gather
their needs and preferences.
 Workshops: Collaborative sessions where multiple stakeholders come together to
discuss and brainstorm system requirements.
 Observation: Watching how users interact with the current system or perform tasks
manually to identify areas for improvement.
 Document Analysis: Reviewing existing documentation like process manuals, forms,
and reports to understand current system operations.
Challenges in Elicitation:
 Stakeholders might not fully understand what they want.
 Conflicting requirements from different stakeholders.
 Difficulty in expressing abstract ideas.
Solution: Use multiple elicitation techniques and ensure active communication with
stakeholders.

2. Analysis of Requirements
Once the requirements are gathered, they need to be analyzed to ensure they are clear,
complete, consistent, and feasible.
Key Aspects of Requirement Analysis:
 Clarity: Requirements should be unambiguous. Vague terms like "good performance"
should be replaced with specific metrics like "response time under 2 seconds."
 Completeness: All necessary functionalities must be captured. Missing requirements
can lead to project failures or extensive rework.
 Consistency: There should be no conflicting requirements. For example, if one
requirement states that the system should be available 24/7, another requirement
asking for scheduled downtime would be inconsistent.
 Feasibility: The requirement should be achievable with the given budget, technology,
and timeline.
Techniques for Requirement Analysis:
 SWOT Analysis: Analyze the Strengths, Weaknesses, Opportunities, and Threats
related to each requirement.
 Risk Analysis: Identify potential risks associated with certain requirements and
determine their impact on the project.

3. Documentation of Requirements
Once requirements are analyzed, they need to be documented in a way that is
understandable by all stakeholders, including developers, testers, and clients.
Types of Requirement Documents:
 Business Requirements Document (BRD): High-level requirements focused on
business objectives.
 Software Requirements Specification (SRS): Detailed document specifying both
functional and non-functional requirements.
o Functional Requirements: Describe what the system should do (e.g., "The
system must allow users to log in with a username and password").
o Non-functional Requirements: Describe the system’s attributes (e.g.,
performance, scalability, security).
Importance of Documentation:
 Provides a clear reference point for developers and testers.
 Acts as a contract between stakeholders and developers.
 Helps manage scope and prevent scope creep by clarifying what is included or
excluded in the project.
4. Validation and Verification
After documenting the requirements, it's essential to validate and verify them.
Validation: Ensuring the requirements align with what stakeholders need. Validation answers
the question: "Are we building the right system?"
 Techniques:
o Prototyping.
o Review sessions with stakeholders.
o Simulations.
Verification: Checking that the requirements are achievable and well-documented.
Verification answers the question: "Are we building the system right?"
 Techniques:
o Peer reviews.
o Requirement walkthroughs.
o Checking requirements against the project scope and constraints.

5. Prioritization
Not all requirements can or should be implemented immediately, especially when there are
resource constraints. Prioritization helps determine which requirements should be
implemented first.
Techniques for Prioritizing Requirements:
 MoSCoW Method: Categorize requirements into:
o Must-have: Critical for the system to function.
o Should-have: Important but not critical.
o Could-have: Nice to have but not essential.
o Won't-have: Not necessary for the current release but can be included in
future versions.
 Kano Model: Classifies requirements based on customer satisfaction:
o Basic Needs: Must be included, and users expect them (e.g., login
functionality).
o Performance Needs: More of these increase customer satisfaction (e.g.,
system response time).
o Excitement Needs: Unexpected features that delight customers (e.g.,
personalized recommendations).
Importance of Prioritization:
 It ensures that the team focuses on the most critical features first.
 Helps manage time, budget, and resources effectively.
 Reduces the risk of missing deadlines by focusing on high-priority tasks.
6. Requirements Modeling
Modeling helps visualize requirements and understand how the system will behave. This
step converts requirements into diagrams, models, or prototypes to provide a clear picture
of the system.
Common Modeling Techniques:
 Use Case Diagrams: Depict interactions between users (actors) and the system,
showing what the system will do for each user role.
 Activity Diagrams: Represent workflows and how different processes in the system
interact.
 Class Diagrams: Visualize the data structures, including the relationships between
entities (e.g., classes in an object-oriented system).
 Prototyping: Build a working model (a mockup or a scaled-down version) of the
system to show stakeholders how it will function.
Purpose of Requirements Modeling:
 Helps identify gaps or inconsistencies in requirements.
 Provides a visual aid that stakeholders and developers can understand more easily
than text-based requirements.
 Allows for better communication and feedback during early stages.

7. Traceability and Change Management

In a dynamic project environment, requirements might change during the lifecycle.
Requirement traceability and change management ensure that these changes are managed
effectively.
Traceability:
 Requirement Traceability Matrix (RTM): A document that tracks requirements
through all stages of the project (from elicitation to testing). It ensures that all
requirements are accounted for in the final product.
 Benefits:
o Ensures that no requirement is overlooked.
o Provides a way to track changes and their impact on the project.
Change Management:
 Requirements can evolve due to new business needs, technological changes, or
stakeholder feedback.
 Process for Managing Changes:
o Change Request: A formal request to modify or add a requirement.
o Impact Analysis: Assess how the change will affect the project in terms of
cost, time, and scope.
o Approval: Get approval from key stakeholders before implementing any
changes.
o Implementation: Ensure the change is implemented in the system and
reflected in all related documents.
Importance of Change Management:
 Controls scope creep, which can lead to budget overruns or delays.
 Ensures transparency and accountability when requirements are modified.
Analysis Principles
1. Understand the Problem: Before diving into solutions, it is essential to have a
thorough understanding of the problem.
2. Separation of Concerns: Break down the problem into smaller parts for better
manageability.
3. Abstraction: Simplify complex systems by focusing on higher-level operations first,
and detail out the specifics later.
4. Prototyping: Build a simplified version of the system to clarify requirements and
receive feedback from users.
5. Modeling: Use models (e.g., flowcharts, data flow diagrams) to represent the
system’s behavior and structure.
6. Progressive Refinement: Gradually detail out the requirements as more is
understood about the system.
7. Iteration: Revisit requirements and models to refine and adjust based on feedback
and new information.

1. Understand the Problem

Before attempting to solve any problem, it's crucial to have a comprehensive understanding
of what the problem actually is. Diving into solutions without understanding the root cause
or the full scope often leads to incomplete or incorrect solutions.
Key Aspects:
 Stakeholder Needs: Who are the end-users? What are their expectations and
challenges? It’s essential to know what problem you're solving from the stakeholders'
perspective.
 Domain Knowledge: Understanding the domain (industry) in which the system will
operate is crucial. For example, a banking system will have vastly different
requirements than an e-commerce website.
 Existing Systems: It's beneficial to analyze if any existing systems are already in place
and why they aren't sufficient.
Importance: A deep understanding of the problem ensures that the development team
doesn't make incorrect assumptions. It helps in designing the right solution that meets the
users’ actual needs, rather than an imagined set of needs.

2. Separation of Concerns
This principle involves breaking down a complex problem into smaller, manageable parts or
modules. Each of these parts can then be addressed independently, without being
overwhelmed by the complexity of the whole.
Key Aspects:
 Modular Design: Divide the system into different modules (e.g., UI, business logic,
database management). Each module should handle a specific responsibility.
  Independent Development: When concerns are separated, teams can work on
different modules concurrently, leading to more efficient development.
 Maintainability: Systems that follow this principle are easier to maintain and extend.
If one module needs to be updated, it can be modified without affecting the entire
system.
Example: In a software system, the user interface (UI) can be designed independently of the
business logic or database systems. The UI focuses solely on how users interact with the
system, while the business logic handles calculations or data processing, and the database
stores information.
Importance: Separation of concerns makes the system more manageable, less error-prone,
and easier to test and maintain.

3. Abstraction
Abstraction involves simplifying complex systems by focusing on the essential details first
and hiding the complexities until necessary. It allows developers and stakeholders to
concentrate on high-level functionality before dealing with technical details.
Key Aspects:
 High-Level Focus: Focus on what the system needs to do, rather than how it will do
it. For example, describing that a user can "make a purchase" without detailing every
step of the purchase process initially.
 Layered Approach: Start by defining broad categories (e.g., user interactions, system
responses), and progressively refine them as more is known about the system.
 Hide Complexity: Hide intricate technical details from non-technical stakeholders to
keep discussions productive and understandable.
Example: Think of a car’s interface — the driver only needs to know how to operate the
steering wheel, gas pedal, and brakes. The complex internal combustion process is
abstracted away from the driver’s view.
Importance: Abstraction simplifies the system design process by helping teams focus on key
functionalities without being bogged down by implementation specifics too early.

4. Prototyping
Prototyping involves creating a simplified, working model of the system to clarify the
requirements and gain user feedback. This prototype acts as an early version of the product,
showing how the system will function without implementing all features.
Key Aspects:
 Clarification of Requirements: A prototype helps stakeholders see how the system
will look and behave. It can reveal misunderstood requirements or gaps that were
not initially apparent.
 Feedback Mechanism: Prototypes allow stakeholders to provide feedback early,
which can lead to refinement of the design and functionality.
  Risk Reduction: By building a prototype, teams can identify potential issues with
usability, design, or functionality before investing significant time and resources.
Example: A software team may build a basic version of an online shopping cart that lets
users add items and proceed to checkout. The prototype can show users how the checkout
process will flow, without integrating complex payment systems yet.
Importance: Prototyping ensures that both developers and stakeholders are on the same
page before moving forward with full development. It reduces the risk of miscommunication
and costly rework.

5. Modeling
Modeling refers to the use of diagrams and formal representations to describe the system’s
behavior, structure, and interactions. It helps visualize the system, making complex
structures easier to understand.
Types of Models:
 Flowcharts: Represent the flow of logic and processes within the system.
 Data Flow Diagrams (DFD): Show how data moves through the system and where it
is processed or stored.
 Entity-Relationship Diagrams (ERD): Represent how different data entities (e.g.,
customer, product) relate to each other in a system.
 Use Case Diagrams: Visualize the interactions between users (actors) and the
system’s functionalities.
Benefits:
 Clear Communication: Models provide a clear way to represent complex systems,
making it easier for both technical and non-technical stakeholders to understand.
 Problem Identification: By visualizing the system, it's easier to identify flaws, gaps, or
inconsistencies in the requirements.
 Documentation: Models serve as a part of the system’s documentation, which can be
referenced throughout the project lifecycle.
Importance: Modeling improves the clarity of system requirements, ensures all parties have
a shared understanding, and aids in the detection of inconsistencies or issues early on.

6. Progressive Refinement
Progressive refinement involves starting with a high-level overview of the system and
gradually adding more detail as understanding improves. This iterative approach helps refine
the system's requirements and design as more knowledge becomes available.
Key Aspects:
 Top-Down Approach: Start by identifying the major components and gradually break
them down into more detailed sub-components.
 Incremental Detailing: As more is understood about user needs and technical
constraints, additional details can be incorporated into the system.
  Adaptive: Allows flexibility to adapt as new insights are gained or requirements
change over time.
Example: Initially, the system might be described as "user can place an order." Over time,
this could be refined into detailed steps like "user selects a product, adds it to cart, provides
payment information, and receives a confirmation."
Importance: Progressive refinement prevents teams from getting stuck in unnecessary
details too early, while ensuring that all critical aspects are eventually addressed.

7. Iteration
Iteration is the process of revisiting and refining the system requirements, design, and
models as new information comes to light. This principle emphasizes the fact that
understanding of the system evolves over time, and early assumptions might need to be
revisited.
Key Aspects:
 Continuous Improvement: Repeatedly revisiting and refining models and designs
ensures that the system stays aligned with stakeholder needs and project constraints.
 Feedback-Driven: Each iteration should be based on feedback from users,
stakeholders, or team members, allowing the system to evolve in response to real-
world needs.
 Risk Management: Iteration allows teams to address new risks or challenges as they
arise, instead of being locked into decisions made at the beginning of the project.
Example: After building a prototype, developers receive feedback that the user interface is
too complex. They return to the design phase to simplify it, then revisit development with
the refined requirements.
Importance: Iteration ensures that the system evolves as new insights are gained, reducing
the likelihood of major issues or rework later in the development process.

Software Prototyping and Specification

Software Prototyping
Software prototyping is the process of creating an incomplete, working version of the
software to simulate parts of the final product. It helps gather early feedback and refine
requirements.
Types of Prototypes:
1. Throwaway Prototyping: The prototype is developed to clarify requirements but is
discarded before the final system is built.
2. Evolutionary Prototyping: The prototype evolves into the final product through
iterative refinement.
3. Incremental Prototyping: Different components of the system are developed as
separate prototypes and later integrated.
4. Extreme Prototyping: Common in web development, where the prototype is built in
phases.
Advantages:
 Provides early feedback from stakeholders.
 Helps in identifying issues and gaps in requirements early.
 Increases user involvement and satisfaction.
Disadvantages:
 May increase development cost if the prototype is not used effectively.
 Can lead to scope creep if not managed well.
Specification
A software specification is a formal document that defines what the system should do, how
it should behave, and any constraints that apply.
Techniques for Specification:
 Formal Specification: Mathematical description of system properties and behavior.
 Informal Specification: Plain text descriptions, often in natural language.
 Data Dictionary: A central repository of information about the data elements in the
system, including their names, descriptions, and relationships.
Finite State Machine (FSM) Models
A Finite State Machine (FSM) is a mathematical model used to describe the behavior of a
system. FSMs consist of:
 States: Distinct modes of operation of the system.
 Transitions: The rules or conditions for moving from one state to another.
 Events: Inputs or actions that trigger state changes.
 Initial State: The starting point of the FSM.
 Final State: The state in which the system stops.
Types of FSMs:
1. Deterministic Finite Automata (DFA): For every input, the machine can move to only
one state.
2. Non-deterministic Finite Automata (NFA): The machine can move to one or more
states for a given input.
FSMs are commonly used in:
 Control systems.
 Parsing systems.
 Protocol design.

Structured Analysis
Structured analysis is a systematic technique used to break down complex systems into more
manageable components.
Data Flow Diagrams (DFD)
A Data Flow Diagram (DFD) represents the flow of information within a system. It shows
how data moves between processes, data stores, and external entities.
Elements of DFD:
 Process: Represents an activity that transforms inputs into outputs.
 Data Store: Storage of data for later use.
 Data Flow: Movement of data between processes, data stores, and external entities.
 External Entity: Objects or people outside the system that interact with it.
Types of DFD:
1. Context Diagram: High-level DFD showing the entire system and its interactions with
external entities.
2. Level-1 DFD: More detailed DFD showing internal processes and data flows.
Control Flow Diagrams (CFD)
Control flow diagrams focus on the flow of control in a system, rather than data. They show
the sequence of operations, decisions, and branching within the system.
Process Specification (P-Spec)
A Process Specification provides detailed descriptions of each process in the DFD, including
how inputs are transformed into outputs.
Behavioral Modeling
Behavioral modeling represents the dynamic behavior of a system. It describes how the
system will behave over time and in response to different events.
Types of Behavioral Models:
1. State Transition Diagrams: Show how the system transitions from one state to
another based on events.
2. Activity Diagrams: Show the sequence of activities and decisions in a process.
Data Dictionary
A Data Dictionary is a central repository that defines all data elements in a system. It
includes descriptions, data types, allowed values, and relationships between data elements.
Example of a Data Dictionary Entry:
 Data Element Name: Customer_ID
 Description: Unique identifier for a customer.
 Data Type: Integer
 Allowed Values: Any positive integer.
 Relationships: Associated with orders, payments, etc.

Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where
data is stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a part
in the order that acts as a starting point for redesigning a system. The DFD is also called as a
data flow graph or bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in
a DFD, suppress that urge! A diamond-shaped box is used in flow charts to
represents decision points with multiple exists paths of which the only one is taken.
This implies an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data store.
Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes
in a different order. The data store can have an element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.
Levels in Data Flow Diagrams (DFD)
The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFDM
It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with multiple
bubbles. Parts of the system represented by each of these bubbles are then decomposed
and documented as more and more detailed DFDs. This process may be repeated at as many
levels as necessary until the program at hand is well understood. It is essential to preserve
the number of inputs and outputs between levels, this concept is called leveling by
DeMacro. Thus, if bubble "A" has two inputs x 1 and x2 and one output y, then the expanded
DFD, that represents "A" should have exactly two external inputs and one external output as
shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in
fig. As the bubbles are decomposed into less and less abstract bubbles, the corresponding
data flow may also be needed to be decomposed.
1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this
level, we highlight the main objectives of the system and breakdown the high-level process
of 0-level DFD into subprocesses.

2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning.
Data Dictionaries
A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership, data
relationships to other objects, and other data. The data dictionary is an essential component
of any relational database. Ironically, because of its importance, it is invisible to most
database users. Typically, only database administrators interact with the data dictionary.
The data dictionary, in general, includes information about the following:
o Name of the data item
o Aliases
o Description/purpose
o Related data items
o Range of values
o Data structure definition/Forms
The name of the data item is self-explanatory.
Aliases include other names by which this data item is called DEO for Data Entry Operator
and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is used for or why it
exists.
Related data items capture relationships between data items e.g., total_marks must always
equal to internal_marks plus external_marks.
Range of values records all possible values, e.g. total marks must be positive and between 0
to 100.
Data structure Forms: Data flows capture the name of processes that generate or receive
the data items. If the data item is primitive, then data structure form captures the physical
structures of the data item. If the data is itself a data aggregate, then data structure form
capture the composition of the data items in terms of other data items.
The mathematical operators used within the data dictionary are defined in the table:

Notations Meaning

x=a+b x includes of data elements a and b.

x=[a/b] x includes of either data elements a or b.

x=a x includes of optimal data elements a.

x includes of y or more occurrences of data

x=y[a]
element a

x includes of z or fewer occurrences of data

x=[a]z
element a
 x includes of some occurrences of data
x=y[a]z
element a which are between y and z.
Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a
conceptual data model of an information system. Diagrams created using this ER-modeling
method are called Entity-Relationship Diagrams or ER diagrams or ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.
Components of an ER Diagrams

1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely
identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school
database, students, teachers, classes, and courses offered can be treated as entities. All
these entities have some attributes or properties that give them their identity.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities
with attribute sharing similar values. For example, a Student set may contain all the students
of a school; likewise, a Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values.
For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot
be negative, etc.

There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an
entity among the entity set. For example, the roll_number of a student makes him
identifiable among students.
There are mainly three types of keys:
1. Super key: A set of attributes that collectively identifies an entity in the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An entity set may
have more than one candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.
2. Composite attribute: An attribute that is a combination of other attributes is called a
composite attribute. For example, In student entity, the student address is a composite
attribute as an address is composed of other characteristics such as pin code, state, country.
3. Single-valued attribute: Single-valued attribute contain a single value. For example,
Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a
multi-valued attribute. Multi-valued attributes are depicted by the double ellipse. For
example, a person can have more than one phone number, email-address, etc.

5. Derived attribute: Derived attributes are the attribute that does not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, age can be derived from date_of_birth. In the ER diagram, Derived attributes are
depicted by the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships are represented by
the diamond-shaped box. For example, an employee works_at a department, a student
enrolls in a course. Here, Works_at and Enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a
relationship too can have attributes. These attributes are called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the degree of the
relationship. The three most common relationships in E-R models are:
1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is a relationship between
the instances of one entity type. For example, one person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two entity types. For
example, the Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the
relationships "may have" provide the association of three entities, i.e., TEACHER, STUDENT,
and SUBJECT. All three entities are many-to-many participants. There may be one or many
participants in a ternary relationship.
In general, "n" entities can be related by the same relationship and is known as n-
ary relationship.

Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with
the number of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of
entity set B and vice versa. Let us assume that each student has only one student ID, and
each student ID is assigned to only one person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one
instances of another entity then it is called one to many relationships. For example, a client
can place many orders; a order cannot be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A. For example - many students can study in a single college, but a
student cannot study in many colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B
and vice-versa. For example, the student can be assigned to many projects, and a project can
be assigned to many students.

Using Sets, it can be represented as: