SOFTWARE ENGINEERING

"The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software; that is, the application of
engineering to software."

Software Requirements
Software Requirements: A comprehensive description of the intended
functionality and behavior of a software system, focusing on what the system will
do without specifying how it will do it. These requirements define the desired
external behavior of the software to be developed.

Software requirements may be:

Abstract statements of services: Broad descriptions of the services or functions

that the software system will provide.

Detailed mathematical functions: Precise specifications of mathematical

algorithms, computations, or operations that the software will perform.

Part of the bid of contract: Software requirements may be included as part of a

bid for a contract, outlining what the software will deliver to meet the client's
needs.

The contract itself: In some cases, software requirements may be formalized

within the contract between the client and the software development team,
serving as the basis for agreement on project scope and deliverables.

Part of the technical document, which describes a product: Software

requirements are often documented as part of technical documentation,
providing a comprehensive understanding of the product's intended functionality
and behavior.

REQUIREMENT
"A requirement in software engineering is a documented description of a
capability, function, or constraint that a software system must satisfy or possess
to meet stakeholder needs and project objectives."

 Requirements serve as the foundation for designing, developing, and

testing software solutions.
 They are typically gathered from stakeholders, including users, customers,
and other relevant parties, and are documented in various forms to ensure
clarity and completeness throughout the software development lifecycle.

IEEE Definition of Requirement

A condition or capability that must be met or possessed by a
system or system component to solve a problem or to achieve
an objective.

Need: Something that is essential or necessary, something one must have to fulfill
a requirement or achieve a certain purpose.

Want: Something desired or wished for, something that would bring satisfaction
or pleasure, but is not essential for survival or fulfillment of basic requirements.

Requirement Engineering
Requirements Engineering (RE) is the systematic process of development,
elicitation, specification, analysis, and management of stakeholder requirements
that need to be fulfilled by a new or evolving system.

Development, Elicitation, Specification, Analysis, and Management: RE involves

various activities, including developing, eliciting, specifying, analyzing, and
managing requirements. These activities ensure that the needs and expectations
of stakeholders are clearly understood and documented.

Identifying System Purpose and Context: RE aims to identify the purpose of a

software system and understand the contexts in which it will be used. This
involves analyzing how and where the system will be utilized, considering factors
such as user environment, constraints, and dependencies.

Capturing Real World Needs: RE focuses on capturing the real-world needs of

stakeholders who will be affected by the software system. It involves gathering
requirements from various stakeholders and expressing them as artifacts that can
be understood and implemented by a computing system.

Bridge to Design and Construction: RE serves as a bridge between stakeholder

requirements and the design and construction phases of the development
process. It ensures that the final design and implementation of the system align
with the specified requirements.

Communication and Negotiation: RE involves effective communication and

negotiation among stakeholders to ensure that their needs and expectations are
accurately captured and addressed. This may require techniques such as
interviews, workshops, and prototyping to facilitate collaboration and consensus
building.

Translation Between Different Worlds: RE acknowledges the challenge of

translating stakeholder needs and requirements into technical specifications and
software features. It strives to minimize the loss of information and fidelity during
this translation process by using clear documentation, models, and feedback
mechanisms.

Overall, RE plays a crucial role in ensuring the success of software development

projects by facilitating a clear understanding of stakeholder needs, guiding the
design and implementation process, and enabling effective communication and
collaboration among project stakeholders.
SRE Activities/phases (REP)
The activities outlined align with the process of System Requirements Engineering
(SRE), which involves various stages to ensure that system requirements are
properly identified, analyzed, documented, validated, and managed.

Inception:

This activity marks the beginning of the SRE process. It involves identifying the
business need, market opportunity, or idea that triggers the development of the
system. During this phase, a business case is developed to justify the investment
in the project. Feasibility studies are conducted to assess the technical, financial,
and organizational feasibility of the project. Additionally, the system scope is
defined, along with an analysis of potential risks.

Requirements Elicitation:

In this activity, requirements are discovered and gathered through consultation

with stakeholders, including end-users, customers, and other relevant parties.
Various techniques such as interviews, surveys, workshops, and observations may
be employed to elicit requirements effectively.

Requirements Analysis:

Once requirements are gathered, they are analyzed to identify inconsistencies,

conflicts, and ambiguities. This activity involves understanding the needs and
expectations of stakeholders and resolving conflicts through negotiation. The goal
is to ensure that the requirements are clear, complete, and feasible.

Requirements Specification:

This activity involves documenting the requirements in a precise and structured

manner. The requirements document serves as a formal agreement between
stakeholders and the development team regarding the functionality and
characteristics of the system. It typically includes details such as functional
requirements, non-functional requirements, and any constraints or dependencies.
Requirements Validation:

After the requirements are specified, they are validated to ensure that they
accurately reflect the needs and expectations of stakeholders. This activity
involves checking the requirements document for consistency, completeness, and
correctness. Reviews, inspections, and walkthroughs may be conducted to
validate the requirements.

Requirements Management:

Requirements management is an ongoing activity throughout the SRE process. It

involves tracking changes to requirements, assessing their impact, and ensuring
that they are properly documented, evaluated, and approved before
implementation. As needs and contexts evolve, requirements may need to be
updated, and the requirements management process helps ensure that changes
are effectively managed.

By following these activities, organizations can effectively manage the

requirements engineering process and ensure that system requirements are
properly identified, analyzed, documented, validated, and managed throughout
the software development lifecycle.

Limitations of REP
Lack of Expertise: One limitation is the absence of the necessary expertise,
including software engineers and domain experts. Without these skilled
professionals, the requirement engineering process may suffer from incomplete
or inaccurate requirements.

Incomplete Initial Ideas: Initial ideas are often incomplete, wildly optimistic, and
firmly entrenched in the minds of those leading the acquisition process. This can
lead to unrealistic expectations and make it hard to gather accurate
requirements.

Complex Tools and Methods: Using different tools and methods for gathering
requirements can be tough. If stakeholders find them hard to use, it might
undermine(demininsh/hinder) the benefits of a thorough requirement
engineering approach.

NIST
70% of defects are introduced in the specification phase:

This statistic indicates that a significant portion of defects in software systems

originate during the specification phase. This phase involves gathering and
documenting requirements, and any inaccuracies, ambiguities, or
misunderstandings during this phase can lead to defects in the final product.

30% are introduced later in the technical solution process:

While a substantial number of defects originate in the specification phase, some

defects are introduced during the subsequent phases of the development
process, such as design, implementation, and testing. These defects may arise due
to errors in translating requirements into technical solutions, coding errors, or
integration issues.

Only 5% of specification inadequacies are corrected in the specification phase:

This statistic suggests that a small percentage of inadequacies or errors identified

during the specification phase are corrected at that stage. It indicates that there
may be challenges in identifying and addressing specification issues early in the
development process.

95% are detected later in the project or after delivery where the cost for
correction on average is 22 times higher compared to a correction directly during
the specification effort:

The majority of specification inadequacies or defects are not detected until later
stages of the project or even after the software is delivered to users. This delayed
detection significantly increases the cost of corrections, with corrections made
after delivery being, on average, 22 times more expensive than those made
during the specification phase.
Requirement Engineering (RE) involves various activities and documents to ensure
that the needs and expectations of stakeholders are accurately captured and
translated into specifications for the software system. Here are some key
activities and associated documents in the RE process:

Requirements Elicitation:

Activity: Gathering requirements from stakeholders through interviews,

workshops, surveys, and observations.

Documents: Stakeholder interviews, requirements workshop notes, surveys, user

personas, and user stories.

Requirements Analysis:

Activity: Analyzing gathered requirements to identify inconsistencies, conflicts,

and ambiguities.

Documents: Requirement analysis reports, use case diagrams, data flow diagrams,
and domain models.

Requirements Specification:

Activity: Documenting requirements in a precise and structured manner.

Documents: Requirement specification documents, including functional

requirements, non-functional requirements, and constraints. Examples include
Software Requirements Specification (SRS) documents, use case specifications,
and interface specifications.

Requirements Validation:

Activity: Validating requirements with stakeholders to ensure they accurately

reflect their needs and expectations.

Documents: Requirements validation reports, stakeholder review feedback, and

traceability matrices.

Requirements Management:
Activity: Managing changes to requirements throughout the software
development lifecycle.

Documents: Requirement change requests, requirement traceability matrices

(RTMs), and requirement version control logs.

Requirements Traceability:

Activity: Establishing and maintaining traceability between requirements and

other artifacts.

Documents: Traceability matrices (RTMs), which map requirements to design,

implementation, and testing artifacts.

Requirements Communication:

Activity: Communicating requirements to stakeholders and team members in a

clear and understandable manner.

Documents: Requirement presentation slides, user interface mockups, and

prototypes.

Requirements Review and Approval:

Activity: Reviewing and obtaining approval from stakeholders on the finalized

requirements.

Documents: Requirement review meeting minutes, sign-off sheets, and approval

emails.

Requirements Documentation:

Activity: Maintaining comprehensive documentation of requirements throughout

the project lifecycle.

Documents: All the documents mentioned above, as well as any other artifacts
created during the RE process.
These activities and documents play a crucial role in ensuring that requirements
are effectively captured, analyzed, documented, validated, and managed
throughout the software development process. They provide a structured
approach to requirement engineering, helping to minimize misunderstandings,
errors, and discrepancies that can arise during software development.

Document
A document is a written or digital record that provides information, instructions,
or evidence about a particular subject or topic. In the context of software
development, documents serve as important artifacts that capture various
aspects of the project, such as requirements, specifications, design, and plans.
These documents help stakeholders understand the project's goals, scope, and
constraints, as well as guide the development team in implementing the project
effectively.

Types of document
Vision and Scope Document:
Description: Records the business requirements, constraints, and organizational
rules for the project.

Author: Typically written by a business analyst.

User Requirements Document:

Description: Documents the needs and expectations of stakeholders, including
user stories and event-response tables. May include use cases if the methodology
is object-oriented (OO).

Author: Typically involves input from various stakeholders.

Interface Specification:
Description: Describes the external interface between the product and its
environment, as well as internal interfaces among components. It may include the
graphical user interface (GUI) at a basic level.

Author: Typically involves input from user experience (UX) designers and
developers.

Software Requirements Specification (SRS):

Description: Provides a comprehensive overview of the complete requirements
and specifications of the proposed product. It's a milestone of the software
requirement engineering (SRE) phase and includes requirements traceability.

Author: Typically written by the requirements engineering team with input from
stakeholders.

TYPES OF REQUIREMENT
Requirements can be categorized into different types, including:

Functional Requirements: These specify the functions, capabilities, or tasks that

the software system must perform. They describe what the system should do in
response to specific inputs or under certain conditions.

Non-functional Requirements: Also known as quality attributes or constraints,

these specify the qualities or properties that the software system must possess,
such as performance, reliability, usability, security, and scalability.

User Requirements: These describe the needs, preferences, and expectations of

the system's users, including their interactions with the software and the
outcomes they expect to achieve.

System Requirements: These define the overall characteristics and behavior of

the software system, including its interfaces with other systems, hardware
requirements, and external dependencies.
Business Requirements: These specify the business goals, objectives, and
constraints that the software solution is intended to address, aligning with the
broader objectives of the organization or project.

Functional Prototypes: Sometimes, requirements are documented through

functional prototypes or mockups, which provide a visual representation of the
desired system behavior or user interface.

WHY WE NEED REQUIREMENT ENGINEERING?

Requirement engineering is crucial in software development for several reasons:

Understanding Stakeholder Needs: Requirement engineering helps in

comprehensively understanding the needs, expectations, and constraints of
stakeholders, including end-users, customers, and business owners.

Defining Scope: It helps in clearly defining the scope of the project, what needs to
be delivered, and what features are essential for the software system.

Minimizing Risks: Properly gathering and analyzing requirements help in

identifying potential risks and challenges early in the project lifecycle, allowing
teams to address them proactively.

Avoiding Costly Changes: By capturing and documenting requirements accurately

upfront, teams can avoid costly changes and rework later in the development
process.

Guiding Design and Development: Requirements serve as a blueprint for

designing and developing the software system, providing guidance on what
functionalities to build and how to implement them.

Ensuring Stakeholder Satisfaction: Meeting the stated requirements ensures that

the software system meets stakeholder expectations and provides value to end-
users and customers.
Facilitating Communication: It facilitates communication and collaboration
among stakeholders, project managers, developers, and testers, ensuring
everyone has a common understanding of project goals and objectives.

Maintaining Traceability: Documenting requirements enables traceability

throughout the development process, helping to ensure that every feature or
functionality implemented aligns with the specified requirements.

In essence, requirement engineering is essential for ensuring that software

projects are delivered successfully, meeting stakeholder needs, and achieving
project objectives while minimizing risks and costs.

How does SDLC work?

The Software Development Life Cycle (SDLC) is a structured process guiding
software projects from inception to completion. It begins with initiation, where
project goals and requirements are identified, stakeholders are engaged, and
teams are assembled. Planning follows, detailing project tasks, timelines, and
resources, while analysis focuses on gathering and prioritizing requirements.
Designing entails creating system architectures and detailed plans, leading to
implementation, where coding and development occur according to
specifications. Testing ensures software meets quality standards, paving the way
for deployment to production environments or end-users. Maintenance then
takes over, addressing issues, updating, and enhancing the software as needed.
Throughout the SDLC, thorough monitoring and management ensure projects
stay on track, delivering successful outcomes that meet stakeholder needs and
expectations.

PHASES OF SDLC
Plan

The planning phase typically includes tasks like cost-benefit analysis, scheduling,
resource estimation, and allocation. The development team collects requirements
from several stakeholders such as customers, internal and external experts, and
managers to create a software requirement specification document.
The document sets expectations and defines common goals that aid in project
planning. The team estimates costs, creates a schedule, and has a detailed plan to
achieve their goals.

Design

In the design phase, software engineers analyze requirements and identify the
best solutions to create the software. For example, they may consider integrating
pre-existing modules, make technology choices, and identify development tools.
They will look at how to best integrate the new software into any existing IT
infrastructure the organization may have.

Implement

In the implementation phase, the development team codes the product. They
analyze the requirements to identify smaller coding tasks they can do daily to
achieve the final result.

Test

The development team combines automation and manual testing to check the
software for bugs. Quality analysis includes testing the software for errors and
checking if it meets customer requirements. Because many teams immediately
test the code they write, the testing phase often runs parallel to the development
phase.

Deploy

When teams develop software, they code and test on a different copy of the
software than the one that the users have access to. The software that customers
use is called production, while other copies are said to be in the build
environment, or testing environment.

Having separate build and production environments ensures that customers can
continue to use the software even while it is being changed or upgraded. The
deployment phase includes several tasks to move the latest build copy to the
production environment, such as packaging, environment configuration, and
installation.

Maintain

In the maintenance phase, among other tasks, the team fixes bugs, resolves
customer issues, and manages software changes. In addition, the team monitors
overall system performance, security, and user experience to identify new ways
to improve the existing software.

Stakeholders: These are the people or groups who are interested in or affected by
the software. They could be users, customers, managers, or others involved in the
project. They share what they need and want from the software, so it meets their
expectations and solves their problems.

Documents: These are papers or files that provide information about the project.
They include things like project plans, stories about what users need, rules from
the government, and contracts with clients. These documents explain what the
software should do and how it should work.

Application Domain: This means the specific area or field where the software will
be used. For example, it could be healthcare, finance, or education. The
requirements come from what people in that area need and what rules they must
follow. This makes sure the software fits well and does what it needs to do in that
particular field.

Existing System: This refers to any software or systems that are already in place
and might be replaced or changed. By looking at what's already there and what
people like or don't like about it, we can figure out what the new software should
do. This helps make sure the new software is better and meets the needs of the
users.
The goal of software development
The goal of software development is to create high-quality software that meets
the needs and expectations of stakeholders while being delivered on time and
within budget. This means:

Developing software that is correct, reliable, maintainable, and user-friendly.

Ensuring that the total cost incurred over all phases of the software's life cycle is
kept minimal and within the allocated budget.

Importance of software requirements

software requirements are crucial because they:

 Provide a clear roadmap for development.

 Ensure effective communication and collaboration among stakeholders.
 Guide decision-making and resource allocation.
 Tailor the software to meet user needs and preferences.
 Mitigate risks and ensure compliance with regulations.
 Ultimately contribute to the delivery of high-quality software that satisfies
stakeholders.

The root causes of project success and failure can vary, but there are some
common factors that tend to emerge across different projects. The following
factors influencing both success and failure:

Factors Contributing to Project Failure:

Lack of User Input: When end-users are not actively involved in the project,
there's a higher chance of misalignment between the final product and user
expectations.

Incomplete Requirements and Specifications: Unclear or ambiguous requirements

can lead to misunderstandings, scope creep, and ultimately project delays or
failures.
Changing Requirements and Specifications: Flexibility is important, but excessive
changes without proper management can disrupt project timelines and budgets.

Unrealistic Schedule or Time Frame: Setting unattainable deadlines can put undue
pressure on the project team, leading to rushed work, quality compromises, and
missed milestones.

Inadequate Staffing and Resources: Insufficient human resources, budget

constraints, or lack of necessary tools can impede progress and hinder the
project's success.

Inadequate Technology Skills: If the project team lacks the necessary expertise to
utilize the chosen technology effectively, it can result in errors, rework, and
project setbacks.

Factors Contributing to Project Success:

User Involvement: Actively engaging end-users throughout the project lifecycle
ensures that their needs and preferences are incorporated, leading to greater
satisfaction with the final product.

Executive Management Support: Strong support from top-level management

provides the necessary resources, authority, and strategic direction to overcome
obstacles and drive the project forward.

Clear Statement of Requirements: Well-defined and documented requirements

set clear expectations for the project deliverables, reducing the likelihood of
misunderstandings or scope changes.

The high cost of requirement errors, also known as defect leakage, refers to the
significant financial and operational consequences that arise from errors or
defects in the requirements phase of a software development project. These
errors can lead to expensive rework, redesign, and other corrective actions
throughout the project lifecycle. Properly understanding this concept is essential
for learning and writing purposes in the context of software engineering and
project management.
Here's a breakdown of the key points:

Unit Cost of Error Detection and Repair: Assigning a unit cost (e.g., one unit) to
the effort required to detect and repair an error during the coding stage helps
quantify the financial impact of defects at different stages of the project.

Categories of Errors in the Design Phase:

Errors stemming from creating technical designs based on a correct set of

requirements.

Errors "leaked" into the design phase, where requirements are misunderstood or
misinterpreted.

Costly Nature of Leaked Errors:

Errors leaked into the design phase are particularly expensive due to:

Potential need to discard or rework the design.

Difficulty in identifying the true nature of the error, leading to additional rework
and costs.

Study Findings on Defect Leakage:

Research by Snyder and Shumate (1992) highlights the extent of defect leakage in
software development projects.

The study reveals that a significant portion (74%) of requirement-oriented defects

are discovered during the requirement analysis phase.

Some defects may not surface until the maintenance phase, constituting 4% of
requirement errors.

Impact of Defects on Cost:

Defects discovered in later phases of development, such as maintenance, can

incur significantly higher costs compared to those found earlier. The study
suggests that the cost multiplier for a defect detected in a software application
could range from 50 to 100 times the cost, considering activities such as re-
specification, redesign, recoding, retesting, corrective action, scrap, warranty
costs, product liability, service costs for field visits, and documentation.