Scribd
Upload
21 views

Unit 2 Notes Till ST-01

The document outlines the Requirements Engineering Process, which includes phases such as feasibility study, requirements elicitation, specification, validation, and management. It also discusses Data Flow Diagrams (DFD) and Entity-Relationship Diagrams (E-R Diagrams) as tools for representing data flow and database design, respectively. Key concepts include the importance of stakeholder engagement, validation techniques, and the representation of relationships and attributes in information models.

Uploaded by

Avishka Chaudhary
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
21 views

Unit 2 Notes Till ST-01

The document outlines the Requirements Engineering Process, which includes phases such as feasibility study, requirements elicitation, specification, validation, and management. It also discusses Data Flow Diagrams (DFD) and Entity-Relationship Diagrams (E-R Diagrams) as tools for representing data flow and database design, respectively. Key concepts include the importance of stakeholder engagement, validation techniques, and the representation of relationships and attributes in information models.

Uploaded by

Avishka Chaudhary
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Unit 02

Requirement Engineering Process


Requirements Engineering is the process of identifying, eliciting, analyzing,
specifying, validating, and managing the needs and expectations of
stakeholders for a software system.

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
1. Feasibility Study: This is the initial phase of the requirement
engineering process. It involves evaluating the feasibility of the
proposed software project. The main objective is to determine
whether the project is technically, economically, and operationally
viable. During this phase, the following aspects are considered:
o Technical Feasibility: Can the proposed system be developed
with the available technology and resources?
o Economic Feasibility: Is the project economically viable in
terms of cost and benefits?
o Operational Feasibility: Will the system work effectively within
the existing organizational structure and processes?

2. Requirement Elicitation and Analysis: This phase


involves gathering and analyzing requirements from stakeholders,
including users, customers, and domain experts. The goal is to
understand the needs of the system and translate them into specific
software requirements. This process involves several techniques,
such as:
o Interviews: Direct communication with stakeholders to gather
information.
o Surveys: Distributing questionnaires to collect opinions and
preferences.
o Workshops: Group sessions to brainstorm and gather
requirements collaboratively.
o Observation: Actively observing users to understand their
workflow and needs.
o Prototyping: Building a preliminary version of the software to
elicit feedback.
Once requirements are gathered, they are analyzed for consistency,
completeness, and feasibility. Conflicts and ambiguities are resolved, and
the requirements are organized into different categories based on their
characteristics (e.g., functional, non-functional).

3. Software Requirement Specification(SRS) In this


phase, the gathered and analyzed requirements are documented
formally. The Software Requirement Specification (SRS) document is
created, which serves as a blueprint for the development process. The
SRS includes the following components:
o Functional Requirements: Descriptions of what the system
should do in terms of specific functions and features.
o Non-functional Requirements: Constraints and qualities the
system must possess (e.g., performance, security).
o User Interfaces: Descriptions of how users will interact with the
system.
o Data Requirements: Details about the data the system will
store, process, and manage.

4. Software Requirement Validation: This step involves


validating the documented requirements to ensure they accurately
represent the stakeholders' needs and expectations. The aim is to
identify and rectify any errors or misunderstandings before
development begins. Techniques used for requirement validation
include:
o Reviews: Expert reviews and walkthroughs to identify issues in
the SRS.
o Prototyping: Building a working model of the software to validate
requirements.
o Simulation: Simulating the software's behavior to test its
alignment with requirements.
5. Software Requirement Management: Requirement
management is an ongoing process that involves maintaining and
tracking changes to requirements throughout the software
development lifecycle. It includes activities such as:
o Version Control: Managing different versions of the
requirements document.
o Change Control: Managing and documenting changes to
requirements and their impact.
o Traceability: Establishing links between requirements and
design, implementation, and testing.
o Prioritization: Assigning priorities to requirements to guide
development efforts.
o Communication: Ensuring stakeholders are informed about
changes and updates to requirements.

Requirement Reviews

A requirements review is a process that involves evaluating a document that outlines


the requirements for a project. The goal is to ensure that the requirements are clear,
accurate, and complete

Requirement review is the practice of scanning the software errors to make the industry
user-friendly for all.

Methods of performing requirement review

1. Team consultation

2. Understanding the user’s requirement

3. Finding measures to software problem


Data Flow Diagrams (DFD)
DFD Provide communication between user and system designer. DFD is
graphical representation of flow of data in an information system. DFD is also
called as a data flow graph

DFD Advantage
1. Easy to understand
2. System documentation file
3. Better communication with user
4. Elimination of redundancy
5. Easy to check some information missing

DFD Components
There are 4 main components of a DFD:
• External entities
• Processes
• Data stores
• Data flows

• External entities: rectangles


• Processes: circles (Yourdon and Coad) or rectangles with rounded corners
(Gane and Sarson)
• Data stores: parallel lines (Yourdon and Coad) or open-ended rectangles
(Gane and Sarson)
• Data flows: horizontal lines
DFD rules

• Each process should have at least one input and an output.


• Each data store should have at least one data flow in and one data flow
out.
• Data stored in a system must go through a process.
• All processes in a DFD go to another process or a data store.

Types of data flow diagrams (DFD)

1.Logical DFD
2.Physical DFD

Logical DFD Physical DFD

Processes would be business activities Processes would be programs and manual


procedures
Logical DFD depicts how the business How the current system operates/ how the
operates. system will be implemented

Data Store Collection of Information Data Store are Database and Files.

Simple Complex

Levels of data flow diagrams


Level 0
Also called a “context diagram,” a level 0 DFD is a high-level view that visualizes the
entire system as a single process. It is the simplest and most basic of the levels. It should
be easily understandable to anyone who views it, regardless of technical skill or job
role.
Level 1
A level 1 DFD explores the component parts of the high-level process in more detail.
What was a single process in the context-level DFD is broken into subprocesses that
provide more information on the function and data flow pathways.

Level 2
Level 2 provides even more granular details by adding new subprocesses and their
interactions and relationships with data flows and data stores. This level offers a highly
intricate view of the inner operations of a system or process.

Level 3
Because DFDs are intended to be accessible and easy to understand, it is unusual to go
beyond the intricacy of level 2. However, highly complex systems might require the
elaborate detail of a level 3 DFD, which maps every single aspect of a data process or
system.

Information model
Information model in software engineering is a representation of concepts and the
relationships, constraints, rules, and operations to specify data semantics for a chosen
domain of discourse.

it specifies relations between kinds of things, but may also include relations with
individual things.

Information models focus on relationships between managed objects.

Information models are often represented in Unified Modeling Language(UML)


(class) diagrams, but there are also informal information models written in plain
English language

Example
Information model for a school, object types could be things like Student, Teacher,
Class, and Subject. Each object type has certain properties or characteristics, which we
call attribute types. For example, a Student can have attribute types such as Name, Age,
and Student Number
Entity Relationship Diagram (E-R Diagram)
Main components of the E-R model are an entity, attributes, and relationship.
It is a very easy way to represent the database design. E-R digram method are
called Entity-Relationship Diagrams or ER diagrams or ERDs. ER model is
a high-level data model diagram

Components of the ER Diagram


This model is based on three basic concepts:

• Entities
• Attributes
• Relationships

• Entity
Entity is denoted as a rectangle in an ER diagram.
• Attributes
Attributes are represented by means of ellipses. Every ellipse
represents one attribute and is directly connected to its entity
• Relationships
Relationships are represented by the diamond-shaped box
Cardinality
Cardinality describes the number of entities in one entity set.

Types of Cardinalities
One-to-One Relationships
For example -Each student has only one student Roll No

One-to-Many Relationships
For example- Teacher teach many students

Many to One Relationships


For example - Many students can study in a single college

Many-to-Many Relationships
For example - Student can be assigned to many Assignments
.

You might also like