Unit -II

Functional and Non Functional-User -System-Requirement engineering process-Feasibility

studies-Communication Practice_requirement elicitation-Validation and management-
Fundamentals of requirement analysis-Analysis principle-structure system analysis-Software
prototyping-prototyping in the software process-Data-Functional & behavioural model-
structure analysis and Data dictionary.

Functional and Non Functional

Requirements analysis is a very critical process that enables the success of a system or software
project to be assessed. Requirements are generally split into two types: Functional and Non-functional
requirements.
Functional Requirements
These are the requirements that the end user specifically demands as basic facilities that the system
should offer. All these functionalities need to be necessarily incorporated into the system as a part of
the contract.
These are represented or stated in the form of input to be given to the system, the operation performed
and the output expected. They are the requirements stated by the user which one can see directly in
the final product, unlike the non-functional requirements.

Example:

What are the features that we need to design for this system?
What are the edge cases we need to consider, if any, in our design?
Non-Functional Requirements
These are the quality constraints that the system must satisfy according to the project contract. The
priority or extent to which these factors are implemented varies from one project to another. They are
also called non-behavioral requirements. They deal with issues like:

Portability
Security
Maintainability
Reliability
Scalability
Performance
Reusability
Flexibility
Example:
Each request should be processed with the minimum latency?
System should be highly valuable.

Difference between Functional Requirements and Non-Functional Requirements:

Functional Requirements Non Functional Requirements

A functional requirement defines a system or A non-functional requirement defines the

its component. quality attribute of a software system.

It places constraints on “How should the

It specifies “What should the software system
software system fulfill the functional
do?”
requirements?”

Non-functional requirement is specified by

Functional requirement is specified by User. technical peoples e.g. Architect, Technical
leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of the Helps you to verify the performance of the
software. software.

Non-Functional Testing like Performance,

Functional Testing like System, Integration,
Stress, Usability, Security testing, etc are
End to End, API testing, etc are done.
done.

Usually easy to define. Usually more difficult to define.

Example Example
1) Authentication of user whenever he/she 1) Emails should be sent with a latency of no
logs into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be
3) A Verification email is sent to user done within 10 seconds
whenever he/she registers for the first time on 3) The site should load in 3 seconds when the
some software system. number of simultaneous users are > 10000
User -System-Requirement engineering process:
What are User and System Requirements in Software Engineering
A clear statement and documentation of the project requirements, whether it’s user or system
requirements, are among the most essential parts of the software engineering process.

Requirements engineering is the process in which the developers establish the services that the
clients or stakeholders require the system shall deliver as well as the constraints and scope in which it
operates and is developed. Therefore, this round of requirements engineering produces a set of system
requirements, which are a description of the software’s services and constraints.

Generally, this statement of requirements can be either a high-level and abstract declaration of the
system’s services and constraints, or it could be a detailed mathematical and functional specification
as well. This statement of requirements is crucial to the software engineering process as it serves as
the basis for the contract and its bids.

User Requirements

User requirements are statements in natural language along with corresponding diagrams (tables,
forms, intuitive diagrams) detailing the services provided by the system and operational constraints it
must comply with. Additionally, it’s worth noting that user requirements primarily focus on the user’s
needs. Thus, these user requirements cater to the customer.

Essentially, it entails the requirement that the user wants or ability to perform a functionality or action
with the system. So, it outlines the activities a user can perform with the system. User requirements
entail both functional and non-functional requirements that are understandable even by users without
technical knowledge.

These requirements don’t contain details of the system design and don’t use technical expressions or
formal notations. Also, these user requirements are documented in a text as “User Requirements
Document” using narrative text.

System Requirements
On the other hand, system requirements consist of a structured document that details the system’s
functions, services and operational constraints. It’s mainly written and serves as a tool for the
developers of the system to build and implement the system design. It contains the functionality that’s
needed by the system in order for it to fulfil the user requirements.

Along with that, it outlines both the functional and non-functional requirements the system should
fulfil. Hence, it consists of all things the system must contain to construct or develop it. They’re often
described as the expanded version of user requirements that engineers use at the beginning of a
system’s design. Hence, the system requirements serve as a blueprint for the developer to follow
defining the parts of a system that are to be implemented, so it acts as a contract between the client
and contractor.
These requirements can be written in natural language, and also possesses more structured forms and
graphical notations. However, as it’s primarily written for developers it possesses a detailed
description of the project services. It uses natural language and is documented as a System
Requirement Specification (SRS).

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.
Benefits of Feasibility

Feasibility studies provide several advantages, including aiding project directors in understanding the
benefits and drawbacks of performing work before investing significant time and money into it.
Feasibility studies may also provide critical information to an organization's management team,
preventing them from embarking on a risky project.
Such studies help firms decide how they will grow. They will learn how they will function, what
potential roadblocks exist, who their competitors are, and what the market is like. Feasibility studies
can aid in convincing financial backers and brokers that investing in a given project or firm is a
sensible move.

Example of a Feasibility study

The following are two examples of feasibility studies. The first involves college development plans.
The second is a genuine model headed by the Washington State Department of Transportation and
backed by Microsoft Inc.

A Science Building at a College

Authorities at a college were concerned that the science building, which had been in use since the
1970s, was antiquated. Taking into account the most recent 20 years of creative and logical
advancements, they needed to explore the cost and benefits of revamping and expanding the structure.
A feasibility study was conducted.

In the preliminary investigation, school officials considered several options, weighing the benefits and
costs of expanding and renovating the science building. Some school officials were concerned about
the project, particularly the cost and potential community opposition. The new scientific building
would be far larger, and the local area board had already rejected a related proposal. The feasibility
study must address these concerns and potential legal or drafting issues.

The feasibility study also looked at the mechanical needs of the new scientific office, the benefits to
students, and the school's long-term suitability. An updated scientific office would broaden the
school's logical investigation capacities, work on its teaching programme, and attract new students.
Monetary forecasts demonstrated the cost and scope of the project, as well as how the school expected
to obtain the necessary assets, which included appealing to financial backers and leveraging the
institution's approval. The predictions also demonstrated how the expanded office would enable more
understudies to enrol in science programmes, increasing money from educational costs and expenses.

The feasibility analysis demonstrated that moving forward with the scientific building's refurbishment
and expansion plans was reasonable. The school's administrators would never have been able to
determine if their extension plans were feasible without conducting a feasibility assessment.

A High-Speed Railway Project

The Washington State Division of Transportation decided to focus its feasibility study on constructing
a high-speed rail connecting Portland, Oregon, Seattle, Washington, and Vancouver, British
Columbia. The goal was to build a stable natural transportation system to increase the Pacific
Northwest's importance and future prosperity.

An administrative framework for future direction was shown in the initial inquiry. The evaluation
involved talking to experts and partners to determine the optimal administrative system, assessing
administrative designs, and learning from already completed fast rail projects in North America. As a
result, managing and organizing components were developed to oversee and carry out the project,
assuming the state assembly would approve it.

An important commitment strategy includes an objective technique with the general public, selected
authorities, government agencies, corporate visionaries, promotion events, and local networks. The
commitment plan was designed to be flexible, considering the scope, size, and number of cities and
towns that seemed to be involved. A group of leadership council members was established, and they
gathered to discuss policies, provide examples from previous jobs, and consult with experts to create a
system.

What is the Main Objective of a Feasibility Study?

Feasibility analysis is meant to help managers determine if a new business or speculative idea has a
good chance of succeeding. It makes a distinction between general costs and typical benefits.

"Fruitful" in business refers to a situation where the financial gain outweighs the cost. Achievement in
a charity might be measured in several ways. The benefit of an enterprise to the community it serves
could be worth the cost.

Conclusion

A feasibility study focuses on helping project managers assess an undertaking's justification by

identifying factors contributing to its success. The focus also highlights potential speculative gains
and risks to the project's success.

A feasibility study includes a detailed analysis of the resources needed to complete the project as
envisioned. A description of the new product or business, a market analysis, the innovation and effort
necessary, as well as the sources of finance and resources, might all be included in the report. The
report will also include financial predictions, the likelihood of progress, and, finally, a go-or-off-limits
decision.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with the help
of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify
inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also
resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

1. Requirements Elicitation
 It is related to the various ways used to gain knowledge about the project domain and requirements.
The various sources of domain knowledge include customers, business manuals, the existing
software of same type, standards and other stakeholders of the project. The techniques used for
requirements elicitation include interviews, brainstorming, task analysis, Delphi technique,
prototyping, etc. Some of these are discussed here. Elicitation does not produce formal models of
the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps
in providing input to the next stage.

Requirements elicitation is the process of gathering information about the needs and expectations of
stakeholders for a software system. This is the first step in the requirements engineering process
and it is critical to the success of the software development project. The goal of this step is to
understand the problem that the software system is intended to solve, and the needs and
expectations of the stakeholders who will use the system.
There are several techniques that can be used to elicit requirements, including:

 Interviews: These are one-on-one conversations with stakeholders to gather

information about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system,
which can be used to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize and prioritize the requirements obtained from all these
techniques to ensure that they are complete, consistent and accurate.

Requirements Specification
This activity is used to produce formal software requirement models. All the requirements including
the functional as well as the non-functional requirements and the constraints are specified by these
models in totality. During specification, more knowledge about the problem may be required which
can again trigger the elicitation process. The models used at this stage include ER diagrams, data
flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.
Requirements specification is the process of documenting the requirements identified in the analysis
step in a clear, consistent, and unambiguous manner. This step also involves prioritizing and
grouping the requirements into manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system. This document should be understandable by both the
development team and the stakeholders.
There are several types of requirements that are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
2. Non-Functional Requirements: These describe how well the software system should
do it. They specify the quality attributes of the system, such as performance, reliability,
usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.
In order to make the requirements specification clear, the requirements should be written in a
natural language and use simple terms, avoiding technical jargon, and using a consistent format
throughout the document. It is also important to use diagrams, models, and other visual aids to help
communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders and
development team to ensure that they are complete, consistent, and accurate.

Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst after
the requirements collected from the various sources - the requirement received by the customer
written in ordinary language. It is the job of the analyst to write the requirement in technical language
so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a company,
an organization, a set of procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information about all
data items defined in DFDs. At the requirements stage, the data dictionary should at least
define customer data items, to ensure that the customer and developers use the same
definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical representation of
the data for the organization and uses three main constructs i.e. data entities, relationships,
and their associated attributes.

o Software Requirement Validation:

o After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions - If they can
practically implement
o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe
Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured requirements
descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the requirements
engineering process and system development.

New requirements emerge during the process as business needs a change, and a better understanding
of the system is developed.

The priority of requirements from different viewpoints changes during development process.

The business and technical environment of the system changes during the development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project. Hence
they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:

Functional Requirements: Functional requirements define a function that a system or system

element must be qualified to perform and must be documented in different forms. The
functional requirements are describing the behavior of the system as it correlates to the
system's functionality.
Non-functional Requirements: This can be the necessities that specify the criteria that can be
used to decide the operation instead of specific behaviors of the system.

Non-functional requirements are divided into two main categories:

 Execution qualities like security and usability, which are observable at run time.
Evolution qualities like testability, maintainability, extensibility, and scalability that
embodied in the static structure of the software system.

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.

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 functioni

ng.
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=y[a] x includes of y or more occurrences of data element a

x=[a]z x includes of z or fewer occurrences of data element a

x=y[a]z x includes of some occurrences of data 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 he 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.

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.

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.