0% found this document useful (0 votes)
26 views17 pages

Se Unit-Ii

Uploaded by

sowmyakella02
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views17 pages

Se Unit-Ii

Uploaded by

sowmyakella02
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

SOFTWARE ENGINEERING

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.

So, without more delay, let's start the topic.

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.

➢ Functional requirements should be written in a simple language, so that it is easily


understandable.
➢ The examples of functional requirements are authentication, business rules, audit tracking,
certification requirements, transaction corrections, etc.
➢ These requirements allow us to verify whether the application provides all functionalities
mentioned in the application's functional requirements. They support tasks, activities, user
goals for easier project management.

From the desk of Prof Vinutha H M, SMDC College 1


SOFTWARE ENGINEERING
➢ There are a number of ways to prepare functional requirements. The most common way is
that they are documented in the text form. Other formats of preparing the functional
requirements are use cases, models, prototypes, user stories, and diagrams.

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.

They are divided into two main categories:

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 v/s Non-functional requirements

Functional Requirements Non-functional requirements

Functional requirements help to understand the They help to understand the system's
functions of the system. performance.

Functional requirements are mandatory. While non-functional requirements are not


mandatory.

They are easy to define. They are hard to define.

They describe what the product does. They describe the working of product.

From the desk of Prof Vinutha H M, SMDC College 2


SOFTWARE ENGINEERING
It concentrates on the user's requirement. It concentrates on the expectation and
experience of the user.

It helps us to verify the software's functionality. It helps us to verify the software's


performance.

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.

Examples of the functional requirements are - Examples of the non-functional


Authentication of a user on trying to log in to the requirements are -The background color of
system. the screens should be light blue.

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.

Software requirements document

The software requirements document (sometimes called the software requirements


specification or SRS) is an official statement of what the system developers should implement. It
should include both the user requirements for a system and a detailed specification of the system
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.

From the desk of Prof Vinutha H M, SMDC College 4


SOFTWARE ENGINEERING
Requirements specification

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.

From the desk of Prof Vinutha H M, SMDC College 5


SOFTWARE ENGINEERING

Requirements engineering processes

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.
➢ Requirements engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software system.

Steps of requirement engineering process are follows:

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

From the desk of Prof Vinutha H M, SMDC College 6


SOFTWARE ENGINEERING
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.

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.

From the desk of Prof Vinutha H M, SMDC College 7


SOFTWARE ENGINEERING
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

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.

3)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.

From the desk of Prof Vinutha H M, SMDC College 8


SOFTWARE ENGINEERING
The main steps for this process include:

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

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

From the desk of Prof Vinutha H M, SMDC College 9


SOFTWARE ENGINEERING
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:

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.

Requirements Elicitation and Analysis

Definition:

In requirements engineering, requirements elicitation is the practice of researching and


discovering the requirements of a system from users, customers, and other stakeholders. The
practice is also sometimes referred to as "requirement gathering".

From the desk of Prof Vinutha H M, SMDC College 10


SOFTWARE ENGINEERING
Requirements elicitation is perhaps the most difficult, most error-prone, and most communication-
intensive software development. It can be successful only through an effective customer-developer
partnership. It is needed to know what the users really need. Requirements elicitation includes the
subsequent activities. Few of them are listed below –

➢ Knowledge of the overall area where the systems is applied.


➢ The details of the precise customer problem where the system is going to be applied must be
understood.
➢ Interaction of system with external requirements.
➢ Detailed investigation of user needs.
➢ Define the constraints for system development.

Requirements elicitation Methods:

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

Objective of conducting an interview is to understand the customer’s expectations from the


software.
It is impossible to interview every stakeholder hence representatives from groups are selected based
on their expertise and credibility.

Interviews maybe 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 structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

From the desk of Prof Vinutha H M, SMDC College 11


SOFTWARE ENGINEERING
2)Brainstorming Sessions

➢ 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.

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, 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 on the


requirements which 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. 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.

From the desk of Prof Vinutha H M, SMDC College 12


SOFTWARE ENGINEERING
The major steps involved in this procedure are –

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


2) List out all requirements from customer.
3) A value indicating degree of importance is assigned to each requirement.
4) 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

5)Use Case Approach

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.

➢ 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.

From the desk of Prof Vinutha H M, SMDC College 13


SOFTWARE ENGINEERING
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 in a clear and concise manner 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 that 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.

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.

➢ Requirements validation is important because errors in a requirements document can lead to


extensive rework costs when these problems are discovered during development or after the
system is in service.
➢ The cost of fixing a requirements problem by making a system change is usually much
greater than repairing design or coding errors.

From the desk of Prof Vinutha H M, SMDC College 14


SOFTWARE ENGINEERING
➢ The reason for this is that a change to the requirements usually means that the system design
and implementation must also be changed. Furthermore, the system must then be re-tested.

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.

From the desk of Prof Vinutha H M, SMDC College 15


SOFTWARE ENGINEERING
There are a number of requirements validation techniques that can be used individually or in
conjunction with one another:

1) Requirements reviews the requirements are analyzed systematically by a team of reviewers


who check for errors and inconsistencies.
2) Prototyping In this approach to validation, an executable model of the system in question is
demonstrated to end-users and customers. They can experiment with this model to see if it
meets their real needs.
3) Test-case generation Requirements should be testable. If the tests for the requirements are
devised as part of the validation process, this often reveals requirements problems. If a test
is difficult or impossible to design, this usually means that the requirements will be difficult
to implement and should be reconsidered. Developing tests from the user requirements
before any code is written is an integral part of extreme programming.

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.

There are several reasons why change is inevitable:

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

From the desk of Prof Vinutha H M, SMDC College 16


SOFTWARE ENGINEERING
requirements are inevitably a compromise between them and, with experience, it is often
discovered that the balance of support given to different users has to be changed.

1) Requirements identification Each requirement must be uniquely identified so that it can be


cross-referenced with other requirements and used in traceability assessments.
2) A change management process This is the set of activities that assess the impact and cost of
changes. I discuss this process in more detail in the following section.
3) Traceability policies These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability
policy should also define how these records should be maintained.
4) Tool support Requirements management involves the processing of large amounts of
information about the requirements. Tools that may be used range from specialist
requirements management systems to spreadsheets and simple database systems.

Requirements management needs automated support and the software tools for this should be
chosen during the planning phase. You need tool support for:

1) Requirements storage: the requirements should be maintained in a secure, managed data


store that is accessible to everyone involved in the requirements engineering process.
2) Change management: the process of change management is simplified if active tool support
is available.
3) Traceability management as discussed above, tool support for traceability allows related
requirements to be discovered. Some tools are available which use natural language
processing techniques to help discover possible relationships between requirements.

From the desk of Prof Vinutha H M, SMDC College 17

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy