Unit - 2
Information Requirement Analysis
Requirement Analysis
Requirements analysis or requirements engineering is a process used to determine
the needs and expectations of a new product. It involves frequent communication
with the stakeholders and end-users of the product to define expectations, resolve
conflicts, and document all the key requirements.
One of the greatest challenges faced by any organization is to share the vision of
the final product with the customers. Hence, a business requirements
analysis involves a team effort of all the key stakeholders, software developers,
end-users, and customer managers to achieve a shared understanding of what the
product should do. This is always done in the early phase of any project to ensure
that the final product conforms to all the requirements.
Requirement analysis starts with:
1. Requirement gathering which is also called as elicitation.
2. This is followed by analyzing the collected requirements to understand the
correctness and feasibility of converting these requirements into a possible
product.
3. And finally, documenting the requirements collected.
To make sure that all the steps mentioned above are appropriately executed, clear,
concise, and correct requirements must be gathered from the customer. The
customer should be able to define their requirements properly and the business
analyst should be able to collect it the same way the customer is intending it to
convey.
1) Requirement Gathering
To make sure that all the steps mentioned above are appropriately executed, clear,
concise, and correct requirements must be gathered from the customer. The
customer should be able to define their requirements properly and the business
analyst should be able to collect it the same way the customer is intending it to
convey.
2) Analyzing Gathered Requirements
Post requirement gathering, analysis of requirement starts. At this stage, various
stakeholders sit and do a brainstorming session. They analyze the requirements
gathered and look for feasibility to implement them. They discuss with each other
and any ambiguity is sorted out.
, 3) Documenting Analyzed Requirements
Once the analysis of requirements is done requirement documentation starts.
Various types of requirements come out of the analysis of requirements.
Some of these are:
(i) Customer Requirement specification.
(ii) Software Architecture requirement.
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
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 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.
Information Requirement Analysis
Requirement Analysis
Requirements analysis or requirements engineering is a process used to determine
the needs and expectations of a new product. It involves frequent communication
with the stakeholders and end-users of the product to define expectations, resolve
conflicts, and document all the key requirements.
One of the greatest challenges faced by any organization is to share the vision of
the final product with the customers. Hence, a business requirements
analysis involves a team effort of all the key stakeholders, software developers,
end-users, and customer managers to achieve a shared understanding of what the
product should do. This is always done in the early phase of any project to ensure
that the final product conforms to all the requirements.
Requirement analysis starts with:
1. Requirement gathering which is also called as elicitation.
2. This is followed by analyzing the collected requirements to understand the
correctness and feasibility of converting these requirements into a possible
product.
3. And finally, documenting the requirements collected.
To make sure that all the steps mentioned above are appropriately executed, clear,
concise, and correct requirements must be gathered from the customer. The
customer should be able to define their requirements properly and the business
analyst should be able to collect it the same way the customer is intending it to
convey.
1) Requirement Gathering
To make sure that all the steps mentioned above are appropriately executed, clear,
concise, and correct requirements must be gathered from the customer. The
customer should be able to define their requirements properly and the business
analyst should be able to collect it the same way the customer is intending it to
convey.
2) Analyzing Gathered Requirements
Post requirement gathering, analysis of requirement starts. At this stage, various
stakeholders sit and do a brainstorming session. They analyze the requirements
gathered and look for feasibility to implement them. They discuss with each other
and any ambiguity is sorted out.
, 3) Documenting Analyzed Requirements
Once the analysis of requirements is done requirement documentation starts.
Various types of requirements come out of the analysis of requirements.
Some of these are:
(i) Customer Requirement specification.
(ii) Software Architecture requirement.
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
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 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.
