Requirement Engineering Process:

1. The process of defining, documentation, and maintenance of

requirements in the design process of engineering is called
requirements engineering.
2. It provides an apt mechanism to understand the customer’s desires,
analysis of needs of the customer, feasibility assessment,
negotiations for a reasonable solution, clarity in the specification of
the solution, specifications validation, and requirements
management.
3. In contrast, the requirements are being transferred to the working
system.

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 the same
type, standards and other stakeholders of the project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, prototyping, etc.

1. Analysis

Requirement analysis is a 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.

1. Documentation

Typically created in the beginning of a software development project. Has

the goal to clearly and precisely specify the expectations in regards to the
software being created. May include functional requirements, limitations,
hardware or software requirements, compatibility requirements, and so on.

1. Review and Management of User Needs

This is a process in which people from client & contractor organizations are
both involved in checking the requirements for omission. Different parts of
the document are checked by different people involved in this type of
activity. Various activities performed during user needs review process
are:

 Plan a review
 Review meeting
 Follow-up actions
 Checking for redundancy
 Completeness
 Consistency
Uses and Significance of Requirement Engineering:
The Requirement Engineering (RE) is the most important phase of the
Software Development Life Cycle (SDLC). This phase is used to translate
the imprecise, incomplete needs and wishes of the potential users of
software into complete, precise and formal specifications.
Uses:
The purpose of requirements engineering methodologies is to make the
problem that is being stated clear and complete, and to ensure that the
solution is correct, reasonable, and effective.

Feasibility Study
When we are developing a system we know whether the proposed system
will be feasible or not i.e. practically implementable or not? It may be
possible that the proposed system may not be implementable due to many
reasons like it may take longer in development than the specified time limit,
cost may increase than proposed.
Purpose:
“evaluation or analysis of the potential impact of a proposed project
or program.”
There may be several types of feasibility depending on the aspects they
cover. Some of them are:

1. Technical Feasibility
2. Operation Feasibility
3. Economical Feasibility

Phases of Feasibility:
Technical feasibility-The technical feasibility study basically centers on
alternatives for hardware, software and design approach to determine the
functional aspects of a system. The technical issues raised during
feasibility are:

1. Does the necessary technology exist?

2. Does the proposed equipment have technical capacity to hold data?
3. Can the system be expended, if developed?
4. Are there technical guarantee of accuracy, reliability and security of
data

Operational feasibility-Operational feasibility is a measure of how people

are able to work with a system. This type of feasibility demands if the
system will work when developed and installed.
Economical Feasibility -Economic feasibility determines whether the
required software is capable of generating financial gains for an
organization. It involves the cost incurred on the software development
team, estimated cost of hardware and software, cost of performing
feasibility study, and so on.
Information Modelling

 An 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.
 Typically it specifies relations between kinds of things, but may also
include relations with individual things.
 It can provide a sharable, stable, and organized structure of
information requirements or knowledge for the domain context.
 Information model is usually an abstract, formal representation of
entity types that may include their properties, relationships and the
operations that can be performed on them.
 The entity types in the model may be kinds of real-world objects,
such as devices in a network, or occurrences, or they may
themselves be abstract, such as for the entities used in a billing
system.
 Typically, they are used to model a constrained domain that can be
described by a closed set of entity types, properties, relationships
and operations.

Data Flow Diagrams

A data-flow diagram is a way of representing a flow of data through a
process or a system (usually an information system).The DFD also
provides information about the outputs and inputs of each entity and the
process itself. A data-flow diagram has no control flow, there are no
decision rules and no loops.It is a graphical tool because it presents a
picture.It presents a system or software at any level of abstraction.
Four simple notations are used to complete a DFD-
i. Data Flow-The data flow is used to describe the movement of
information from a part of the system to another part.
ii. Process-A circle or bubble represents a process that transforms
incoming data to outgoing data.
iii. External Entity- A square defines a source or destination of system
data. External entities represent any entity that supplies information from
the system.
iv. Data Store- The data store is used to collect data at rest or a temporary
repository of data.
Example:
Components of DFD
The Data Flow Diagram has 4 components:
 Process Input to output transformation in a system takes place
because of process function. The symbols of a process are
rectangular with rounded corners, oval, rectangle or a circle. The
process is named a short sentence, in one word or a phrase to
express its essence
 Data Flow Data flow describes the information transferring between
different parts of the systems. The arrow symbol is the symbol of data
flow. A relatable name should be given to the flow to determine the
information which is being moved. Data flow also represents material
along with information that is being moved. Material shifts are
modeled in systems that are not merely informative. A given flow
should only transfer a single type of information. The direction of flow
is represented by the arrow which can also be bi-directional.
 Warehouse The data is stored in the warehouse for later use. Two
horizontal lines represent the symbol of the store. The warehouse is
 simply not restricted to being a data file rather it can be anything like a
folder with documents, an optical disc, a filing cabinet. The data
warehouse can be viewed independent of its implementation. When
the data flow from the warehouse it is considered as data reading and
when data flows to the warehouse it is called data entry or data
updating.
 Terminator The Terminator is an external entity that stands outside of
the system and communicates with the system. It can be, for example,
organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the model
system and is an external entity. Modeled systems also communicate
with terminator.

Rules for creating DFD

 The name of the entity should be easy and understandable without
any extra assistance(like comments).
 The processes should be numbered or put in ordered list to be
referred easily.
 The DFD should maintain consistency across all the DFD levels.
 A single DFD can have a maximum of nine processes and a minimum
of three processes.
Symbols Used in DFD
 Square Box: A square box defines source or destination of the
system. It is also called entity. It is represented by rectangle.
 Arrow or Line: An arrow identifies the data flow i.e. it gives
information to the data that is in motion.
 Circle or bubble chart: It represents as a process that gives us
information. It is also called processing box.
 Open Rectangle: An open rectangle is a data store. In this data is
store either temporary or permanently.
Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can
be created. Levels of DFD are as follows:
 0-level DFD: It represents the entire system as a single bubble and
provides an overall picture of the system.
 1-level DFD: It represents the main functions of the system and how
they interact with each other.
 2-level DFD: It represents the processes within each function of the
system and how they interact with each other.
 3-level DFD: It represents the data flow within each process and how
the data is transformed and stored.
Advantages of DFD
 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it
helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of
system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or
nontechnical person because they are very easy to understand.

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.

Notations for ERD:

Purpose of ERD:

 The database analyst gains a better understanding of the data to be

contained in the database through the step of constructing the ERD.
 The ERD serves as a documentation tool.
  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.

Example of ERD:

Decision Tables
A Decision Table is a tabular representation of inputs versus
rules/cases/test conditions. It is a very effective tool used for both complex
software testing and requirements management. Decision table helps to
check all possible combinations of conditions for testing and testers can
also identify missed conditions easily. The conditions are indicated as
True(T) and False(F) values.
Purpose:
The purpose of a decision table is to show a logical structure, with all
possible combinations of conditions and resulting actions.They provide a
clear method to verify testing of all pertinent combinations to ensure that all
possible conditions, relationships, and constraints are handled by the
software under test.
How to create a decision table?
At first fill in the Y/N patterns. Next, each column or rule represents a
different set of conditions, analyze the logic and show the outcome of each
rule.
Example:

Importance:

1. It assists in development process with developer to do a better job.

Testing with all combination might be impractical.
2. A decision table is basically an outstanding technique used in both
testing and requirements management.
3. It is a structured exercise to prepare requirements when dealing with
complex business rules.

Decision Table Designed for Test looks like:

SRS Document:
A software requirements specification (SRS) is a document that
captures a complete description about how the system is expected to
perform. It is usually signed off at the end of requirements engineering
phase.It also describes the functionality the product needs to fulfill all
stakeholders (business, users) needs.

A typical SRS includes:

 A purpose
 An overall description
 Specific requirements
The best SRS documents define how the software will interact when
embedded in hardware — or when connected to other software.
It is not a design document.It contains functional and nonfunctional
requirements only. System Architects and Programmers write SRS
documents.
Importance of SRS Document?

1. A software requirements specification is the basis for your entire

project. It lays the framework that every team involved in
development will follow.
2. It’s used to provide critical information to multiple teams —
development, quality assurance, operations, and maintenance. This
keeps everyone on the same page.
3. Using the SRS helps to ensure requirements are fulfilled. And it can
also help you make decisions about your product’s lifecycle — for
instance, when to retire a feature.
4. Writing an SRS can also minimize overall development time and
costs. Embedded development teams especially benefit from using
an SRS.

IEEE Standards for SRS

1. Introduction
1. Purpose
2. Scope
3. Definition, Acronyms and abbreviations
4. References
 5. Overview
2. The Overall Description
1. 2.1 Product Perspective
1. System Interfaces
2. Interfaces
3. Hardware Interfaces
4. Software Interfaces
5. Communication Interfaces
6. Memory Constraints
7. Operations
8. Site Adaptation Requirements
2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions for dependencies
6. Apportioning of requirements
3. Specific Requirements
1. External Interfaces
2. Functions
3. Performance requirements
4. Logical database requirements
5. Design Constraints
6. Software System attributes
7. Organization of specific requirements
8. Additional Comments.

Software Quality Assurance(SQA)

Software Quality Assurance (SQA) is a set of activities for ensuring quality
in software engineering processes. It ensures that developed software
meets and complies with the defined or standardized quality specifications.
SQA is an ongoing process within the Software Development Life Cycle
(SDLC) that routinely checks the developed software to ensure it meets the
desired quality measures.It encompasses:

 A quality management approach

 Effective Software engineering technology (methods and tools)
 Formal technical reviews that are tested throughout the software
process
 A multi tiered testing strategy
 Control of software documentation and the changes made to it.
  A procedure to ensure compliances with software development
standards
 Measuring and reporting mechanisms.
Components of SQA:

Verification and Validation

Verification:

 The process of checking documents, design, code, and program in

order to check if the software has been built according to the
requirements or not.
 The main goal of the verification process is to ensure quality of
software application, design, architecture etc.
 Verification is the process of evaluating products of a development
phase to find out whether they meet the specified requirements.
  The verification process involves activities like reviews, walk-
throughs and inspection.

Validation:

 Validation is the process of evaluating software at the end of the

development process to determine whether software meets the
customer expectations and requirements.
 It is a dynamic mechanism of testing and validating if the software
product actually meets the exact needs of the customer or not.
 The process helps to ensure that the software fulfills the desired use
in an appropriate environment.
 The validation process involves activities like unit testing, integration
testing, system testing and user acceptance testing.

SQA Plans
The SQA plan document consists of the below sections:

1. Purpose section
2. Reference section
3. Software configuration management section
4. Problem reporting and corrective action section
5. Tools, technologies and methodologies section
6. Code control section
7. Records: Collection, maintenance and retention section
8. Testing methodology
Abbreviated as SQAP, the software quality assurance plan comprises the
procedures, techniques, and tools that are employed to make sure that a
product or service aligns with the requirements defined in the SRS(software
requirement specification).
The plan identifies the SQA responsibilities of a team, lists the areas that
need to be reviewed and audited. It also identifies the SQA work products.

SQA Activities include:

1) Creating an SQA Management Plan
2) Setting the Checkpoints
3) Apply software Engineering Techniques
4) Executing Formal Technical Reviews
5) Having a Multi- Testing Strategy
6) Enforcing Process Adherence

Software Quality Frameworks

Software Quality Framework is a model for software quality by connecting
and integrating the different views of software quality. This is a framework
that describes all the different concepts relating to quality in a common way
measured by qualitative scale that can be understood and interpreted in a
common way.

1. Developer’s View:

The primary concern for developers is in the design and engineering

processes involved in producing software. Quality can be measured by the
degree of conformance to predetermined requirements and standards, and
deviations from these standards can lead to poor quality and low reliability.
Uses validation and verification to improve the software.

1. Customer’s/User’s View:

End-user programming, a phrase popularized by which is programming to

achieve the result of a program primarily for personal, rather than public
use. The important distinction here is that software itself is not primarily
intended for use by a large number of users with varying needs.

1. Product’s View:

Product quality can be measured by the value-based view which sees the
quality as dependent on the amount a customer is willing to pay for it.
According to the users, a high-quality product is one that satisfies their
expectations and preferences while meeting their requirements.

ISO (International Standards Organization) 9000 Models

The International standards organization (ISO) is a standard which serves
as a contract between independent parties. It specifies guidelines for
development of quality system.The ISO standard mainly addresses
operational methods and organizational methods such as responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production
process and is not directly concerned about the product itself.The ISO 9000
standard determines the guidelines for maintaining a quality system.
Processes involved in ISO 9000

Description of the processes include:

1. Application: Once an organization decides to go for ISO

certification, it applies to the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough
assessment of the organization.
3. Document review and Adequacy of Audit: During this stage, the
registrar reviews the document submitted by the organization and
suggests an improvement.
4. Compliance Audit: During this stage, the registrar checks whether
the organization has compiled the suggestion made by it during the
review or not.
5. Registration: The Registrar awards the ISO certification after the
successful completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the
organization time by time.

Why is it necessary to get ISO 9000 certified?

Some of reasons are:

 This certification has become a standard for international bidding.

 It helps in designing high-quality repeatable software products.
 It emphasizes the need for proper documentation.
Features of ISO 9001 Requirements :

 Document control:All documents concerned with the development

of a software product should be properly managed and controlled.
  Planning:Proper plans should be prepared and monitored.
 Review:For effectiveness and correctness all important documents
across all phases should be independently checked and reviewed .
 Testing:The product should be tested against specification.
SEI-CMM Model
Software Engineering Institute Capability Maturity Model (SEI-CMM)
The Capability Maturity Model (CMM) is a procedure used to develop and
refine an organization's software development process.The model defines
a five-level evolutionary stage of increasingly organized and consistently
more mature processes.It was developed and is promoted by the Software
Engineering Institute (SEI)
Methods of SEI-CMM includes:

1. Capability Evaluation:It provides a way to assess the software

process capability of an organization. The results of capability
evaluation indicate the likely contractor performance if the
contractor is awarded a work. Therefore, the results of the
software process capability assessment can be used to select a
contractor.
2. Software Process Assessment: Software process assessment is
used by an organization to improve its process capability. Thus, this
type of evaluation is for purely internal use.

Levels Of SEICMM:

1. Level-1: Initial :Processes followed are ad hoc and immature and

are not well defined.Unstable environment for software
development.No basis for predicting product quality, time for
completion, etc.
2. Level-2: Repeatable:Experience with earlier projects is used for
managing new similar natured projects.
3. Level-3: Defined:At this level, documentation of the standard
guidelines and procedures takes place.It is a well defined integrated
set of project specific software engineering and management
processes.
4. Level-4: Managed:At this stage, quantitative quality goals are set for
the organization for software products as well as software
processes.The measurements made help the organization to predict
the product and process quality within some limits defined
quantitatively.
5. Level-5: Optimizing:This is the highest level of process maturity in
CMM and focuses on continuous process improvement in the
organization using quantitative feedback.