Se Unit-Ii
Se Unit-Ii
UNIT-II
REQUIREMENTS ENGINEERING
Functional vs Non-Functional Requirements
In this article, we will discuss two important terms used in software engineering that are
functional requirements and non-functional requirements, along with the comparison between
them. Understanding the difference between both terms helps to ensure that the delivered product
meets the expectations of the client.
Functional Requirements
Functional requirements define a function that a system or system element must be qualified
to perform and must be documented in different forms. The functional requirements describe the
behavior of the system as it correlates to the system's functionality.
Non-functional requirements
Non-functional requirements are not related to the software's functional aspect. They can be
the necessities that specify the criteria that can be used to decide the operation instead of specific
behaviors of the system. Basic non-functional requirements are - usability, reliability, security,
storage, cost, flexibility, configuration, performance, legal or regulatory requirements, etc.
1) Execution qualities like security and usability, which are observable at run time.
2) Evolution qualities like testability, maintainability, extensibility, and scalability that
embodied in the static structure of the software system.
Non-functional requirements specify the software's quality attribute. These requirements define the
general characteristics, behavior of the system, and features that affect the experience of the user.
They ensure a better user experience, minimizes the cost factor.
Non-functional requirements ensure that the software system must follow the legal and adherence
rules. The impact of the non-functional requirements is not on the functionality of the system, but
they impact how it will perform. For a well-performing product, at least some of the non-functional
requirements should be met.
Functional requirements help to understand the They help to understand the system's
functions of the system. performance.
They describe what the product does. They describe the working of product.
These requirements are specified by the user. These requirements are specified by the
software developers, architects, and
technical persons.
There is functional testing such as API testing, There is non-functional testing such as
system, integration, etc. usability, performance, stress, security, etc.
These requirements are important to system These are not always the important
operation. requirements; they may be desirable.
Completion of Functional requirements allows the While system will not work only with non-
system to perform, irrespective of meeting the functional requirements.
non-functional requirements.
➢ Sometimes, the user and system requirements are integrated into a single description.
➢ In other cases, the user requirements are defined in an introduction to the system
requirements specification. If there are a large number of requirements, the detailed system
requirements may be presented in a separate document.
➢ Requirements documents are essential when an outside contractor is developing the software
system. However, agile development methods argue that requirements change so rapidly
From the desk of Prof Vinutha H M, SMDC College 3
SOFTWARE ENGINEERING
that a requirements document is out of date as soon as it is written, so the effort is largely
wasted.
➢ Rather than a formal document, approaches such as Extreme Programming (Beck, 1999)
collect user requirements incrementally and write these on cards as user stories. The user
then prioritizes requirements for implementation in the next increment of the system.
➢ The requirements document has a diverse set of users, ranging from the senior management
of the organization that is paying for the system to the engineers responsible for developing
the software.
Requirements specification is the process of writing down the user and system requirements
in a requirements document. Ideally, the user and system requirements should be clear,
unambiguous, easy to understand, complete, and consistent. In practice, this is difficult to achieve
as stakeholders interpret the requirements in different ways and there are often inherent conflicts
and inconsistencies in the requirements.
The requirements document should not include details of the system architecture or design.
Consequently, if you are writing user requirements, you should not use software jargon, structured
notations, or formal notations. You should write user requirements in natural language, with simple
tables, forms, and intuitive diagrams.
Ideally, the system requirements should simply describe the external behavior of the system and its
operational constraints. They should not be concerned with how the system should be designed or
implemented. However, at the level of detail required to completely specify a complex software
system, it is practically impossible to exclude all design information. There are several reasons for
this:
1) You may have to design an initial architecture of the system to help structure the
requirements specification. The system requirements are organized according to the different
sub-systems that make up the system. As I discuss in Chapters 6 and 18, this architectural
definition is essential if you want to reuse software components when implementing the
system.
2) In most cases, systems must interoperate with existing systems, which constrain the design
and impose requirements on the new system.
3) The use of a specific architecture to satisfy non-functional requirements (such as N-version
programming to achieve reliability, discussed in Chapter 13) may be necessary. An external
regulator who needs to certify that the system is safe may specify that an already certified
architectural design be used.
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.
1)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 Elicitation does not produce formal models of the requirements
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:
It’s important to document, organize and prioritize the requirements obtained from all these
techniques to ensure that they are complete, consistent and accurate.
2)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.
There are several types of requirements that are commonly specified in this step, including
1) 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.
2) 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.
3) Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
4) 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.
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.
1) The requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
2) The requirements should be complete in every sense.
3) 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.
1) 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.
2) 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.
3) 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.
4)Requirements Management
There are several key activities that are involved in requirements management, including:
1) 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.
2) Version control: This involves keeping track of different versions of the requirements
document and other related artifacts.
3) Traceability: This involves linking the requirements to other elements of the development
process, such as design, testing, and validation.
4) 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.
5) 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.
Definition:
There are a number of requirements elicitation methods. Few of them are listed below –
1) Interviews
2) Brainstorming Sessions
3) Facilitated Application Specification Technique (FAST)
4) Quality Function Deployment (QFD)
5) Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.
1)Interviews
1) In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
2) In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
➢ It 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 group 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.
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-
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, 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.
➢ Normal requirements – In this the objective and goals of the proposed software are
discussed with the customer. 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. Example – when unauthorized access is detected,
it should backup and shutdown all processes.
This 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, use case diagram.
1)Actor
It is the external agent that lies outside the system but interacts with it in some way. An actor
maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or
secondary actors.
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.
A use case diagram graphically represents what happens when an actor interacts with a
system. It captures the functional aspect of the system.
Requirement’s validation
Requirements validation is the process of checking that requirements actually define the
system that the customer really wants. It overlaps with analysis as it is concerned with finding
problems with the requirements.
During the requirements validation process, different types of checks should be carried out on the
requirements in the requirements document. These checks include:
1) Validity checks A user may think that a system is needed to perform certain functions.
However, further thought and analysis may identify additional or different functions that
are required. Systems have diverse stakeholders with different needs and any set of
requirements is inevitably a compromise across the stakeholder community.
2) Consistency checks Requirements in the document should not conflict. That is, there should
not be contradictory constraints or different descriptions of the same system function.
3) Completeness checks The requirements document should include requirements that define
all functions and the constraints intended by the system user.
4) Realism checks Using knowledge of existing technology, the requirements should be checked
to ensure that they can actually be implemented. These checks should also take account of
the budget and schedule for the system development.
5) Verifiability To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you
should be able to write a set of tests that can demonstrate that the delivered system meets
each specified requirement.
Requirements management
The requirements for large software systems are always changing. One reason for this is that
these systems are usually developed to address ‘wicked’ problems—problems that cannot be
completely defined. Because the problem cannot be fully defined, the software requirements are
bound to be incomplete. During the software process, the stakeholders’ understanding of the
problem is constantly changing. The system requirements must then also evolve to reflect this
changed problem view.
1) The business and technical environment of the system always changes after installation. New
hardware may be introduced, it may be necessary to interface the system with other systems,
business priorities may change (with consequent changes in the system support required),
and new legislation and regulations may be introduced that the system must necessarily
abide by.
2) The people who pay for a system and the users of that system are rarely the same people.
System customers impose requirements because of organizational and budgetary
constraints. These may conflict with end-user requirements and, after delivery, new features
may have to be added for user support if the system is to meet its goals.
3) Large systems usually have a diverse user community, with many users having different
requirements and priorities that may be conflicting or contradictory. The final system
Requirements management needs automated support and the software tools for this should be
chosen during the planning phase. You need tool support for: