UNIT 2

SOFTWARE REQUIREMENT SPECIFICATION AND SOFTWARE

QUALITY ASSURANCE
(SRS/SQA)
Requirement Engineering Process: Elicitation
Requirements elicitation is the process of gathering and defining the requirements for a software system.
The goal of requirements elicitation is to ensure that the software development process is based on a clear
and comprehensive understanding of the customer’s needs and requirements. This article focuses on
discussing Requirement Elicitation in detail.

What is Requirement Elicitation?

The process of investigating and learning about a system’s requirements from users, clients, and other
stakeholders is known as requirements elicitation. Requirements elicitation in software engineering is
perhaps the most difficult, most error-prone, and most communication-intensive software development.

1. Requirement Elicitation can be successful only through an effective customer-developer

partnership. It is needed to know what the users require.

2. Requirements elicitation involves the identification, collection, analysis, and refinement of

the requirements for a software system.

3. Requirement Elicitation is a critical part of the software development life cycle and is
typically performed at the beginning of the project.

4. Requirements elicitation involves stakeholders from different areas of the organization,

including business owners, end-users, and technical experts.

5. The output of the requirements elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the software system.

6. Requirements elicitation is difficult because just questioning users and customers about
system needs may not collect all relevant requirements, particularly for safety and
dependability.

7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-playing, and
prototyping are all methods for eliciting requirements.
 Requirement Engineering

Requirement Engineering

Importance of Requirements Elicitation

1. Compliance with Business Objectives: The process of elicitation guarantees that the
software development endeavors are in harmony with the wider company aims and
objectives. Comprehending the business context facilitates the development of a solution that
adds value for the company.

2. User Satisfaction: It is easier to create software that fulfills end users’ needs and
expectations when they are involved in the requirements elicitation process. Higher user
pleasure and acceptance of the finished product are the results of this.

3. Time and Money Savings: Having precise and well-defined specifications aids in preventing
miscommunication and rework during the development phase. As a result, there will be cost
savings and the project will be completed on time.
 4. Compliance and Regulation Requirements: Requirements elicitation is crucial for projects
in regulated industries to guarantee that the software conforms with applicable laws and
norms. In industries like healthcare, finance, and aerospace, this is crucial.

5. Traceability and Documentation: Throughout the software development process,

traceability is based on well-documented requirements. Traceability helps with testing,
validation, and maintenance by ensuring that every part of the software can be linked to a
particular requirement.

Requirements Elicitation Activities

Requirements elicitation includes the subsequent activities. A few of them are listed below:

1. Knowledge of the overall area where the systems are applied.

2. The details of the precise customer problem where the system is going to be applied must be
understood.

3. Interaction of system with external requirements.

4. Detailed investigation of user needs.
5. Define the constraints for system development.

Requirements Elicitation Methods

There are several requirements for elicitation methods. A few of them are listed below:

1. Interviews

The objective of conducting an interview is to understand the customer’s expectations of the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on
their expertise and credibility. Interviews may be open-ended or structured.

1. In open-ended interviews, there is no pre-set agenda. Context-free questions may be asked to

understand the problem.

2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper

questionnaire is designed for the interview.

2. Brainstorming Sessions

● Brainstorming Sessions is a group technique

● It is intended to generate lots of new ideas hence providing a platform to share views
 ● A highly trained facilitator is required to handle group bias and conflicts.
● Every idea is documented so that everyone can see it.
● Finally, a document is prepared which consists of the list of requirements and their priority if
possible.

3. Facilitated Application Specification Technique

Its objective is to bridge the expectation gap – the difference between what the developers think they are
supposed to build and what customers think they are going to get. A team-oriented approach is developed
for requirements gathering. Each attendee is asked to make a list of objects that are:

1. Part of the environment that surrounds the system.

2. Produced by the system.
3. Used by the system.

Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated,
the team is divided into smaller sub-teams to develop mini-specifications and finally, a draft of
specifications is written down using all the inputs from the meeting.

4. Quality Function Deployment

In this technique customer satisfaction is of prime concern, hence it emphasizes the requirements that are
valuable to the customer.
3 types of requirements are identified:

● Normal requirements: In this the objective and goals of the proposed software are discussed
with the customer. For example – normal requirements for a result management system may
be entry of marks, calculation of results, etc.

● Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.

● Exciting requirements: It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. For example – when unauthorized access is
detected, it should back up and shut down all processes.

5. Use Case Approach

Use Case technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of
the system.
The components of the use case design include three major things – Actor, use cases, and use case
diagram.

1. Actor: It is the external agent that lies outside the system but interacts with it in some way.
An actor may be a person, machine, etc. It is represented as a stick figure. Actors can be
primary actors or secondary actors.

● Primary actors: It requires assistance from the system to achieve a goal.

● Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.

3. Use case diagram: A use case diagram graphically represents what happens when an actor
interacts with a system. It captures the functional aspect of the system.

● A stick figure is used to represent an actor.

● An oval is used to represent a use case.
● A line is used to represent a relationship between an actor and a use case.

The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and
the customer involved.

Steps of Requirements Elicitation

Following are the Steps of Requirement Elicitation

Identify all the stakeholders, e.g., Users, developers, customers, etc.

1. List out all requirements from the customer.

2. A value indicating the degree of importance is assigned to each requirement.
3. In the end, the final list of requirements is categorized as:
● It is possible to achieve.
● It should be deferred and the reason for it.
● It is impossible to achieve and should be dropped off.
Features of Requirements Elicitation
1. Stakeholder engagement: Requirements elicitation involves engaging with stakeholders
such as customers, end-users, project sponsors, and subject-matter experts to understand their
needs and requirements.

2. Gathering information: Requirements elicitation involves gathering information about the

system to be developed, the business processes it will support, and the end-users who will be
using it.

3. Requirement prioritization: Requirements elicitation involves prioritizing requirements

based on their importance to the project’s success.

4. Requirements documentation: Requirements elicitation involves documenting the

requirements clearly and concisely so that they can be easily understood and communicated
to the development team.

5. Validation and verification: Requirements elicitation involves validating and verifying the
requirements with the stakeholders to ensure they accurately represent their needs and
requirements.

6. Iterative process: Requirements elicitation is an iterative process that involves continuously

refining and updating the requirements based on feedback from stakeholders.

7. Communication and collaboration: Requirements elicitation involves effective

communication and collaboration with stakeholders, project team members, and other
relevant parties to ensure that the requirements are clearly understood and implemented.

8. Flexibility: Requirements elicitation requires flexibility to adapt to changing requirements,

stakeholder needs, and project constraints.

Advantages of Requirements Elicitation

1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration between
stakeholders.

3. Results in good quality software: Increases the chances of developing a software system
that meets customer needs.

4. Avoids misunderstandings: Avoids misunderstandings and helps to manage expectations.

 5. Supports the identification of potential risks: Supports the identification of potential risks
and problems early in the development cycle.

6. Facilitates development of accurate plan: Facilitates the development of a comprehensive

and accurate project plan.

7. Increases user confidence: Increases user and stakeholder confidence in the software
development process.

8. Supports identification of new business opportunities: Supports the identification of new

business opportunities and revenue streams.

Disadvantages of Requirements Elicitation

1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This may be impacted by changing business needs
and requirements.

4. Impacted by other factors: Can be impacted by political and organizational factors.

5. Lack of commitment from stakeholders: This can result in a lack of buy-in and
commitment from stakeholders.

6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and competing

interests.

7. Sometimes inaccurate requirements: This may result in incomplete or inaccurate

requirements if not properly managed.

8. Increased development cost: This can lead to increased development costs and decreased
efficiency if requirements are not well-defined.

Requirement Engineering Process: Documentation

Requirement Engineering (RE) is the process of defining, documenting, and maintaining the
requirements for a software system. The goal is to understand what the stakeholders need and to ensure
that the final software product meets those needs.
Requirement Engineering Process Documentation involves creating structured and organized records
of all activities, decisions, and outputs during the requirement engineering process. This documentation
serves as a reference for stakeholders, developers, and testers throughout the software development
lifecycle (SDLC).

Purpose of Requirement Engineering Documentation

● To provide a clear and shared understanding of the system requirements.

● To act as a contract between stakeholders and the development team.
● To support future modifications and maintenance of the system.
● To ensure that requirements are testable and traceable.
● To reduce misunderstandings and scope creep.

Phases of Requirement Engineering Process Documentation

The requirement engineering process is typically divided into the following phases:

1. Requirement Elicitation

The process of gathering information from stakeholders to understand their needs and expectations.

Activities:

● Identify stakeholders (e.g., customers, users, developers).

● Use different elicitation techniques:
○ Interviews – One-on-one or group discussions.
○ Questionnaires – Collect structured input.
○ Observation – Watch how users interact with existing systems.
○ Prototyping – Create a mockup and get feedback.
○ Brainstorming – Generate creative ideas.

Documentation:

● Stakeholder List – List of all stakeholders involved.

● Interview/Survey Reports – Summary of responses and feedback.
 ● Requirement Elicitation Report – Document detailing all identified requirements.

2. Requirement Analysis

The process of analyzing gathered requirements to identify conflicts, gaps, and inconsistencies.

Activities:

● Classify requirements into categories:

○ Functional Requirements – What the system should do.
○ Non-Functional Requirements – Performance, security, usability, etc.
○ Technical Requirements – Platforms, hardware, and software constraints.
● Check for feasibility and consistency.
● Prioritize requirements based on business value.
● Resolve conflicts and ambiguities.

Documentation:

● Requirement Specification Document – Detailed list of functional and non-functional

requirements.
● Use Case Diagrams – Illustrate how users interact with the system.
● Data Flow Diagrams (DFD) – Show the flow of data in the system.
● State Diagrams – Depict how the system transitions between states.

3. Requirement Specification

The process of formally documenting the analyzed requirements into a structured format.

Activities:

● Create a structured Software Requirement Specification (SRS) document.

● Include:
○ Purpose and scope of the system.
○ System overview.
○ Detailed functional and non-functional requirements.
 ○ System constraints and dependencies.
○ Acceptance criteria.

Documentation:

● Software Requirement Specification (SRS) – Comprehensive document defining all system

requirements.
● Requirement Traceability Matrix (RTM) – Maps requirements to design, implementation, and
testing phases.

4. Requirement Validation

The process of checking whether the documented requirements accurately reflect stakeholder needs.

Activities:

● Conduct formal reviews and walkthroughs.

● Perform prototyping and user acceptance testing.
● Ensure requirements are consistent, complete, and testable.

Documentation:

● Validation Report – Document highlighting findings from the review.

● Review Log – Records of feedback and changes requested.

5. Requirement Management

The process of handling changes and maintaining requirement consistency throughout the project
lifecycle.

Activities:

● Establish a change control process.

● Maintain a version-controlled repository for requirements.
● Update requirements based on feedback and testing results.
● Ensure traceability of all requirements.
Documentation:

● Change Request Log – Record of all change requests and their status.
● Updated SRS – Revised version reflecting approved changes.
● Requirement Traceability Matrix (RTM) – Updated with changes and status.

Structure of Requirement Engineering Documentation

A well-structured requirement document typically includes the following sections:

1. Introduction

● Purpose of the document.

● Scope of the system.
● Stakeholders involved.

2. System Overview

● High-level description of the system.

● Business objectives.

3. Functional Requirements

● List of system features and functionalities.

● Example:
○ "The system shall allow users to log in using a username and password."

4. Non-Functional Requirements

● Performance, security, usability, and scalability requirements.

● Example:
○ "The system shall support 1000 concurrent users."

5. System Constraints

● Hardware and software limitations.

 ● Regulatory and legal requirements.

6. Data Requirements

● Database structure.
● Data input and output formats.

7. Interface Requirements

● User Interface (UI) requirements.

● External system interaction.

8. Traceability Matrix

● Mapping of requirements to design, code, and test cases.

9. Acceptance Criteria

● Conditions that must be met for the system to be accepted by stakeholders.

Best Practices in Requirement Documentation

● Keep the language simple and unambiguous.

● Use diagrams and models to make the document visually clear.
● Include version numbers to track changes.
● Ensure all stakeholders review and approve the document.
● Keep documentation up to date as the project evolves.

Example: Functional Requirement

Requirement:
"The system shall allow registered users to reset their password using a verified email address."

Mapped in Traceability Matrix:

 Requirem Descript Design Te Statu
ent ID ion Component st s
Ca
se

FR-001 Passwor User Account TC Imple

d Reset Module - mente
00 d
1

Outcome of Requirement Engineering Documentation

● Clear understanding of system requirements.

● Reduced ambiguity and misunderstandings.
● Effective project planning and resource allocation.
● Better tracking of requirement changes and impact analysis.
● Higher success rate of software projects.

Requirement Engineering Process: Analysis in Software Engineering

Requirement Analysis is a critical phase in the Requirement Engineering (RE) process where the
gathered requirements are systematically examined to ensure they are complete, consistent, unambiguous,
and feasible. It involves refining and detailing the initial high-level requirements collected from
stakeholders to create a clear and structured understanding of the system’s needs.

Requirement analysis ensures that the development team and stakeholders have a common understanding
of what the system should do and how it should perform. It helps prevent issues such as missing
functionality, conflicting requirements, and unrealistic expectations, which can lead to project failures if
not addressed early.
Objectives of Requirement Analysis

The key objectives of requirement analysis are:

● To define and refine stakeholder needs and expectations.

● To identify and resolve conflicts between requirements.
● To prioritize requirements based on business value and technical feasibility.
● To ensure clarity and remove ambiguities in requirements.
● To document the requirements in a structured manner for future reference.
● To validate requirements to confirm they align with business goals and technical constraints.

Importance of Requirement Analysis

● Helps prevent scope creep and requirement gaps.

● Improves communication and understanding between stakeholders and developers.
● Reduces the risk of project failure due to unclear or incomplete requirements.
● Ensures that the final product meets the business needs and user expectations.
● Provides a foundation for design, development, and testing activities.

Steps in Requirement Analysis

The requirement analysis phase is generally broken down into five key steps:

1. Requirement Classification and Organization

In this step, the collected requirements are grouped into logical categories to simplify analysis and
understanding.

Types of Requirements:

● Functional Requirements – Describe the system's specific functionality and behavior.

○ Example: "The system shall allow users to log in using a username and password."
● Non-Functional Requirements – Define the system's performance, security, and usability
characteristics.
 ○ Example: "The system shall support 1000 concurrent users without performance
degradation."
● Technical Requirements – Specify the platforms, frameworks, and hardware needed.
○ Example: "The system shall run on Windows Server 2019."
● Business Requirements – Describe the business goals and outcomes the system should achieve.
○ Example: "The system should increase customer engagement by 20% within the first
year."
● User Requirements – Define how the user will interact with the system.
○ Example: "The user shall be able to update their profile information."

Outcome:

● A structured list of categorized requirements.

● Early identification of conflicting or missing requirements.

2. Requirement Prioritization

Not all requirements have equal importance. Prioritization helps the development team focus on the most
critical aspects of the system first.

Factors Influencing Prioritization:

● Business Value – Requirements that directly impact business goals are given higher priority.
● Technical Complexity – Simple requirements are often implemented first to build a strong
foundation.
● Stakeholder Impact – Critical requirements for stakeholders are prioritized.
● Legal and Compliance Needs – Regulatory requirements are given high priority.

Prioritization Techniques:

● MoSCoW Method:

○ M – Must Have – Critical for system functionality.

○ S – Should Have – Important but not essential.
○ C – Could Have – Nice to have but not mandatory.
 ○ W – Won't Have – Not considered for the current release.
● Kano Model:

○ Basic Needs – Fundamental system requirements.

○ Performance Needs – Enhance user satisfaction.
○ Excitement Needs – Unexpected features that delight users.

Outcome:

● A list of prioritized requirements.

● Clarity on which features to implement first.

3. Requirement Modeling

In this step, the requirements are represented visually using various models and diagrams to improve
understanding and communication.

Common Requirement Models:

● Use Case Diagrams – Define user interactions with the system.

○ Example: A use case for "User Login" shows how a user logs into the system.
● Entity-Relationship Diagrams (ERD): – Represent the structure and relationships between
system entities.
○ Example: A customer entity linked to an order entity.
● Data Flow Diagrams (DFD): – Show how data flows through the system.
○ Example: Data flow from login to the user dashboard.
● State Transition Diagrams: – Represent how the system transitions between different states.
○ Example: A state change from "Logged Out" to "Logged In."
● Class Diagrams: – Define the objects and their relationships within the system.
○ Example: User class, Product class, and Order class relationships.

Outcome:

● Clear visual representation of how the system will work.

● Improved stakeholder and developer understanding.
4. Requirement Validation and Verification

Once the requirements are modeled and documented, they need to be checked for accuracy, completeness,
and consistency.

Verification:

● Ensures that the documented requirements are consistent and logically correct.
● Techniques used:
○ Formal reviews
○ Walkthroughs
○ Checklists

Validation:

● Ensures that the requirements reflect stakeholder needs and business goals.
● Techniques used:
○ Prototyping
○ User feedback
○ Stakeholder reviews

Outcome:

● A validated set of requirements that can be confidently used for development.

● Resolution of any conflicts or inconsistencies.

5. Conflict Resolution

During the analysis phase, conflicting requirements may arise between different stakeholders or between
business and technical constraints.

Sources of Conflict:

● Stakeholder Disagreement: Different stakeholders may have opposing views.

● Technical Limitations: Some features may not be technically feasible.
● Business vs. Legal Requirements: Business goals may conflict with regulatory requirements.
Conflict Resolution Techniques:

● Negotiation: Stakeholders reach a compromise.

● Trade-offs: Sacrificing one requirement to meet another.
● Escalation: Conflicts are resolved at a higher management level.

Outcome:

● Resolved conflicts.
● Clear and agreed-upon requirements.

Deliverables of Requirement Analysis

The output of the requirement analysis phase includes the following:

1. Software Requirements Specification (SRS):

○ A structured document defining all functional and non-functional requirements.
2. Use Case Models:
○ Graphical representation of user interactions with the system.
3. Data Models:
○ Define the structure of system data.
4. State Transition Diagrams:
○ Describe system states and transitions.
5. Traceability Matrix:
○ Maps requirements to design, implementation, and testing phases.

Example of Requirement Analysis

Functional Requirement:
"The system shall allow users to reset their password using a verified email."

Analysis:

● Completeness: Does the requirement cover all password recovery methods?

● Consistency: Does this conflict with other security requirements?
 ● Feasibility: Is it technically possible to implement email verification with the current system
architecture?
● Unambiguity: Is it clear how the email verification will work?

Resolution:

● Add support for SMS-based recovery.

● Define security guidelines for email verification.
● Confirm that the feature aligns with system security policies.

Outcomes of Requirement Analysis

● Clear and complete requirement documentation.

● Reduced ambiguity and conflict.
● Improved communication among stakeholders and developers.
● A solid foundation for system design and development.

Best Practices in Requirement Analysis

Involve stakeholders throughout the process.

Keep language clear and precise.

Regularly validate and review requirements.

Prioritize requirements based on business and technical value.

Maintain traceability of all requirements.

Review And Management of User Needs

Requirement reviews in Software Development

Why are requirements needed before developing software ?
Requirements are mandatory in terms of software development. Requirements are the basics that take
forward the development procedure. Requirements enhance the existing project to a different level. The
software cannot progress without the participation of user input. User input like feedback and product
review comes as the major requirements in the development work.

What are requirement reviews ?

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

Why is requirement review performed ?

Software in the current time is so Advanced that the act of requirement review holds greater importance
in software development. The pursuance of requirement reviews helps to have a clear peek into the space
of the software industry. The requirement reviews call attention to the only chance of finding quality
reviews. So keeping in mind that there are problems and solutions to everything, a requirement review
needs a good performance.

Importance of performing requirement review :

● The performance of requirement review helps to radiate the precise and correct data to the
consumers and users.

● It helps to have a quick tour of the Existing project to see whether or not it is going in the
right direction.

● It helps to provide practical instructions and helps make decisions accordingly.

Methods of performing requirement review :

1. Team consultation :
Suggestion matters also matter the way of performance. Teamwork goes hand in hand. When there are
people to offer suggestions, give appropriate guidelines, and supervise in a team. There is no doubt about
the project getting mismanaged. Reaching out to the team/individual who has better insights into
requirement review works the best way.

2. Understanding the user’s requirement :

Recognize the user’s needs and go all out in understanding them. Requirements keep on changing with
time. So, When you have collected a list of things that a user requires in the current time. There you found
a way to go about it. To get exact information on their requirements, Asking for feedback is Important.
3. Finding measures to software problem :
The occurrence of software problems is predictable. Errors and defects are bound to take place in
software development. In this context, Rather than making a fuss about the Problems, developers should
find solutions to satisfy the requirements. The requirement review not only meets the expectations of
users but also the standard of the entire industry.

Advantages of performing requirement reviews :

● Requirement reviews accord the developers a motive and structure to carry out the project
further.

● Group collaboration is the highlight. Group work saves time.

● Therefore, the developers can utilize the saved time in rechecking and reconfirming the
processing work to take it ahead.

Disadvantages of performing requirement reviews :

● Lack of attention acts as a hindrance. When a team does not listen to each other in a meeting
room because of disagreement on matters, it emerges as a sign of unprofessional and
uncoordinated work.

● At times, the Review cannot be accurate. So, If you fail in assembling the precise
information, it can be an obstacle for the developers and the industry.

Management of User Needs

Managing user needs involves handling requirements throughout the software development lifecycle
(SDLC) to ensure alignment with business goals and user expectations.

1. Requirement Elicitation

● Interviews – Directly asking stakeholders about their needs.

● Surveys/Questionnaires – Collecting structured feedback.
● Workshops – Collaborative sessions to define needs.
● Observation – Watching users interact with existing systems.
● Prototyping – Building early versions to gather feedback.
2. Requirement Documentation

● Create clear and structured Software Requirement Specification (SRS) documents.

● Include functional, non-functional, and technical requirements.

3. Requirement Analysis

● Prioritize requirements based on business value, feasibility, and user impact.

● Resolve conflicts and redundancies.

4. Requirement Validation

● Ensure requirements align with stakeholder expectations.

● Conduct reviews and feedback sessions.

5. Requirement Change Management

● Establish a Change Control Board (CCB) to evaluate and approve changes.

● Track changes using version control tools.
● Communicate changes to stakeholders.

6. Requirement Traceability

● Create a traceability matrix to track requirements from definition to testing.

● Ensure all requirements are implemented and tested.

7. Requirement Monitoring and Reporting

● Regularly monitor progress toward meeting requirements.

● Generate reports to keep stakeholders informed.

🌟 Best Practices

Involve stakeholders early and continuously.

Use prototyping and iterative feedback loops.

Prioritize requirements to manage scope creep.

 Maintain clear communication channels.

Automate requirement tracking where possible.

Feasibility Study

A Feasibility Study in Project Management is a comprehensive analysis conducted to determine the

practicality and viability of a proposed project. It assesses various aspects such as technical, economic,
legal, operational, and scheduling feasibility to ascertain if the project can be successfully completed
within defined constraints. The study helps stakeholders make informed decisions about whether to
proceed with the project or explore alternative options based on the identified risks, costs, benefits, and
potential outcomes.

What's the Importance of a Feasibility Study?

1. Cost-Benefit Analysis: It permits the interested parties to carry out an exhaustive evaluation
of costs and advantages to envision

2. Project Viability: Evaluating the general viability and feasibility of a proposed project is
critical because it enables stakeholders to determine if the project is profitable.

3. Market Demand and Competition: A feasibility study gives insights into the possible
purchaser base, marketplace possibilities, and competitive surroundings by analyzing market
demands, trends, and opposition.

4. Making Decisions: Feasibility studies provide stakeholders the information and

understanding they need to decide whether or not to move ahead with the task, exchange its
scope or technique, or scrap it entirely.

What is Included in a Feasibility Study Report?

1. Executive Summary: An executive summary is a quick assessment of the feasibility study's

important conclusions, guidelines, and findings.

2. Introduction: A summary of the goals and goals to be carried out, along with the reason and
scope of the feasibility study.
 3. Background and Context: Details about the project or business endeavors under attention,
such as its heritage, purpose, and justification for conducting a feasibility study.

4. Market Analysis: Market study is the process of examining the target market's size, trends,
potential for growth, customer demographics, and competitive environment. This section
explores possible opportunities and difficulties as well as evaluates the demand for the
suggested good or service.

5. Financial Analysis: A thorough financial analysis that includes ROI calculations, cost
estimates, revenue forecasts, and cash flow projections. This part evaluates the project's
prospective profitability as well as its financial viability.

6. Risk assessment: It is the process of identifying and evaluating the project's possible risks
and difficulties, such as financial, technical, commercial, and regulatory concerns. The
methods for decreasing and controlling those risks are described in this phase.

7. Resource Requirements: Plans for allocating sources and an estimate of its expenses are
supplied in this segment.

8. Conclusion and Recommendations: An evaluation of the feasibility study's essential

conclusions and findings, together with suggestions for decision-makers.

9. Appendices: Extra data, charts, tables, references, and supporting documents that give the
feasibility study more context or information.

Types of Feasibility Study

1. Technical Feasibility Study: This type of feasibility takes a look at evaluating a project's
technical capabilities, consisting of the accessibility of the resources, technology, and
knowledge needed to deliver it out efficiently. It assesses whether or not the project may be
technically finished on time.

2. Economic Feasibility Study: Economic feasibility studies examine a project's expenses and
feasible benefits to determine whether or not it's financially viable. This entails comparing the
project's effect on income, charges, and profitability as well as doing cost-benefit analysis
and calculating return on funding (ROI).

3. Operational Feasibility Study: Operational feasibility research determines an assignment's

operational factors, which include its workflows, organizational structure, and strategies.
 They evaluate how successfully and efficiently the project can be performed and integrated
into the current operations.

4. Social Feasibility Study: It evaluates how a task will have an effect on stakeholders,
neighborhood communities, and society as a whole on a social and cultural stage. To decide if
the project is socially possible and suitable, they determine variables like social acceptance,
stakeholder participation, community effect, and company social responsibility.

7 Steps to do a Feasibility Study

● Step1: Specify the goals and scope of the assignmentClearly state the project's goals,
objectives, and motive. Comprehending the project's scale is critical in directing the
feasibility study methodology.

● Step2: Collect relevant details and dataGather all the project-related data and information
that is required. This could contain financial information, industry analysis, legal needs,
technological considerations, market research, and any other elements that could have an
impact on the project's success.

● Step3: Analyze the marketAnalyze the product or service's potential and market demand.
Examine consumer demands and preferences, market developments, rivalry, and possible
entry hurdles.

● Step4: Determine Technical FeasibilityDetermine the technical specifications and capacities

required to carry out the project. This involves figuring out if the infrastructure, generation,
manpower, and expertise needed to create and offer the coolest or carrier are with ease
available.

● Step5: Assessing the Financial ViabilityTo determine the viability and profitability of the
project, do a detailed economic study. Compute the projected revenue, persevering with
prices, one-time investment charges, and feasible return on investment (ROI). To ascertain
whether or not the project is financially feasible, compute essential economic indicators such
net present value (NPV), internal rate of run (IRR), and payback duration.

● Step6: Analyze Organizational and Operational FeasibilityExamine the project's operational

and organizational feasibility by conducting an organizational and operational feasibility
analysis. Evaluate the organization's ability and potential to carry out the project successfully.
Take into account elements including the amount of workers needed, the management
structure, the operating procedures, and any potential hazards or limitations.
 ● Step7: Compile Results and Offer RecommendationsCreate a thorough report by compiling
the feasibility study's results. Include a SWOT analysis of the main conclusions, highlighting
the benefits, risks, possibilities, and threats. Provide tips approximately about the project's
viability primarily based on the study, along with whether or not to move ahead, make
changes, or scrap the idea altogether.

How to Manufacturing Feasibility Study?

1. Define the Objectives: Clearly state the aim and objectives of the manufacturing feasibility
study, with an emphasis on the product to be produced and the intended results.

2. Gather information: To help with the feasibility evaluation, gather information on the
following topics: market demand, competitors, materials, production techniques, product
specifications, and regulatory needs.

3. Analyze Technical Feasibility: Determine whether the technology, tools, and information
required for manufacturing are simply available. You should also look for areas where the
manufacturing process might be optimized and faced with obstacles.

4. Assessing Financial Feasibility: To ascertain the profitability and financial viability of

producing the product, estimate the original investment and ongoing costs. Then, examine
revenue estimates.

5. Evaluate Operational Feasibility: To guarantee effective product production and

distribution, compare labor availability, deliver chain logistics, and operational processes.

6. Evaluate the Issues of Regulation and Compliance: Recognize and abide through
applicable laws and regulations, securing the required licenses and certifications to guarantee
ethical and steady production strategies.

7. Compile Results and Offer Recommendations: Combine results into a report that
emphasizes important factors and offers suggestions on whether or not the product can be
manufactured, along with any necessary modifications or mitigations.

Best Practices for a Feasibility Study

1. Include Crucial Stakeholders: To assure support and obtain a variety of viewpoints, involve
decision-makers, subject matter experts, and end users at every stage of the feasibility study.
 2. Complete Data Collection: To support the feasibility evaluation, compile accurate and
thorough data from a variety of sources, such as industry reports, financial predictions,
market research, and expert opinions.

3. Clear Communication: Clearly and simply convey to all stakeholders the results,
conclusions, and suggestions of the feasibility study. Charts, graphs, and other visual aids can
help with comprehension.

4. Practical Suggestions: Based on the results of the feasibility study, make practical
suggestions that specify the measures that must be done in order to overcome obstacles or
seize possibilities.

Information Modeling in Software Engineering

Information Modeling in software engineering is the process of defining, analyzing, and documenting
the structure, relationships, and constraints of data and information within a software system. It
provides a structured way to represent the data and how it interacts with different components of the
system, ensuring that the system's design is consistent, complete, and aligned with business requirements.

Information modeling helps developers and stakeholders understand how data is stored, processed, and
exchanged within a system, forming the foundation for database design, system architecture, and
application development.

Objectives of Information Modeling

● To provide a clear understanding of the system’s data structure.

● To define how different data elements relate to each other.
● To ensure data consistency and integrity across the system.
● To help identify redundancy and data conflicts.
● To facilitate better system design and database optimization.
● To enable easier system modification and scalability.

Importance of Information Modeling

● Reduces the risk of data inconsistency and data loss.

 ● Helps in data integrity by defining constraints and relationships.
● Improves system performance through efficient data organization.
● Enhances stakeholder communication by providing a visual representation of the data model.
● Supports decision-making by organizing data to reflect business needs.

Key Elements of Information Modeling

An information model consists of three main components:

1. Entities

● Represent real-world objects or concepts in the system.

● Example: Customer, Order, Product.

2. Attributes

● Define the properties or characteristics of an entity.

● Example: A Customer entity might have attributes like Name, Email, and Phone Number.

3. Relationships

● Describe how entities are connected to each other.

● Example: A Customer can place multiple Orders, forming a one-to-many relationship.

Types of Information Models

There are three main types of information models used in software engineering:

1. Conceptual Model

● High-level model that defines the system’s data structure and relationships without technical
details.
● Focuses on understanding the business requirements.
● Example: A diagram showing how Customers, Orders, and Products relate to each other.

Techniques Used:
 ● Entity-Relationship Diagrams (ERD)
● UML Class Diagrams

2. Logical Model

● Translates the conceptual model into a more detailed model with specific data elements and
relationships.
● Defines the structure of the data and the rules that govern it.
● Independent of the database or storage technology used.

Example:

● Customer table with fields for ID, Name, and Email.

● Order table with fields for Order ID, Date, and Total Amount.
● Relationship defined by Customer ID in the Order table referencing the Customer table.

Techniques Used:

● Normalization (to eliminate data redundancy)

● Data Flow Diagrams (DFD)
● State Transition Diagrams

3. Physical Model

● Converts the logical model into a database-specific design.

● Includes specific details like table names, data types, and constraints.
● Defines how data is stored, accessed, and indexed in the system.

Example:

● Table structures, primary keys, foreign keys, indexes, and constraints.

● Database platform-specific configurations (e.g., MySQL, PostgreSQL).

Techniques Used:

● Database Schema Diagrams

● SQL Data Definition Language (DDL) Scripts
Techniques for Information Modeling

Several modeling techniques are used to create information models:

1. Entity-Relationship Diagrams (ERD)

● Define entities, attributes, and relationships between entities.

● Example: A "Customer" entity related to an "Order" entity through a one-to-many relationship.

2. Unified Modeling Language (UML) Diagrams

● Class diagrams represent data objects and their relationships.

● Sequence diagrams represent how data flows during operations.

3. Data Flow Diagrams (DFD)

● Show how data moves through the system.

● Example: Data flow from user login to the user profile screen.

4. State Transition Diagrams

● Represent how the system changes states based on data inputs and events.
● Example: "Logged Out" → "Logged In" → "Session Expired."

5. Object-Role Modeling (ORM)

● Focuses on the roles played by entities in a relationship.

● Example: A "Customer" entity places an "Order."

Example of Information Modeling

1. Conceptual Model

● Entities: Customer, Order, Product

● Relationships:
○ A Customer can place multiple Orders (One-to-Many)
○ An Order can include multiple Products (Many-to-Many)
2. Logical Model

Customer Table:

Benefits of Information Modeling

1. Improved understanding of system data structure and relationships.

2. Reduced data redundancy and improved data integrity.
3. Enhanced system performance through efficient data storage and retrieval.
4. Easier maintenance and scalability of the system.
5. Facilitates better communication between stakeholders and developers.

Challenges in Information Modeling

1. Poorly defined requirements can lead to an incomplete model.

2. Complex systems may result in overly complicated models.
3. Changing requirements can require updates to the information model.
4. Misalignment between business goals and technical implementation.

Best Practices for Information Modeling

1. Start with a conceptual model and gradually refine it into a logical and physical model.
2. Keep models simple and understandable.
3. Use standard naming conventions for entities and attributes.
 4. Regularly review and update the model as requirements change.
5. Ensure that the model aligns with business goals and technical constraints.

DFD (Data Flow Diagram)

Data Flow Diagram (DFD) represents the flow of data within information systems. Data Flow Diagrams
(DFD) provide a graphical representation of the data flow of a system that can be understood by both
technical and non-technical users. The models enable software engineers, customers, and users to work
together effectively during the analysis and specification of requirements.

What is a Data Flow Diagram (DFD)?

DFD is the abbreviation for Data Flow Diagram. The flow of data in a system or process is represented
by a Data Flow Diagram (DFD). It also gives insight into the inputs and outputs of each entity and the
process itself. Data Flow Diagram (DFD) does not have a control flow and no loops or decision rules are
present. Specific operations, depending on the type of data, can be explained by a flowchart. It is a
graphical tool, useful for communicating with users, managers and other personnel. it is useful for
analyzing existing as well as proposed systems.

It should be pointed out that a DFD is not a flowchart. In drawing the DFD, the designer has to specify
the major transforms in the path of the data flowing from the input to the output. DFDs can be
hierarchically organized, which helps in progressively partitioning and analyzing large systems.

It provides an overview of
 ● What data is system processes.
● What transformation are performed.
● What data are stored.
● What results are produced , etc.

Data Flow Diagram can be represented in several ways. The Data Flow Diagram (DFD) belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular because they help us to visualize
the major steps and data involved in software-system processes.

Characteristics of Data Flow Diagram (DFD)

Below are some characteristics of Data Flow Diagram (DFD):

● Graphical Representation: Data Flow Diagram (DFD) use different symbols and notation to
represent data flow within system. That simplify the complex model.

● Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a system
and can be effectively used during analysis. Data Flow Diagram (DFDs) are quite general and
are not limited to problem analysis for software requirements specification.

● Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e. DFD
hides unnecessary implementation details and show only the flow of data and processes
within information system.

● Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level diagram
i.e. 0-level diagram provides an overview of entire system while lower-level diagram like 1-
level DFD and beyond provides a detailed data flow of individual process.

● Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the data flow
between external entity, processes and data store. Data Flow is represented by an arrow
Symbol.

● Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both
technical and non-technical stakeholders.

● Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks the
complex system into smaller module or processes. This provides easily analysis and design of
a system.

Types of Data Flow Diagram (DFD)

There are two types of Data Flow Diagram (DFD)
 1. Logical Data Flow Diagram
2. Physical Data Flow Diagram

Logical Data Flow Diagram (DFD)

Logical data flow diagram mainly focuses on the system process. It illustrates how data flows in the
system. Logical Data Flow Diagram (DFD) mainly focuses on high level processes and data flow without
diving deep into technical implementation details. Logical DFD is used in various organizations for the
smooth running of system. Like in a Banking software system, it is used to describe how data is moved
from one entity to another.

Physical Data Flow Diagram

Physical data flow diagram shows how the data flow is actually implemented in the system. In the
Physical Data Flow Diagram (DFD), we include additional details such as data storage, data transmission,
and specific technology or system components. Physical DFD is more specific and close to
implementation.

Components of Data Flow Diagrams (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 (Data Store) : 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 (External Entity): 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 terminators.

What symbols and notations are used to represent Components of DFD?

In Data-Flow Diagrams (DFDs), symbols and notations vary depending on the methodology being used.
Here’s a summary of symbols and notations commonly associated with each methodology:

The different methodologies or approaches used for creating Data-Flow Diagrams (DFDs) are:

● Gane and Sarson

● Yourdon and De Marco
● SSADM
● UML

Each methodology provides its own set of guidelines, symbols, and notations for representing system
components and their interactions.

Levels of Data Flow Diagram (DFD)

Data Flow Diagram (DFD) uses hierarchy to maintain transparency thus multilevel Data Flow Diagram
(DFD’s) can be created. Levels of Data Flow Diagram (DFD) are as follows:

0-level DFD

It is also known as a context diagram. It’s designed to be an abstraction view, showing the system as a
single process with its relationship to external entities. It represents the entire system as a single bubble
with input and output data indicated by incoming/outgoing arrows.

1-Level DFD

This level provides a more detailed view of the system by breaking down the major processes identified
in the level 0 DFD into sub-processes. Each sub-process is depicted as a separate process on the level 1
DFD. The data flows and data stores associated with each sub-process are also shown. In 1-level DFD,
the context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the main
functions of the system and breakdown the high-level process of 0-level DFD into subprocesses.

2-level DFD

This level provides an even more detailed view of the system by breaking down the sub-processes
identified in the level 1 DFD into further sub-processes. Each sub-process is depicted as a separate
process on the level 2 DFD. The data flows and data stores associated with each sub-process are also
shown.

Rules for Data Flow Diagram (DFD)

Following are the rules of DFD:

● Data can flow from:

○ Terminator or External Entity to Process
○ Process to Terminator or External Entity
○ Process to Data Store
○ Data Store to Process
○ Process to Process
● Data Cannot Flow From
○ Terminator or External Entity to Terminator or External Entity
○ Terminator or External Entity to Data Store
○ Data Store to Terminator or External Entity
○ Data Store to Data Store

Advantages of Data Flow Diagram (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.

Disadvantages of Data Flow Diagram (DFD)

● At times Data Flow Diagram (DFD) can confuse the programmers regarding the system.
 ● Data Flow Diagrams take a long time to be generated, and many times due to this reasons
analysts are denied permission to work on it.

How to Draw a Data Flow Diagram?

Following are the steps to Draw Data Flow Diagram

● Understand the System

● Identify External Entities
● Identify Processes
● Identify Data Stores
● Use Standard Symbols
● Create Level 0 Diagram
● Based on Complexity Draw Further Level Diagrams like Level 1, 2 and so on.
● Identify Data Flows:
● Number Processes and Data Stores
● Review and Validate
 DFD for UNIVERSITY COURSE REGISTRATION SYSTEM

ER Model
We typically follow the below steps for designing a database for an application.

● Gather the requirements (functional and data) by asking questions to the database users.
● Do a logical or conceptual design of the database. This is where the ER model plays a role. It
is the most used graphical representation of the conceptual design of a database.

● Physical Database Design (Like indexing) and external design (like views)
The Entity Relationship Model is a model for identifying entities (like student, car or company) to be
represented in the database and representation of how those entities are related. The ER data model specifies
an enterprise schema that represents the overall logical structure of a database graphically.

Why Use ER Diagrams In DBMS?

● ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).

● ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.

● ER diagrams require no technical knowledge of the underlying DBMS used.

● It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists of these
symbols:

● Rectangles: Rectangles represent Entities in the ER Model.

● Ellipses: Ellipses represent Attributes in the ER Model.
● Diamond: Diamonds represent Relationships among Entities.
● Lines: Lines represent attributes to entities and entity sets with other relationship types.
● Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
● Double Rectangle: Double Rectangle represents a Weak Entity.

Symbols used in ER Diagram

Components of ER Diagram

ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.

Components of ER Diagram

What is Entity?

An Entity may be an object with a physical existence – a particular person, car, house, or employee – or it
may be an object with a conceptual existence – a company, a job, or a university course.

What is Entity Set?

An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example, E1 is an
entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram, Entity
Type is represented as:

Entity Set

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because entity is
row and column in the relation and ER Diagram is graphical representation of data.
Types of Entity

There are two types of entity:

1. Strong Entity

A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other Entity
in the Schema. It has a primary key, that helps in identifying it uniquely, and it is represented by a rectangle.
These are called Strong Entity Types.

2. Weak Entity

An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity type
exists for which key attributes can’t be defined. These are called Weak Entity types .

For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can’t exist without the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type for Dependent, which means it is Strong Entity Type
.

A weak entity type is represented by a Double Rectangle. The participation of weak entity types is always
total. The relationship between the weak entity type and its identifying strong entity type is called
identifying relationship and it is represented by a double diamond.

Strong Entity and Weak Entity

What are Attributes?

Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age, Address,
and Mobile_No are the attributes that define entity type Student. In ER diagram, the attribute is represented
by an oval.
 Attribute

Types of Attributes

1. Key Attribute

The attribute which uniquely identifies each entity in the entity set is called the key attribute. For example,
Roll_No will be unique for each student. In ER diagram, the key attribute is represented by an oval with
underlying lines.

Key Attribute

2. Composite Attribute

An attribute composed of many other attributes is called a composite attribute. For example, the Address
attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram, the composite
attribute is represented by an oval comprising of ovals.

Composite Attribute

3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone_No (can be more
than one for a given student). In the ER diagram, a multivalued attribute is represented by a double oval.

Multivalued Attribute

4. Derived Attribute

An attribute that can be derived from other attributes of the entity type is known as a derived attribute. e.g.;
Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed oval.

Derived Attribute

The Complete Entity Type Student with its Attributes can be represented as:

Entity and Attributes

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER diagram, the relationship type
is represented by a diamond and connecting the entities with lines.
 Entity-Relationship Set

A set of relationships of the same type is known as a relationship set. The following relationship set depicts
S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.

Relationship Set

Degree of a Relationship Set

The number of different entity sets participating in a relationship set is called the degree of a relationship
set.

1. Unary Relationship: When there is only ONE entity set participating in a relation, the relationship is
called a unary relationship. For example, one person is married to only one person.

Unary Relationship

2. Binary Relationship: When there are TWO entities set participating in a relationship, the relationship
is called a binary relationship. For example, a Student is enrolled in a Course.

Binary Relationship
3. Ternary Relationship: When there are three entity sets participating in a relationship, the relationship
is called a ternary relationship.

4. N-ary Relationship: When there are n entities set participating in a relationship, the relationship is called
an 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 the 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:

 DECISION TREE
A decision tree gives a graphic view of the processing logic involved in
decision making and the corresponding actions taken.
The edges of a decision tree represent conditions and the leaf nodes represent
the actions to be performed depending on the outcome of testing the condition.
EXAMPLE
Consider Library Membership Automation Software (LMS) where it should
support the following three options:
i. New member
ii. Renewal
iii. Cancel membership
iv. Renewal option
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name
and his membership number to check whether he is a valid member or not.
Action: If the membership is valid then membership expiry date is updated and
the annual membership bill is printed, otherwise an error message is displayed.
Cancel membership option
Decision: If the 'cancel membership' option is selected, then the software asks
for member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to
the member is printed and finally the membership record is deleted from the
database.

Graphical Representation of Decision Tree

New member option
Decision: When the 'new member' option is selected, the software asks details
about the member like member's name, address, phone number etc.
 Action: If proper information is entered, then a membership record for the
member is created and a bill is printed for the annual membership charge plus
the security deposit payable.
A decision table is a brief visual representation for specifying which actions to
perform depending on given conditions. This article focuses on
discussing decision tables in detail.

What is a Decision Table?

A decision table is a good way to settle different combination inputs with their
corresponding outputs and is also called a cause-effect table.
1. The reason to call the cause-effect table is a related logical diagramming
technique called cause-effect graphing that is used to obtain the decision table.

The four quadrants

Conditions Condition alternatives

Actions Action entries

Importance of Decision Table

Decision tables are very helpful in test design techniques.
1. Helps testers to search effects of combinations: It helps testers to search the
effects of combinations of different inputs and other software states that must
correctly implement business rules.
2. Helps to start complex business rules: It provides a regular way of starting
complex business rules, that is helpful for developers as well as for testers.
3. Helps in the development process: It assists in the development process with
the developer to do a better job. Testing with all combinations might be
impractical.
4. Used in testing: A decision table is basically an outstanding technique used in
both testing and requirements management.
Decision Table in Test Designing
Blank Decision Table
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1
Condition 2
Condition 3
Condition 4
Decision Table: Combinations
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N
Advantages of Decision Table
1. Easy conversion of business flow to test case: Any complex business flow
can be easily converted into test scenarios and test cases using this technique.
2. Works iteratively: Decision tables work iteratively which means the table
created at the first iteration is used as input tables for the next tables. The
iteration is done only if the initial table is not satisfactory.
3. Simple to understand: Simple to understand and everyone can use this method
to design the test scenarios & test cases.
4. Provides complete test case coverage: It provides complete coverage of test
cases which helps to reduce the rework on writing test scenarios & test cases.

Software Requirement Specification (SRS)

This is the way of representing requirements in a consistent format.
It is called Software Requirement Specification (SRS).
SRS serves many purposes depending upon who is writing it.
➢ written by customer
➢ written by developer
Serves as contract between customer & developer.

Software Requirement Specification (SRS) Format as the name suggests, is

a complete specification and description of requirements of the software that
need to be fulfilled for the successful development of the software system.
These requirements can be functional as well as non-functional depending upon
the type of requirement. The interaction between different customers and
contractors is done because it is necessary to fully understand the needs of

Introduction
• Purpose of this Document – At first, main aim of why this document is
necessary and what’s purpose of document is explained and described.
• Scope of this document – In this, overall working and main objective of
document and what value it will provide to customer is described and explained.
It also includes a description of development cost and time required.
• Overview – In this, description of product is explained. It’s simply summary or
overall review of product.
General description
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also
describes features of user community.
Functional Requirements
In this, possible outcome of software system which includes effects due to
operation of program is fully explained. All functional requirements which may
include calculations, data processing, etc. are placed in a ranked order.
Functional requirements specify the expected behavior of the system-which
outputs should be produced from the given inputs. They describe the
relationship between the input and output of the system. For each functional
requirement, detailed description all the data inputs and their source, the units
of measure, and the range of valid inputs must be specified.
Interface Requirements
In this, software interfaces which mean how software program communicates
with each other or users either in form of any language, code, or message are
fully described and explained. Examples can be shared memory, data streams,
etc.
Performance Requirements
In this, how a software system performs desired functions under specific
condition is explained. It also explains required time, required memory,
 maximum error rate, etc. The performance requirements part of an SRS
specifies the performance constraints on the software system.
Design Constraints
In this, constraints which simply means limitation or restriction are specified
and explained for design team. Examples may include use of a particular
algorithm, hardware and software limitations, etc.
Non-Functional Attributes
In this, non-functional attributes are explained that are required by software
system for better performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity, Scalability
capacity, etc.
Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include
overall time duration required and overall cost required for development of
project.
Appendices
In this, additional information like references from where information is
gathered, definitions of some specific terms, acronyms, abbreviations, etc. are
given and explained.
Uses of SRS document
• Development team require it for developing product according to the need.
• Test plans are generated by testing group based on the describe external
behaviour.
• Maintenance and support staff need it to understand what the software product
is supposed to do.
• Project manager base their plans and estimates of schedule, effort and resources
on it.
• customer rely on it to know that product they can expect.
 CHARACTERSTICS OF GOOD SRS
SRS should be
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
Advantages of SRS
Software SRS establishes the basic for agreement between the client and the
supplier on what the software product will do.
1. A SRS provides a reference for validation of the final product.
2. A high-quality SRS is a prerequisite to high-quality software.
3. A high-quality SRS reduces the development cost.

IEEE Standards for Software Requirements Specification

(SRS)
The Software Requirements Specification (SRS) is a document that provides
a detailed description of the software system to be developed. It specifies what
the software should do and the constraints under which it must operate. The
IEEE (Institute of Electrical and Electronics Engineers) defines standards for
the preparation of an SRS, ensuring consistency, quality, and clarity across
software development projects.
The IEEE 830-1998 standard is one of the most widely recognized standards
for creating an SRS. This standard outlines the format and content that should
be included in an SRS document.
IEEE 830-1998 Standard for SRS
The IEEE 830-1998 standard for an SRS specifies that the document should be
well-structured and include the following key sections:
1. Introduction
➢ Purpose: This section describes the purpose of the SRS document,
including who the intended audience is and what they can expect to find
in the document.
➢ Scope: Defines the software product's scope, including the problem it
solves and its relationship to other products, systems, or components.
➢ Definitions, Acronyms, and Abbreviations: Any specific terms,
acronyms, and abbreviations used in the document should be clearly
defined.
➢ References: A list of references to other documents or resources relevant
to the system or requirements.
➢ Overview: A brief summary of what the SRS document covers, providing
a roadmap for the reader.
2. Overall Description
➢ Product Perspective: Describes the context of the software product,
including whether it is a stand-alone system, part of a larger system, or an
interface to other systems.
➢ Product Features: High-level overview of the major features and
capabilities the software will offer. This section should provide a summary of
what the software is expected to do.
➢ User Characteristics: Describes the expected characteristics of users
(e.g., technical skills, experience) and how they will interact with the system.
➢ Assumptions and Dependencies: Lists any assumptions made during the
development of the SRS and any dependencies on other systems, technologies,
or components.
➢ Constraints: Defines any limitations on the design or implementation of
the system (e.g., regulatory constraints, hardware limitations, time restrictions).
3. System Features
➢ This is the core section of the SRS, detailing all the functional
requirements of the software system. Each system feature should include:
▪ Description of the feature: A clear and detailed explanation of what the
feature does.
▪Functional Requirements: The specific actions or behaviors the software
must exhibit to fulfill the feature.
▪ Use Cases: Scenarios or interactions that show how the system will be used
in various situations.
4. External Interface Requirements
➢ Describes how the software interacts with other systems, hardware, or
software components.
➢ User Interfaces: Defines the layout, behavior, and user experience of the
software’s user interface.
➢ Hardware Interfaces: Specifies how the software will interact with
hardware devices.
➢ Software Interfaces: Details the interactions with other software systems
or components.
➢ Communication Interfaces: Describes how the software will
communicate over networks (e.g., protocols, APIs, data formats).
5. System Attributes
➢ Performance Requirements: Defines how well the system should
perform, including response times, throughput, or scalability.
➢ Safety Requirements: Describes any safety-critical aspects of the
system, such as preventing system failures that could cause harm.
➢ Security Requirements: Specifies the security features, such as
encryption, authentication, or access control.
➢ Reliability Requirements: Describes the expected uptime, fault
tolerance, and error handling mechanisms.
6. Other Non-Functional Requirements
➢ Quality Attributes: This section may include additional non-functional
requirements such as usability, compliance with industry standards, legal
requirements, or internationalization and localization.
➢ Constraints on Design and Implementation: Lists any restrictions on
how the system should be implemented based on technology or design
choices.
7. Appendices
➢ Contains any supplementary information that is too detailed for inclusion
in the main sections of the SRS. This could include detailed specifications for
system components, additional use cases, or mathematical models.

Benefits of IEEE 830 Standard for SRS

1. Clarity and Consistency: The standard ensures that all stakeholders have
a clear and consistent understanding of the software's requirements, reducing
the risk of miscommunication and ambiguity.
2. Complete and Structured Documentation: It provides a comprehensive
template that ensures all necessary aspects of the system are considered and
documented. This reduces the chances of leaving out critical requirements.
3. Quality Assurance: By following the IEEE 830 standard, developers,
testers, and project managers can ensure that they are all on the same page
regarding the system's functionality and constraints, improving the overall
quality of the software.

SOFTWARE QUALITY ASSURANCE

Software Quality
Our objective of software engineering is to produce good quality maintainable
software in time and within budget.
Here, quality is very important.
Different people understand different meaning of quality like:
• Conformance to requirements
• Fitness for the purpose
• Level of satisfaction
When user uses the product, and finds the product fit for its purpose, he/she
feels that product is of good quality.
Software quality assurance (SQA) consists of a means of monitoring
the software engineering processes and methods used to ensure quality.
 Every software developer will agree that high-quality software is an important
goal. Once said, "Every program does something right, it just may not be the
thing that we want it to do."
The definition serves to emphasize three important points:
1. Software requirements are the foundation from which quality is measured.
Lack of conformance to requirements is lack of quality.
2. Specified standards define a set of development criteria that guide the
manner in which software is engineered. If the criteria are not followed, lack
of quality will almost surely result.
3. A set of implicit requirements often goes unmentioned (e.g., the desire for
ease of use and good maintainability). If software conforms to its explicit
requirements but fails to meet implicit requirements, software quality is
suspect.
It is the name given to the checking and analysis process.
The purpose is to ensure that the software conforms to its specifications and
meets the need of the customer.
Verification represents the set of activities that are carried out to confirm that
the software correctly implements the specific functionality.
Validation represents set of activities that ensure that the software that has built
is satisfying the customer requirements.

In the verification and validation, two techniques of system checking and

analysis may be used: -
1. Software Inspection
2. System testing
The testing can be carried out using following tests:-
i. Unit testing
ii. Module testing
iii. System testing
 iv. Acceptance testing

DIFFERENCE BETWEEN VERIFICATION AND

VALIDATION
Verification Validation

Are we building the product right? Are we building the right product?

Ensure that the software system meets all the functionality Ensure that the functionalities meet the intended behavio

Verifications take place first and include the checking for Validation occurs after verification and mainly involves th
documentation, code etc checking of the overall product.

Done by developers Done by testers

Have static activities as it includes the reviews, walk-throughs Have dynamic activities as it includes executing the softw
and inspections to verify that software is correct or not against the requirements.

SOFTWARE QUALITY ASSURANCE PLAN'S

A software quality assurance plan's main goal is to guarantee that the market's
product or service is trouble- and bug-free. Additionally, it must fulfill the
specifications listed in the SRS (software requirement specification).
An SQA plan serves three purposes. It includes the following:
• Determining the QA duties assigned to the concerned team.

• A list of the areas that require review, audit, and examination.

• Determines the work products for SQA.
A Quality Assurance Plan (QAP) is a document or set of documents that
outlines the systematic processes, procedures, and standards for ensuring the
quality of a product or service. It is a key component of quality management
and is used in various industries to establish and maintain a consistent level of
quality in deliverables. For a software product or service, an SQA plan will be
used in conjunction with the typical development, prototyping, design,
production, and release cycle. An SQA plan will include several components,
such as purpose, references, configuration and management, tools, code
controls, testing methodology, problem reporting and remedial measures, and
more, for easy documentation and referencing.
Steps to Develop Software Quality Assurance Plan:
Developing a Quality Assurance Plan (QAP) involves a systematic process to
ensure that the plan effectively addresses the quality requirements of a project
or process. Here are the steps to develop a Quality Assurance Plan:
Define Project Objectives and Scope:
• Clearly articulate the objectives and scope of the project or process for which

the Quality Assurance Plan is being developed. Understand the goals,

deliverables, and stakeholders involved.
Identify Quality Standards and Criteria:
• Determine the relevant quality standards, regulations, and criteria that are

applicable to the project. This may include industry standards, legal

requirements, and internal organizational standards.
Identify Stakeholders:
• Identify and involve key stakeholders who have an interest in or will be

affected by the quality of the project or process. This includes project

managers, team members, customers, and any regulatory bodies.
Define Roles and Responsibilities:
• Clearly define the roles and responsibilities of individuals or teams involved

in quality assurance activities. This ensures accountability and clarity in the

execution of quality-related tasks.
Conduct a Risk Assessment:
• Identify potential risks to the quality of the project. Assess the impact and

likelihood of these risks and develop strategies for risk mitigation and
management.
Establish Quality Assurance Activities:
• Determine the specific activities and tasks that will be carried out to ensure

quality throughout the project lifecycle. This may include reviews,

inspections, audits, testing, and other quality control measures.
Develop Testing and Inspection Procedures:
• If applicable, create detailed testing and inspection procedures. This includes

developing test plans, test cases, and acceptance criteria to ensure that the
product or service meets quality standards.
Document Processes and Procedures:
• Document the processes and procedures that will be followed to implement

quality assurance activities. This documentation serves as a reference for team

members and provides a basis for consistency.
Establish Documentation and Reporting Mechanisms:
• Define the documentation requirements for tracking and reporting quality-

related information. This may include reports, checklists, and records of

quality assessments.
Allocate Resources and Training:
• Specify the resources, tools, and training that will be provided to team

members to support quality assurance efforts. Ensure that team members have
the necessary skills and knowledge.
Define Change Control Processes:
• Establish a process for managing changes to the project or product to ensure

that they do not negatively impact quality. This includes a change control
board and a structured process for reviewing and approving changes.
Review and Approval:
• Seek input and feedback from relevant stakeholders on the draft Quality

Assurance Plan. Revise the plan based on feedback and obtain formal approval
before implementation.
Monitoring and Continuous Improvement:
• Continuously monitor quality metrics, track progress, and identify

opportunities for improvement. Regularly review and update the Quality

Assurance Plan to adapt to changes and enhance its effectiveness.
Communication and Training:
• Communicate the Quality Assurance Plan to all relevant stakeholders and

provide training as necessary. Ensure that everyone involved understands their

roles and responsibilities in maintaining and improving quality.
Pros of Software Quality Assurance Plan:
• Early Defect Identification: SQA strategies lessen the possibility of

expensive problems later in the software development life cycle by facilitating

the early discovery and resolution of flaws.
• Enhanced Quality of Product: SQA plans help to improve the overall
quality of the software product by setting quality standards and procedures,
which raises customer satisfaction.
• Adherence to the standards: It plans guarantee adherence to industry norms,
legal mandates, and optimal methodologies, offering a structure for producing
software of superior quality.
• Improved Cooperation Among Teams: The SQA plan's well-defined roles
and duties encourage productive teamwork and guarantee that everyone is on
the same page with the quality goals.
Cons of Software Quality Assurance Plan:
• Overhead in Small Projects: The cost of developing and upholding a

detailed SQA plan may be excessive for small projects compared to their
scope and complexity.
• Opposition to Change: An SQA strategy may involve changes that teams
accustomed to their current workflows find difficult to accept, which could
result in a time of adjustment and resistance.
• Documentation Complexity: SQA plans with high documentation
requirements run the risk of adding complexity and coming off as bureaucratic
to teams, which makes it difficult to keep documentation up to date.
Software Quality Framework
Software Quality Framework connects the customer view with the developer’s
view of software quality and it treats software as a product.
1.The software product view describes the characteristics of a product that
bear on its ability to satisfy stated and implied needs.
2.This is a framework that describes all the different concepts relating to
quality in a common way measured by a qualitative scale that can be
understood and interpreted commonly.
Developers View
Validation and verification are two independent methods used together to
check that a software product meets the requirements and that it fulfills its
intended purpose.
 1. The primary concern for developers is in the design and engineering
processes involved in producing software.
2. 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.
3. While validation and verification are used by the developers to improve the
software, the two methods don’t represent a quantifiable quality measurement.
For example, the customer understands or describes the quality of operation
as meeting the requirement while the developers use different factors to describe
the software quality. The developer view of quality in the software is influenced
by many factors. This model stresses on 3 primary ones:
The code: It is measured by its correctness and reliability.
The data: The application integrity measures it.
Maintainability: It has different measures the simplest is the mean time to
change.
Users View
When the user acquires software, he/she always expect a high-quality
software. When end users develop their software then quality is different. End-
user programming, a phrase popularized by which is programming to achieve
the result of a program primarily for personal, rather than public use.
1. The important distinction here is that software itself is not primarily
intended for use by many users with varying needs.
2. For example, a teacher may write a spreadsheet to track student’s test scores.
3. In these end-user programming situations, the program is a means to an end
that could be used to accomplish a goal.
4. In contradiction to end-user programming, professional programming has
the goal of producing software for others to use.
Product View
 The product view describes quality as correlated to inherent characteristics of
the product. Product quality is defined as the set of characteristics and features
of a product that gives contribution to its ability to fulfill given requirements.
1. 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.
2. According to the users, a high-quality product is one that satisfies their
expectations and preferences while meeting their requirement.

Methods for SQA

The methods by which quality assurance is accomplished are many and varied,
out of which, two are mentioned as follows:
1. ISO 9000
2. Capability Maturity Model
ISO 9000
• “ISO” (International Organization for Standardization) in greek means
“equal”, so the association wanted to convey the idea of equality.
• It is an attempt to improve software quality based on ISO 9000 series
standards.
• It has been adopted by over 130 countries including India and Japan.
• It can be interpreted by the developers to diverse projects such as hair dryers,
automobiles, televisions as well as software.
• ISO-9000 applies to all types of organizations.
• After adopting the standards, a country typically permits only ISO registered
companies to supply goods and services to government agencies and public
utilities.
• ISO-9000 series is not just software standard, but are applicable to a wide
variety of industrial activities including design/development, production,
installation and servicing.

ISO 9000 Certification

This process consists of following stages: -

1. Application
2. Pre-assessment
3. Document review and adequacy of audit
4. Compliance audit
5. Registration
6. Continued surveillance

ISO 9000 Series

The types of software industries to which the different ISO standards apply are
as follows:
ISO 9001: This standard applies to the organization engaged in design,
development, production & servicing of goods. This is the standard that is
applicable to most software development organization.
ISO 9002: This standard applies to the organization which do not design
products but only involved in production. Ex. Car manufacturing industries.
ISO 9003: This standard applies to the organization involved only in installation
and testing of the products.
Benefits of ISO 9000 Certification
1. Continuous Improvement
2. Improved Customer Satisfaction
3. Eliminate Variations
4. Better product and Services
5. Improved Profit levels
6. Improved Communication
7. Reduced Cost
Why ISO Certification required by Software Industry?
There are several reasons why software industry must get an ISO certification.
Some of reasons are as follows:
• This certification has become a standard for international bidding.

• It helps in designing high-quality repeatable software products.

• Its emphasis need for proper documentation.
•It facilitates development of optimal processes and totally quality
measurements.
 CAPABILITY MATURITY MODEL (CMM)
It was developed by Software Engineering Institute (SEI) of Carnegie
Mellon University in 1986.
It specifies an increasing series of levels of a software development
organization. The higher the level, the better the software development
process.
It can be used in two ways: Capability evaluation and Software
process assessment.

CMM Levels

Level One :Initial - The software process is characterized as

inconsistent, and occasionally even chaotic. Defined processes
and standard practices that exist are abandoned during a crisis.
Success of the organization majorly depends on an individual
effort, talent, and heroics. The heroes eventually move on to
other organizations taking their wealth of knowledge or lessons
learnt with them.
Level Two: Repeatable - This level of Software Development
Organization has a basic and consistent project management
processes to track cost, schedule, and functionality. The process
is in place to repeat the earlier successes on projects with similar
applications. Program management is a key characteristic of a
level two organization.
Level Three: Defined - The software process for both
management and engineering activities are documented,
standardized, and integrated into a standard software process for
the entire organization and all projects across the organization
use an approved, tailored version of the organization's standard
software process for developing, testing and maintaining the
application.
Level Four: Managed - Management can effectively control
the software development effort using precise measurements. At
this level, organization set a quantitative quality goal for both
software process and software maintenance. At this maturity
level, the performance of processes is controlled using statistical
and other quantitative techniques, and is quantitatively
predictable.
Level Five: Optimizing - The Key characteristic of this level is
focusing on continually improving process performance through
both incremental and innovative technological improvements.
At this level, changes to the process are to improve the process
 performance and at the same time maintaining statistical
probability to achieve the established quantitative process-
improvement objectives

Comparison of ISO-9000 Certification & SEI-CMM

ISO 9000 SEICMM

ISO 9000 is a set of international

SEI (Software Engineering Institute),
standards on quality management and
Capability Maturity Model (CMM)
quality assurance developed to help
specifies an increasing series of levels
companies effectively document the
of a software development
quality system elements needed to an
organization.
efficient quality system.
ISO 9000 SEICMM

Focus on the software supplier to

Focus is customer supplier relationship,
improve its interval processes to
attempting to reduce customer’s risk in
achieve a higher quality product for
choosing a supplier.
the benefit of the customer.

It is created for hard goods manufacturing

It is created for software industry.
industries.

ISO9000 is recognized and accepted in SEICMM is used in USA, less widely

most of the countries. elsewhere.

CMM provides detailed and specific

It specifies concepts, principles and
definition of what is required for given
safeguards that should be in place.
levels.

This establishes one acceptance level. It assesses on 5 levels.

Its certification is valid for three years. It has no limit on certification.

It focuses on inwardly processes. It focuses outwardly.

ISO 9000 SEICMM

It has 5 levels:

(a). Initial
(b). Repeatable
It has no level.
(c). Defined
(d). Managed
(e). Optimized

It is basically an audit. It is basically an appraisal.

It is open to multi sector. It is open to IT/ITES.

Follow set of standards to make success It emphasizes a process of continuous

repeatable. improvement.
 IMP QUESTIONS
1. Write the methods of requirements elicitation.
2. Write the differences between software and software engineering.
3. What is the difference between Verification and Validation?
4. What is meant by “Formal Technical Review”? Should it access both
programming style as well as correctness of software? Give reasons.
5. Compare ISO and SEE-CMI model.
6. What is a data flow diagram? Explain rules for drawing good data flow
diagrams with the help of a suitable example.
7. Explain software quality assurance (SQA) with life cycle.
8. List five desirable characteristics of good SRS document. Discuss the
relative advantages of formal and informal requirement specifications.
9. What is Decision Tree?
10. Explain CMM Model. Compare ISO and CMM.
11. Explain different methods of verification in detail
12. List the process maturity levels in SEI's CMM
13. Draw the Context level DFD for the Safe home Software
14. Explain the feasibility studies. What are the outcomes? Does it have
either implicit or explicit effects on software requirement collection
15. Narrate the importance of software specification of requirements.
Explain a typical SRS structure and its parts.
16. Create a level-2 DFD of the Smart College Campus.
17. Discuss the importance of software specification Document. And also
explain the typical IEEE format of SRS document.
18. Discuss about decision tables and its components. Create a decision
table. for the following scenario; a bookstore gets a trade discount of 25% for
order more than 6 books; for order from libraries and individuals, 5% allowed
on orders of 6-19 copies per book title; 10% on orders for 20-49 copies per
book title; 15% on orders for 50 copies or more per book title.
19. Discuss the various Mc Call’s quality factors with quality triangle.
20. What are the various stages of requirement engineering process? Explain
it with diagrammatic representation.
21. Discuss the importance of Feasibility Study. Also discuss its various
types.
22. Explain Code Inspection, Formal Technical Reviews (Peer Reviews) and
Walk Through in detail.