Software Engineering:

It is a systematic, disciplined and cost-effective technique to build a software.

OR Engineering approach to develop a software.

Software Requirements Engineering:

Software requirements engineering refers to the first phase, before any of the actual designing, coding,
testing, or maintenance takes place. The goal is to create an important early document and process in the
software design. Often referred to as software requirements specification, or SRS, it determines what
software is produced. It is basically the gathering of information of a customer's or potential
customer/target audience's requirements for a system, before any actual design takes place.

KINDS of software requirements:

1. Functional requirements
2. Non-functional requirements
3. Domain requirements

• Functional requirements
These are the requirements that the end user specifically demands as basic facilities that the system
should offer. It can be a calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform. Functional
Requirements in Software Engineering are also called Functional Specification.

• Non-functional requirements:
These are basically the quality constraints that the system must satisfy according to the project contract.
Non-functional requirements, not related to the system functionality, rather define how the system
should perform The priority or extent to which these factors are implemented varies from one project
to other. They are also called non-behavioral requirements. They basically deal with issues like:

➢ Portability
➢ Security
➢ Maintainability
➢ Reliability
➢ Scalability
➢ Performance
➢ Reusability
➢ Flexibility
• Domain requirements:
Domain requirements are the requirements which are characteristic of a particular category or domain
of projects. Domain requirements can be functional or nonfunctional. Domain requirements
engineering is a continuous process of proactively defining the requirements for all foreseeable
applications to be developed in the software product line.
Another view of requirement:
A viewpoint is a way of organising the requirements for a software system, based on some perspective
such as an end-user perspective or a manager's perspective.

A key strength of viewpoint-oriented analysis is that it recognizes the existence of multiple perspectives
and provides a framework for discovering conflicts in the requirements proposed by different
stakeholders. Viewpoints can be used as a way of classifying different types of stakeholder and other
sources of requirements.

There are three generic types of viewpoints:

• Interactor viewpoints that represent people or other systems that interact directly with the
system. In the bank ATM system, examples of interactor viewpoints are the bank’s
customers and the bank’s account database.
• Indirect viewpoints that represent stakeholders who do not use the system themselves but
who influence the requirements in some way. In the bank ATM system, examples of
indirect viewpoints are the management of the bank and the bank security staff.
• Domain viewpoints that represent domain characteristics and constraints that influence
the system requirements. In the bank ATM system, an example of a domain viewpoint
would be the standards that have been developed for inter-bank communications.

software process model:

A software process model is an abstraction of the software development process. The models specify the
stages and order of a process. So, think of this as a representation of the order of activities of the process
and the sequence in which they are performed.

A model will define the following:

The tasks to be performed

The input and output of each task

The pre and post-conditions for each task

The flow and sequence of each task

TYPE of software process models

As we mentioned before, there are multiple kinds of software process models that each meet different
requirements. Below, we will look at the top seven types of software process models that you should know.

Waterfall Model:

The waterfall model is a sequential, plan driven-process where you must plan and schedule all your
activities before starting the project. Each activity in the waterfall model is represented as a separate phase
arranged in linear order.

It has the following phases:

 • Requirements
• Design
• Implementation
• Testing
• Deployment
• Maintenance
Each of these phases produces one or more documents that need to be approved before the next phase
begins. However, in practice, these phases are very likely to overlap and may feed information to one
another.

The software process isn’t linear, so the documents produced may need to be modified to reflect
changes.

The waterfall model is easy to understand and follow. It doesn’t require a lot of customer involvement
after the specification is done. Since it’s inflexible, it can’t adapt to changes. There is no way to see or try
the software until the last phase.

The waterfall model has a rigid structure, so it should be used in cases where the requirements are
understood completely and unlikely to radically change.

V Model:

The V model (Verification and Validation model) is an extension of the waterfall model. All the
requirements are gathered at the start and cannot be changed. You have a corresponding testing activity
for each stage. For every phase in the development cycle, there is an associated testing phase.

The corresponding testing phase of the development phase is planned in parallel, as you can see above.

The V model is highly disciplined, easy to understand, and makes project management easier. But it isn’t
good for complex projects or projects that have unclear or changing requirements. This makes the V model
a good choice for software where downtimes and failures are unacceptable.

Incremental Model:

The incremental model divides the system’s functionality into small increments that are delivered one
after the other in quick succession. The most important functionality is implemented in the initial
increments.

The subsequent increments expand on the previous ones until everything has been updated and
implemented.

Incremental development is based on developing an initial implementation, exposing it to user feedback,

and evolving it through new versions. The process’ activities are interwoven by feedback.

Each iteration passes through the requirements, design, coding, and testing stages.

The incremental model lets stakeholders and developers see results with the first increment. If the
stakeholders don’t like anything, everyone finds out a lot sooner. It is efficient as the developers only focus
on what is important and bugs are fixed as they arise, but you need a clear and complete definition of
the whole system before you start.
The incremental model is great for projects that have loosely coupled parts and projects with complete
and clear requirements.

Iterative Model:

The iterative development model develops a system by building small portions of all the features. This
helps to meet the initial scope quickly and release it for feedback.

In the iterative model, you start off by implementing a small set of software requirements. These are
then enhanced iteratively in the evolving versions until the system is completed. This process model
starts with part of the software, which is then implemented and reviewed to identify further requirements.

Like the incremental model, the iterative model allows you to see the results at the early stages of
development. This makes it easy to identify and fix any functional or design flaws. It also makes it
easier to manage risk and change requirements.

The deadline and budget may change throughout the development process, especially for large complex
projects. The iterative model is a good choice for large software that can be easily broken down into
modules.

RAD Model:

The Rapid Application Development (RAD model) is based on iterative development and prototyping
with little planning involved. You develop functional modules in parallel for faster product delivery. It
involves the following phases:

Business modeling

Data modeling

Process modeling

Application generation

Testing and turnover

The RAD concept focuses on gathering requirements using focus groups and workshops, reusing software
components, and informal communication.

The RAD model accommodates changing requirements, reduces development time, and increases the
reusability of components. But it can be complex to manage. Therefore, the RAD model is great for systems
that need to be produced in a short time and have known requirements.

Spiral Model:

The spiral model is a risk driven iterative software process model. The spiral model delivers projects in
loops. Unlike other process models, its steps aren’t activities but phases for addressing whatever
problem has the greatest risk of causing a failure.

It was designed to include the best features from the waterfall and introduces risk-assessment.
You have the following phases for each cycle:

Address the highest-risk problem and determine the objective and alternate solutions

Evaluate the alternatives and identify the risks involved and possible solutions

Develop a solution and verify if it’s acceptable

Plan for the next cycle

You develop the concept in the first few cycles, and then it evolves into an implementation. Though this
model is great for managing uncertainty, it can be difficult to have stable documentation. The spiral model
can be used for projects with unclear needs or projects still in research and development.

Agile model:

The agile process model encourages continuous iterations of development and testing. Each
incremental part is developed over an iteration, and each iteration is designed to be small and manageable
so it can be completed within a few weeks.

Each iteration focuses on implementing a small set of features completely. It involves customers in the
development process and minimizes documentation by using informal communication.

Agile development considers the following:

Requirements are assumed to change

The system evolves over a series of short iterations

Customers are involved during each iteration

Documentation is done only when needed

Though agile provides a very realistic approach to software development, it isn’t great for complex
projects. It can also present challenges during transfers as there is very little documentation. Agile is great
for projects with changing requirements.
Some commonly used agile methodologies include:

Scrum: One of the most popular agile models, Scrum consists of iterations called sprints. Each sprint is
between 2 to 4 weeks long and is preceded by planning. You cannot make changes after the sprint activities
have been defined.

Extreme Programming (XP): With Extreme Programming, an iteration can last between 1 to 2 weeks.
XP uses pair programming, continuous integration, test-driven development and test automation, small
releases, and simple software design.

Kanban: Kanban focuses on visualizations, and if any iterations are used they are kept very short. You use
the Kanban Board that has a clear representation of all project activities and their numbers, responsible
people, and progress.

Requirements engineering process:

The requirement’s engineering process is an iterative process that involves several steps, including:

➢ Requirements Elicitation
This is the process of gathering information about the needs and expectations of stakeholders for the
software system. This step involves interviews, surveys, focus groups, and other techniques to gather
information from stakeholders.

➢ Requirements Analysis
This step involves analyzing the information gathered in the requirements elicitation step to identify the
high-level goals and objectives of the software system. It also involves identifying any constraints or
limitations that may affect the development of the software system.

➢ Requirements Specification
This step involves documenting the requirements identified in the analysis step in a clear, consistent,
and unambiguous manner. This step also involves prioritizing and grouping the requirements into
manageable chunks.

➢ Requirements Validation
This step involves checking that the requirements are complete, consistent, and accurate. It also involves
checking that the requirements are testable and that they meet the needs and expectations of
stakeholders.

➢ Requirements Management
This step involves managing the requirements throughout the software development life cycle, including
tracking and controlling changes, and ensuring that the requirements are still valid and relevant.

Requirement analysis
Requirements analysis is a common and essential concept in software development and
software project management. At the start of every software project, the project team must understand,
finalize and document the features and functionalities required of the end product. These required
features and functionalities are often called functional specifications, and the process of determining
and understanding them is called requirements gathering and analysis.
Requirements must be quantifiable, as detailed as possible and relevant to the end product. In addition,
they should be clearly documented so the development team has clear expectations and understands
required specifications from the beginning.

Requirement validation
Requirements validation is the process of checking that requirements defined for development, define
the system that the customer wants. To check issues related to requirements, we perform requirements
validation. We typically use requirements validation to check errors at the initial phase of development
as the error may increase excessive rework when detected later in the development process. In the
requirements validation process, we perform a different type of test to check the requirements
mentioned in the Software Requirements Specification (SRS), these checks include:

➢ Completeness checks
➢ Consistency checks
➢ Validity checks
➢ Realism checks
➢ Ambiguity checks
➢ Variability

Requirement management
The requirement management process is the process of managing changing requirements during the
requirements engineering process and system development where the new requirements emerge as a
system is being developed and after it has gone into use. During this process, one must keep track of
individual requirements and maintain links between dependent requirements so that one can assess
the impact of requirements changes along with establishing a formal process for making change
proposals and linking these to system requirements

Requirement traceability
Requirements traceability is the ability to trace a requirement forwards and backwards in the
development lifecycle.

Requirements are traced forward through other development artifacts, including test cases, test runs, and
issues. Requirements are traced backward to the source of the requirement, such as a stakeholder or a
regulatory compliance mandate.

The purpose of requirements traceability is to verify that requirements are met. It also accelerates
development. That’s because it’s easier to get visibility over your requirements.

Traceability is also important for analysis. If a requirement changes, then you can use traceability to
determine the impact of change. You’ll see what the requirement is connected to. And you’ll be able to
see how changing that requirement will impact related issues or tests.

Many organizations do this by creating a traceability matrix. This establishes an audit trail, which is critical
in regulated industries.