Functional and Non Functional Requirements

• A functional requirement defines a system or its component, whereas a

non-functional requirement defines the performance attribute of a
software system.
• Functional requirements, along with requirement analysis help identify
missing requirements, while the advantage of Non-functional
requirements is that it helps you to ensure a good user experience and
ease of operating the software.
• Functional Requirement is a verb, while Non-Functional Requirement is
an attribute
• Types of Non-functional requirements are Scalability Capacity,
Availability, Reliability, Recoverability, Data Integrity, etc., whereas
transaction corrections, adjustments, and cancellations, Business Rules,
Certification Requirements, Reporting Requirements, Administrative
functions, Authorization levels, Audit Tracking, External Interfaces,
Historical Data management, Legal or Regulatory Requirements are
various types of functional requirements.
 What is a Functional Requirement?
• In software engineering, a functional requirement defines a system or its
component. It describes the functions a software must perform. A function is
nothing but inputs, its behavior, and outputs. 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 help you to capture the
intended behavior of the system. This behavior may be expressed as
functions, services or tasks or which system is required to perform.
Example of Functional Requirements
• Here, are some examples of functional requirement in software engineering:
• The software automatically validates customers against the ABC Contact
Management System
• The Sales system should allow users to record customers sales
• The background color for all windows in the application will be blue and have
a hexadecimal RGB color value of 0x0000FF.
• Only Managerial level employees have the right to view revenue data.
• The software system should be integrated with banking API
• The software system should pass Section 508 accessibility requirement.
 Advantages of Functional Requirement
• Here, are the pros/advantages of creating a typical functional
requirement document-
• Helps you to check whether the application is providing all the
functionalities that were mentioned in the functional requirement of
that application
• A functional requirement document helps you to define the
functionality of a system or one of its subsystems.
• Functional requirements along with requirement analysis help
identify missing requirements. They help clearly define the expected
system service and behavior.
• Errors caught in the Functional requirement gathering stage are the
cheapest to fix.
• Support user goals, tasks, or activities for easy project management
• Functional requirement can be expressed in Use Case form or user
story as they exhibit externally visible functional behavior.
 What is Non-Functional Requirement?
• A non-functional requirement defines the quality attribute
of a software system. They represent a set of standards used
to judge the specific operation of a system. Example, how
fast does the website load?
• A non-functional requirement is essential to ensure the
usability and effectiveness of the entire software system.
Failing to meet non-functional requirements can result in
systems that fail to satisfy user needs.
• Non-functional Requirements allows you to impose
constraints or restrictions on the design of the system across
the various agile backlogs. Example, the site should load in 3
seconds when the number of simultaneous users are >
10000. Description of non-functional requirements is just as
critical as a functional requirement.
 Examples of Non-functional requirements
• Here, are some examples of non-functional requirement in software engineering:
• Users must change the initially assigned login password immediately after the first successful
login. Moreover, the initial should never be reused.
• Employees never allowed to update their salary information. Such attempt should be
reported to the security administrator.
• Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit
trail.
• A website should be capable enough to handle 20 million users with affecting its
performance
• The software should be portable. So moving from one OS to other OS does not create any
problem.
• Privacy of information, the export of restricted technologies, intellectual property rights, etc.
should be audited.

Advantages of Non-Functional Requirement

• Benefits/pros of Non-functional testing in software engineering are:
• The nonfunctional requirements ensure the software system follow legal and compliance
rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.
 Software Engineering |
Requirements Engineering Process
• Requirements engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software system.
The requirements 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.
• The Requirements Engineering process is a critical step in the software development life
cycle as it helps to ensure that the software system being developed meets the needs and
expectations of stakeholders, and that it is developed on time, within budget, and to the
required quality.
• Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining service
provided by the system. it is the disciplined application of proven principle ,
methods ,tools and notations to describe a proposed system’s intended behavior
and its associated constraints.
Tools involved in requirement engineering:
• observation report
• Questionnaire ( survey , poll )
• Use cases
• User stories
• Requirement workshop
• Mind mapping
• Role playing
• Prototyping

Requirements Engineering Process consists of the following main activities:

• Requirements elicitation
• Requirements specification
• Requirements verification and validation
• Requirements management
 Requirements Elicitation:
• It is related to the various ways used to gain knowledge about the
project domain and requirements. The various sources of domain
knowledge include customers, business manuals, the existing
software of same type, standards and other stakeholders of the
project. The techniques used for requirements elicitation include
interviews, brainstorming, task analysis, Delphi technique,
prototyping, etc. Some of these are discussed here. Elicitation
does not produce formal models of the requirements understood.
Instead, it widens the domain knowledge of the analyst and thus
helps in providing input to the next stage.
• Requirements elicitation is the process of gathering information
about the needs and expectations of stakeholders for a software
system. This is the first step in the requirements engineering
process and it is critical to the success of the software
development project. The goal of this step is to understand the
problem that the software system is intended to solve, and the
needs and expectations of the stakeholders who will use the
system.
• There are several techniques that can be used to elicit requirements,
including:
• Interviews: These are one-on-one conversations with stakeholders to
gather information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders
to gather information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are brought
together to discuss their needs and expectations for the software
system.
• Observation: This technique involves observing the stakeholders in their
work environment to gather information about their needs and
expectations.
• Prototyping: This technique involves creating a working model of the
software system, which can be used to gather feedback from
stakeholders and to validate requirements.
• It’s important to document, organize and prioritize the requirements
obtained from all these techniques to ensure that they are complete,
consistent and accurate.
• Requirements specification:
• This activity is used to produce formal software requirement
models. All the requirements including the functional as well as the
non-functional requirements and the constraints are specified by
these models in totality. During specification, more knowledge
about the problem may be required which can again trigger the
elicitation process. The models used at this stage include ER
diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.
• Requirements specification is the process of 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.
• The goal of this step is to create a clear and comprehensive
document that describes the requirements for the software
system. This document should be understandable by both the
development team and the stakeholders.
 There are several types of requirements that are commonly specified in this
step, including:
• Functional Requirements: These describe what the software system should do.
They specify the functionality that the system must provide, such as input
validation, data storage, and user interface.
• Non-Functional Requirements: These describe how well the software system
should do it. They specify the quality attributes of the system, such as
performance, reliability, usability, and security.
• Constraints: These describe any limitations or restrictions that must be
considered when developing the software system.
• Acceptance Criteria: These describe the conditions that must be met for the
software system to be considered complete and ready for release.
• In order to make the requirements specification clear, the requirements should be
written in a natural language and use simple terms, avoiding technical jargon, and
using a consistent format throughout the document. It is also important to use
diagrams, models, and other visual aids to help communicate the requirements
effectively.
• Once the requirements are specified, they must be reviewed and validated by the
stakeholders and development team to ensure that they are complete, consistent,
and accurate.
• Requirements verification and validation:
• Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.
• Validation: It refers to a different set of tasks that ensures that the software
that has been built is traceable to customer requirements. If requirements are
not validated, errors in the requirement definitions would propagate to the
successive stages resulting in a lot of modification and rework. The main steps
for this process include:
• The requirements should be consistent with all the other requirements i.e no
two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
• Reviews, buddy checks, making test cases, etc. are some of the methods used
for this.
• Requirements verification and validation (V&V) is the process of checking that
the requirements for a software system are complete, consistent, and
accurate, and that they meet the needs and expectations of the stakeholders.
The goal of V&V is to ensure that the software system being developed meets
the requirements and that it is developed on time, within budget, and to the
required quality.
• Verification is the process of checking that the requirements are
complete, consistent, and accurate. It involves reviewing the
requirements to ensure that they are clear, testable, and free of errors
and inconsistencies. This can include reviewing the requirements
document, models, and diagrams, and holding meetings and
walkthroughs with stakeholders.
• Validation is the process of checking that the requirements meet the
needs and expectations of the stakeholders. It involves testing the
requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders. This can include
testing the software system through simulation, testing with prototypes,
and testing with the final version of the software.
• V&V is an iterative process that occurs throughout the software
development life cycle. It is important to involve stakeholders and the
development team in the V&V process to ensure that the requirements
are thoroughly reviewed and tested.
• It’s important to note that V&V is not a one-time process, but it should be
integrated and continue throughout the software development process
and even in the maintenance stage.
 Requirements management:
• Requirement management is the process of analyzing, documenting,
tracking, prioritizing and agreeing on the requirement and controlling
the communication to relevant stakeholders. This stage takes care of
the changing nature of requirements. It should be ensured that the
SRS is as modifiable as possible so as to incorporate changes in
requirements specified by the end users at later stages too. Being
able to modify the software as per requirements in a systematic and
controlled manner is an extremely important part of the
requirements engineering process.
• Requirements management is the process of managing the
requirements throughout the software development life cycle,
including tracking and controlling changes, and ensuring that the
requirements are still valid and relevant. The goal of requirements
management is to ensure that the software system being developed
meets the needs and expectations of the stakeholders and that it is
developed on time, within budget, and to the required quality.
• There are several key activities that are involved in requirements management,
including:
• Tracking and controlling changes: This involves monitoring and controlling
changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.
• Version control: This involves keeping track of different versions of the
requirements document and other related artifacts.
• Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
• Communication: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed in a
timely manner.
• Monitoring and reporting: This involves monitoring the progress of the
development process and reporting on the status of the requirements.
• Requirements management is a critical step in the software development life cycle
as it helps to ensure that the software system being developed meets the needs
and expectations of stakeholders, and that it is developed on time, within budget,
and to the required quality. It also helps to prevent scope creep and to ensure that
the requirements are aligned with the project goals.
 The advantages of disadvantages of the requirements engineering process in
software engineering include:
Advantages:
• Helps ensure that the software being developed meets the needs and expectations
of the stakeholders
• Can help identify potential issues or problems early in the development process,
allowing for adjustments to be made before significant
• Helps ensure that the software is developed in a cost-effective and efficient
manner
• Can improve communication and collaboration between the development team
and stakeholders
• Helps to ensure that the software system meets the needs of all stakeholders.
• Provides a clear and unambiguous description of the requirements, which helps to
reduce misunderstandings and errors.
• Helps to identify potential conflicts and contradictions in the requirements, which
can be resolved before the software development process begins.
• Helps to ensure that the software system is delivered on time, within budget, and
to the required quality standards.
• Provides a solid foundation for the development process, which helps to reduce
the risk of failure.
 Disadvantages:
• Can be time-consuming and costly, particularly if the requirements gathering
process is not well-managed
• Can be difficult to ensure that all stakeholders’ needs and expectations are taken
into account
• Can be challenging to ensure that the requirements are clear, consistent, and
complete
• Changes in requirements can lead to delays and increased costs in the
development process.
• As a best practice, Requirements engineering should be flexible, adaptable, and
should be aligned with the overall project goals.
• It can be time-consuming and expensive, especially if the requirements are
complex.
• It can be difficult to elicit requirements from stakeholders who have different
needs and priorities.
• Requirements may change over time, which can result in delays and additional
costs.
• There may be conflicts between stakeholders, which can be difficult to resolve.
• It may be challenging to ensure that all stakeholders understand and agree on the
requirements.
 Requirements engineering is a critical process in software engineering that involves
identifying, analyzing, documenting, and managing the requirements of a software
system. The requirements engineering process consists of the following stages:
• Elicitation: In this stage, the requirements are gathered from various stakeholders such
as customers, users, and domain experts. The aim is to identify the features and
functionalities that the software system should provide.
• Analysis: In this stage, the requirements are analyzed to determine their feasibility,
consistency, and completeness. The aim is to identify any conflicts or contradictions in
the requirements and resolve them.
• Specification: In this stage, the requirements are documented in a clear, concise, and
unambiguous manner. The aim is to provide a detailed description of the requirements
that can be understood by all stakeholders.
• Validation: In this stage, the requirements are reviewed and validated to ensure that
they meet the needs of all stakeholders. The aim is to ensure that the requirements are
accurate, complete, and consistent.
• Management: In this stage, the requirements are managed throughout the software
development lifecycle. The aim is to ensure that any changes or updates to the
requirements are properly documented and communicated to all stakeholders.
• Effective requirements engineering is crucial to the success of software development
projects. It helps ensure that the software system meets the needs of all stakeholders
and is delivered on time, within budget, and to the required quality standards.
 Agile Testing Methods:
• Scrum
• Crystal
• Dynamic Software Development
Method(DSDM)
• Feature Driven Development(FDD)
• Lean Software Development
• eXtreme Programming(XP)
 Plan-driven and agile development
• Plan-driven development
• – A plan-driven approach to software engineering is
based around separate development stages with the
outputs to be produced at each of these stages planned in
advance.
• – Not necessarily waterfall model – plan-driven,
incremental development is possible
• – Iteration occurs within activities.
• Agile development
• – Specification, design, implementation and testing are
inter-leaved and the outputs from the development
process are decided through a process of negotiation
during the software development process.
Most projects include elements of plan-driven and agile processes.
Deciding on the balance depends on:
– Is it important to have a very detailed specification and design before
moving to implementation? If so, you probably need to use a plan-
driven approach.
– Is an incremental delivery strategy, where you deliver the software to
customers and get rapid feedback from them, realistic? If so, consider
using agile methods.
• – How large is the system that is being developed? Agile methods are most
effective when the system can be developed with a small co-located team
who can communicate informally. This may not be possible for large systems
that require larger development teams so a plan-driven approach may have
to be used.
• – What type of system is being developed?
• • Plan-driven approaches may be required for systems that require a lot of
analysis before implementation (e.g. real-time system with complex timing
requirements).
• – What is the expected system lifetime?
• • Long-lifetime systems may require more design documentation to
communicate the original intentions of the system developers to the support
team.
• – What technologies are available to support system development?
• • Agile methods rely on good tools to keep track of an evolving design
• – How is the development team organized?
• • If the development team is distributed or if part of the development is
being outsourced, then you may need to develop design documents to
communicate across the development teams.
• – Are there cultural or organizational issues that may affect
the system development?
• • Traditional engineering organizations have a culture of
plan-based development, as this is the norm in engineering.
• – How good are the designers and programmers in the
development team?
• • It is sometimes argued that agile methods require
higher skill levels than plan-based approaches in which
programmers simply translate a detailed design into code
• – Is the system subject to external regulation?
• • If a system has to be approved by an external regulator
(e.g. the FAA approve software that is critical to the
operation of an aircraft) then you will probably be required
to produce detailed documentation as part of the system
safety case.
 Extreme programming
• • Perhaps the best-known and most widely used agile method.
• • Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
• – New versions may be built several times per day;
• – Increments are delivered to customers every 2 weeks;
• – All tests must be run for every build and the build is only accepted if tests run
successfully.
•
•
• XP and agile principles
• • Incremental development is supported through small, frequent system
releases.
• • Customer involvement means full-time customer engagement with the team.
• • People not process through pair programming, collective ownership and a
process that avoids long working hours.
• • Change supported through regular system releases.
• • Maintaining simplicity through constant refactoring of code.
The XP release cycle:
 Agile Project Management
• Agile project management is an interactive approach to manage
software development. The agile project management focuses on
continuous releases and covers customer feedback with every iteration.
• Traditionally the agile project management is classified into two
frameworks: scrum and kanban. The scrum framework focused fixed-
length project iterations, whereas kanban framework focused on
continuous releases. After competition of project first iteration (or
steps) project management activity immediately moves on to the next.
History of Agile Project Management
• Agile project management is rapidly rising in the 21st century. It is used
for software development projects and other IT initiatives.
• However, from the mid-20th century, the concept of continuous
development has taken various forms. For example, there was James
Martin's Rapid Iterative Production Prototyping (RIPP), an approach
that served as the premise for the 1991 book Rapid Application
Development (RAD).
• The agile project management framework which has emerged in most recent years is
known as Scrum. This methodology features works on the development team to
create a product backlog. It also creates a prioritized list of the features,
functionalities, and fixes required to deliver a successful software system. The scrum
team offers the pieces of a task in rapid increments.
How Agile Project Management works
• The agile project management calls for teams to regularly evaluate cost and time as
they move through their work. They use velocity, burnup and burndown charts to
measure their work, rather than Gantt charts and project milestones to track
progress.
• The agile team practices to continuous development and continuous integration using
technology that automates steps to speed up the release and use of products.
• The presence and participation of the project manager are not required in agile
project management. Although the presence of the project manager is essential for
success under the traditional (waterfall model) project delivery. The role of the
project manager is to distribute task among team members. However, the project
manager is not obsolete in agile project management, and many organizations use
them in a large, more complex project. The organization mostly places them in the
project coordinator role.
• Agile Project Management demands that team members know how to work in this
new agile methodology. The team member must be able to coordinate with each
other, as well as with users.