Software Engineering

MODULE 3
Understanding Requirements
➢Understanding the requirements of a problem is among the most difficult tasks that
you’ll face as a software engineer.
➢When you first think about it, developing a clear understanding of requirements
doesn’t seem that hard.
➢ Ralph Young’s book - “It’s your worst nightmare. A customer walks into your office,
sits down, looks you straight in the eye, and says, “I know you think you understand
what I said, but what you don’t understand is what I said is not what I meant.”
➢Invariably, this happens late in the project, after deadline commitments have been
made, reputations are on the line, and serious money is at stake.
Understanding Requirements
➢The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering.
➢From a software process perspective, requirements engineering is a major software
engineering action that begins during the communication activity and continues into
the modeling activity.
➢It must be adapted to the needs of the process, the project, the product, and the
people doing the work.

➢Requirements engineering builds a bridge to design and construction.

Software requirements and its types
There are three types of software requirements as follows:
1. Functional requirements
2. Non Functional requirements
3. Domain requirements
Functional Requirements
➢Functional requirements are such software requirements that are demanded
explicitly as basic facilities of the system by the end users.
➢So, these requirements for functionalities should be necessarily incorporated into
the system as a part of the contract.
➢They describe system behavior under specific conditions .
➢In other words, they are the functions that one can see directly in the final product,
and it was the requirements of the users as well.
➢ It describes a software system or its components.
➢These are represented as inputs to the software system, its behavior, and its output.
➢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 software requirements help us to capture the intended behavior of the
system.
➢Functional requirements can be incorporated into the system in many ways as
➢1. Natural language
➢2. A structured or formatted language with no rigorous syntax and formal
specification language with proper syntax.
➢Examples of functional requirements
1. Whenever a user logs into the system, their authentication is done.
2. In case of a cyber attack, the whole system is shut down.
3. Whenever a user registers on some software system for the first time, a verification
e-mail/sms is sent to the user.
Non-functional Requirements(NFRs)
➢These requirements are defined as the quality constraints that the system
must satisfy to complete the project contract.
➢Non-functional requirements are more abstract. They deal with issues like-
» Performance
» Reusability
» Flexibility
» Reliability
» Maintainability
» Security
» Portability
Types of NFRs
Non-Functional Requirements are classified into many types. Some of them are as
follows:
• Interface Constraints
• Economic Constraints
• Operating Constraints
• Performance constraints: storage space, response time, security, etc.
• Life Cycle constraints: portability, maintainability, etc.
Domain Requirements
➢Domain requirements are the requirements related to a particular category like
software, purpose or industry, or other domain of projects.
➢Domain requirements can be functional or non functional.
➢These are essential functions that a system of specific domains must necessarily
exhibit.
➢The common factor for domain requirements is that they meet established
standards or widely accepted feature sets for that category of the software project.
➢Domain requirements typically arise in military, medical, and financial industry
sectors. They are identified from that specific domain and are not user specific.
Difference between Functional Requirements
and Non-Functional Requirements
Requirements Engineering process
Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering design
process. Requirement engineering provides the appropriate mechanism to
understand what the customer desires, analyzing the need, and assessing
feasibility, negotiating a reasonable solution, specifying the solution clearly,
validating the specifications and managing the requirements as they are
transformed into a working system.
Requirement Engineering Process is a five-step process, which includes -
1.Feasibility Study
2.Requirement Elicitation and Analysis
3.Software Requirement Specification
4.Software Requirement Validation
5.Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change
and conformable to established standards.
Types of Feasibility:
1.Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer
requirements within the time and budget.
2.Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve
business problems and customer requirements.
3.Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.
2.Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements
are identified with the help of customers and existing systems processes, if
available.
Analysis of requirements starts with requirement elicitation. The
requirements are analyzed to identify inconsistencies, defects, omission,
etc. We describe requirements in terms of relationships and also resolve
conflicts if any.
Problems of Elicitation and Analysis
Getting all, and only, the right people involved.
Stakeholders often don't know what they want
Stakeholders express requirements in their terms.
Stakeholders may have conflicting requirements.
Requirement change during the analysis process.
Organizational and political factors may influence system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software analyst
after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements.
DFD shows the flow of data through a system. The system may be a company, an organization, a
set of procedures, a computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data
items defined in DFDs. At the requirements stage, the data dictionary should at least define
customer data items, to ensure that the customer and developers use the same definition and
terminologies.
Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the
data for the organization and uses three main constructs i.e. data entities, relationships, and their
associated attributes.
4. Software Requirement Validation:
After requirement specifications developed, the requirements
discussed in this document are validated. The user might demand
illegal, impossible solution or experts may misinterpret the needs.
Requirements can be the check against the following conditions -
If they can practically implement
If they are correct and as per the functionality and specially of
software
If there are any ambiguities
If they are full
If they can describe
Requirements Validation Techniques
Requirements reviews/inspections: systematic manual analysis of
the requirements.
Prototyping: Using an executable model of the system to check
requirements.
Test-case generation: Developing tests for requirements to check
testability.
Automated consistency analysis: checking for the consistency of
structured requirements descriptions.
5. Software Requirement management
A typical requirements management process complements the through
these steps:
Collect initial requirements from stakeholders
Analyze requirements
Define and record requirements
Prioritize requirements
Agree on and approve requirements
Trace requirements to work items
Query stakeholders after implementation on needed changes to requirements
Utilize test management to verify and validate system requirements
Assess impact of changes
Revise requirements
Document changes
Some of the benefits of requirements management include:
Lower cost of development across the lifecycle
Fewer defects
Minimized risk for safety-critical products
Faster delivery
Reusability
Traceability
Requirements being tied to test cases
Global configuration management
Requirements Elicitation
Requirement elicitation can be done by communicating
with stakeholders directly or by doing some research,
experiments. The activities can be planned, unplanned,
or both.
Planned activities include workshops, experiments.
Unplanned activities happen randomly. Prior notice is
not required for such activities. For example, you directly
go to the client site and start discussing the
requirements however there was no specific agenda
published in advance.
Following tasks are the part of elicitation:
Prepare for Elicitation: The purpose here is to
understand the elicitation activity scope, select the right
techniques, and plan for appropriate resources.
Conduct Elicitation: The purpose here is to explore and
identify information related to change.
Confirm Elicitation Results: In this step, the information
gathered in the elicitation session is checked for
accuracy.
Requirements Elicitation Techniques
There are several techniques available for elicitation,
however, the commonly used techniques are explained
below:
1) Stakeholder Analysis
Stakeholders can include team members, customers, any
individual who is impacted by the project or it can be a
supplier. Stakeholder analysis is done to identify the
stakeholders who will be impacted by the system.
2) Brainstorming
This technique is used to generate new ideas and find a
solution for a specific issue. The members included for
brainstorming can be domain experts, subject matter
experts.
Brainstorming technique is used to answer the below
questions:
What is the expectation of a system?
What are the risk factors that affect the proposed
system development and what to do to avoid that?
What are the business and organization rules required to
follow?
What are the options available to resolve the current
issues?
What should we do so that this particular issue does not
happen in the future?
3) Interview
Interview techniques should be used for building strong
relationships between business analysts and stakeholders.

called a structured interview.

If the interviewer is not having any particular format or any
unstructured interview.
4) Document Analysis/Review
This technique is used to gather business information by
reviewing/examining the available materials that describe the
business environment. This analysis is helpful to validate the
implementation of current solutions and is also helpful in
understanding the business need.
Document analysis includes reviewing the business plans,
technical documents, problem reports, existing requirement
documents, etc. This is useful when the plan is to update an
existing system. This technique is useful for migration
projects.
5) Focus Group
The Focus group includes subject matter experts. The
objective of this group is to discuss the topic and provide
information. A moderator manages this session.
The moderator should work with business analysts to analyze
the results and provide findings to the stakeholders.
If a product is under development and the discussion is
required on that product then the result will be to update
the existing requirement or you might get new requirements.
If a product is ready to ship then the discussion will be on
releasing the product.
 6) Interface Analysis
Interface analysis is used to review the system, people,
and processes. This analysis is used to identify how the
information is exchanged between the components. An
Interface can be described as a connection between two
components. This is described in the below image:

The interface analysis focus on the below questions:

1.Who will be using the interface?
2.What kind of data will be exchanged?
3.When will the data be exchanged?
4.How to implement the interface?
5.
the interface?
7) Observation
The main objective of the observation session is to
understand the activity, task, tools used, and events
performed by others.
The plan for observation ensures that all stakeholders are
aware of the purpose of the observation session, they agree
on the expected outcomes, and that the session meets their
expectations
During the session, the observer should record all the
activities and the time taken to perform the work by others
so that he/she can simulate the same. Observation can be
either active or passive.
Active observation is to ask questions and try to attempt the
work that other persons are doing.
Passive observation is silent observation i.e. you sit with
others and just observe how they are doing their work
without interpreting them.
8) Prototyping
Prototyping is used to identify missing or unspecified
requirements. In this technique, frequent demos are given to the
client by creating the prototypes so that client can get an idea of
how the product will look like.
9) Joint Application Development (JAD)/ Requirement Workshops
This technique is more process-oriented and formal as compared
to other techniques. These are structured meetings involving end-
users. This is used to define, clarify, and complete requirements.
This technique can be divided into the following categories:
Formal Workshops: These workshops are highly structured and
are usually conducted with the selected group of stakeholders.
The main focus of this workshop is to define, create, refine, and
reach closure on business requirements.
Business Process Improvement Workshops: These are less formal
as compared to the above one. Here, existing business processes
are analyzed and process improvements are identified.
10) Survey/Questionnaire
For Survey/Questionnaire, a set of questions is given to
stakeholders to quantify their thoughts. After collecting the
responses from stakeholders, data is analyzed to identify the area
of interest of stakeholders.
Questions should be based on high priority risks. Questions should
be direct and unambiguous. Once the survey is ready, notify the
participants and remind them to participate.
Two types of questions can be used here:
Open-Ended: Respondent is given the freedom to provide answers
in their own words rather than selecting from predefined
responses. This is useful but at the same time, this is time-
consuming as interpreting the responses is difficult.
Close Ended: It includes a predefined set of answers for all the
questions and the respondent has to choose from those answers.
Questions can be multiple choice or can be ranked from not
important to very important.
Software Engineering:
Module 3
System Modelling
➢System modeling is the process of developing abstract models of a system, with
each model presenting a different view or perspective of that system.
➢System modeling has generally come to mean representing the system using some
kind of graphical notation, which is now almost always based on notations in the
Unified Modeling Language (UML).
➢However, it is also possible to develop formal (mathematical)models of a system,
usually as a detailed system specification.
➢Models are used during the requirements engineering process to help derive the
requirements for a system, during the design process to describe the system to
engineers implementing the system and after implementation to document the
system’s structure and operation.
➢You may develop models of both the existing system and the system to be
developed:
o Models of the existing system are used during requirements engineering to
help clarify what the existing system does and can be used as a basis for
discussing its strengths and weaknesses. These then lead to requirements
for the new system.
o Models of the new system are used during requirements engineering to
help explain the proposed requirements to other system stakeholders.
Engineers use these models to discuss design proposals and to document
the system for implementation.
o In a model-driven engineering process, it is possible to generate a
complete or partial system implementation from the system model.
➢The most important aspect of a system model is that it leaves out detail.
➢A model is an abstraction of the system being studied rather than an alternative
representation of that system.
➢Ideally, a representation of a system should maintain all the information about the
entity being represented.
➢An abstraction deliberately simplifies and picks out the most salient characteristics.
➢You may develop different models to represent the system from different perspectives.
For example,
1. An external perspective, where you model the context or environment of the system.
2. An interaction perspective where you model the interactions between a system and
its environment or between the components of a system.
3. A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
4. A behavioral perspective, where you model the dynamic behavior of the system and
how it responds to events.
➢Benefits of System Modeling:
1. Ease project management tasks.
2. Can provide complete views of a system, as well as detailed views of subsystems.
3. Clarify structures and relationships.
4. Offer a communication framework for ideas within and between teams. Can
generate new ideas and possibilities.
5. Allow quality assurance and testing scenarios to be generated.
6. Platform independent.
➢The following five diagram types could represent the essentials of a system:

1. Activity diagrams, which show the activities involved in a process or in data

processing.

2. Use case diagrams, which show the interactions between a system and its
environment.

3. Sequence diagrams, which show interactions between actors and the system and
between system components.

4. Class diagrams, which show the object classes in the system and the associations
between these classes.

5. State diagrams, which show how the system reacts to internal and external
events.
Types of Models
1. Context models

2. Interaction models

3. Structural models

4. Behavioural models

5. Model driven engineering

Context Models
➢Context models are used to illustrate the operational context of a system.
➢They show what lies outside the system boundaries.
➢At an early stage in the specification of a system, you should decide on the system
boundaries.
➢This involves working with system stakeholders to decide what functionality should
be included in the system and what is provided by the system’s environment.
➢You may decide that automated support for some business processes should be
implemented but others should be manual processes or supported by different
systems.
➢You should look at possible overlaps in functionality with existing systems and decide
where new functionality should be implemented.
➢These decisions should be made early in the process to limit the system costs and
the time needed for understanding the system requirements and design.
➢In some cases, the boundary between a system and its environment is relatively clear.
For example, where an automated system is replacing an existing manual or
computerized system, the environment of the new system is usually the same as the existing
system’s environment.
➢In other cases, there is more flexibility, and you decide what constitutes the boundary
between the system and its environment during the requirements engineering process.
For example, say you are developing the specification for the patient information
system for mental healthcare – MHC-PMS. This system is intended to manage information
about patients attending mental health clinics and the treatments that have been prescribed.
In developing the specification for this system, you have to decide whether the system should
focus exclusively on collecting information about consultations (using other systems to collect
personal information about patients) or whether it should also collect personal patient
information. The advantage of relying on other systems for patient information is that you
avoid duplicating data. The major disadvantage, however, is that using other systems may
make it slower to access information. If these systems are unavailable, then the MHC-PMS
cannot be used.
➢The position of the system boundary has a profound effect on the system requirements.

➢The definition of a system boundary is not a value-free judgment.

➢Social and organizational concerns may mean that the position of a system boundary
may be determined by non-technical factors. For example, a system boundary may be
deliberately positioned so that the analysis process can all be carried out on one site; or it
may be chosen so that a particularly difficult manager need not be consulted.

➢Once some decisions on the boundaries of the system have been made, part of the
analysis activity is the definition of that context and the dependencies that a system has
on its environment. Normally, producing a simple architectural model is the first step in
this activity.
 Figure 1 is a simple context model that shows the patient
information system MHC-PMS and the other systems in
its environment.
You can see that the MHC-PMS is connected to an
appointments system and a more general patient record
system with which it shares data.
The system is also connected to systems for management
reporting and hospital bed allocation and a statistics
system that collects
information for research.
Figure 1: The context of the patient Finally, it makes use of a prescription system to generate
management system – MHC_PMS
prescriptions for patients’ medication.
➢Context models normally show that the environment includes several other
automated systems.
➢However, they do not show the types of relationships between the systems in the
environment and the system that is being specified.
➢External systems might produce data for or consume data from the system. They
might share data with the system, or they might be connected directly, through a
network or not connected at all. They might be physically co-located or located in
separate buildings.
➢All of these relations may affect the requirements and design of the system being
defined and must be taken into account.
➢Therefore, simple context models are used along with other models, such as
business process models.
➢These describe human and automated processes in which particular software
systems are used.
Figure 2: Process model of involuntary detention (It is a model of an important system
process that shows the processes in which the MHC-PMS is used)
➢Figure 2 is a UML activity diagram.

➢Activity diagrams are intended to show the activities that make up a system process and the flow of
control from one activity to another.

➢The start of a process is indicated by a filled circle; the end by a filled circle inside another circle.

➢Rectangles with round corners represent activities, that is, the specific sub-processes that must be
carried out.

➢The arrows represent the flow of work from one activity to another.

➢ A solid bar is used to indicate activity coordination.

➢ When the flow from more than one activity leads to a solid bar then all of these activities must be
complete before progress is possible.
➢When the flow from a solid bar leads to a number of activities, these may be executed in
parallel.

➢ Therefore, in Figure 2, the activities to inform social care and the patient’s next of kin, and
to update the detention register may be concurrent.

➢ Arrows may be annotated with guards that indicate the condition when that flow is taken.

➢ In Figure 2, you can see guards showing the flows for patients who are dangerous and not
dangerous to society.

➢ Patients who are dangerous to society must be detained in a secure facility.

➢However, patients who are suicidal and so are a danger to themselves may be detained in an
appropriate ward in a hospital.
 Interaction models
➢All systems involve interaction of some kind.

➢This can be user interaction, which involves user inputs and outputs, interaction between the
system being developed and other systems or interaction between the components of the system.

➢Modeling user interaction is important as it helps to identify user requirements.

➢Modeling system to system interaction highlights the communication problems that may arise.

➢Modeling component interaction helps us understand if a proposed system structure is likely to

deliver the required system performance and dependability.
➢Two approaches to interaction modeling:
1. Use case modeling, which is mostly used to model interactions between a
system and external actors (users or other systems).

2. Sequence diagrams, which are used to model interactions between system

components, although external agents may also be included.

➢ Use case models and sequence diagrams present interaction at different levels of
detail and so may be used together.
➢ The details of the interactions involved in a high level use case may be documented in
a sequence diagram.
➢ The UML also includes communication diagrams that can be used to model
interactions which is not discussed here as they are an alternative representation of
sequence charts.
➢ In fact, some tools can generate a communication diagram from a sequence diagram.
Use Case Modelling
➢Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s.

➢It was then incorporated into the first release of the UML (Rumbaugh et al., 1999).

➢A use case can be taken as a simple scenario that describes what a user expects from a system.

➢Each use case represents a discrete task that involves external interaction with a system.

➢In its simplest form, a use case is shown as an ellipse with the actors involved in the use case
represented as stick figures.

➢Figure 3 shows a use case from the MHC-PMS that represents the task of uploading data from the
MHC-PMS to a more general patient record system.

➢This more general system maintains summary data about a patient rather than the data about
each consultation, which is recorded in the MHC-PMS.
 Figure 3: Transfer data use case

➢Notice that there are two actors in this use case: the operator who is transferring the data
and the patient record system.
➢The stick figure notation was originally developed to cover human interaction but it is also
now used to represent other external systems and hardware.
➢Formally, use case diagrams should use lines without arrows as arrows in the UML indicate
the direction of flow of messages.
➢Obviously, in a use case messages pass in both directions.
➢However, the arrows in Figure 3 are used informally to indicate that the medical receptionist
initiates the transaction and data is transferred to the patient record system.
➢Use case diagrams give a fairly simple overview of an interaction so you have to provide
more detail to understand what is involved.
➢This detail can either be a simple textual description, a structured description in a table, or
a sequence diagram.
➢You chose the most appropriate format depending on the use case and the level of detail
that you think is required in the model.
➢Figure 4 shows
a tabular description
of the
‘Transfer data’ use case.

Figure 4: Tabular description of the ‘Transfer data’ use case

➢Composite use case diagrams show a number
of different use cases.

➢Sometimes, it is possible to include all possible

interactions with a system in a single composite
use case diagram.

➢However, this may be impossible because of

the number of use cases. In such cases, you
may develop several diagrams, each of which
shows related use cases.

➢For example, Figure 5.5 shows all of the use

cases in the MHC-PMS in which the actor Figure 5: Use cases involving the role ‘medical receptionist’
‘Medical Receptionist’ is involved.
Requirements Specification and Requirement Validation
For requirement specification write(SRS)
Once the SRS completed validation begins
Requirement Validation
The development of software begins once the requirements

Ensure that the requirements specification (SRS)contains no

errors
If errors present in the SRS will adversely affect the cost if they
are detected later in the development process or when the
software is delivered to the user.
 So it is desirable to detect errors in the requirements before the
design and development of the software begins.
In the validation phase the requirements are examined for
consistency, omissions, and ambiguity.
The basic objective is to ensure that the SRS reflects the actual
requirements accurately and clearly.
objectives of the requirements document are given below.
1. To certify that the SRS contains an acceptable description of the system to be implemented
2. To ensure that the actual requirements of the system are reflected in the SRS
3. To check the requirements document for completeness, accuracy, consistency, requirement
conformance to standards and technical errors.
Requirements validation studies the of the
requirements document while requirements analysis studies the
from the system stakeholders (users).
 Requirements validation: Have we got the requirements right?
Requirements analysis: Have we got the right requirements?

The requirements document should be formulated and organized according to the standards of the organization.
The organizational standards are specified standards followed by the organization according to which the
system is to be developed.

The agreed actions is a list that displays the actions to be performed to resolve the problems
depicted in the problem list.
Requirements Review
Requirements validation determines whether the requirements are substantial to design
the system.
The problems encountered during requirements validation are listed below.
1.Unclear stated requirements
2.Conflicting requirements are not detected during requirements analysis
3.Errors in the requirements elicitation and analysis
4.Lack of conformance to quality standards.
To avoid the problems stated above, a requirements review is
conducted, which consists of a review team that performs a
systematic analysis of the requirements.
The review team consists of software engineers, users, and
other stakeholders who examine the specification to ensure that
the problems associated with consistency, omissions, and
errors are detected and corrected.
 In the review meeting check list are:
1. Is the initial state of the system defined?
2. Is there a conflict between one requirement and the other?
3. Are all requirements specified at the appropriate level of abstraction?
4. Is the requirement necessary or does it represent an add-on feature that may not be essentially
implemented?
5. Is the requirement bounded and has a clear defined meaning?
6. Is each requirement feasible in the technical environment where the product or system is to be
used?
7. Is testing possible once the requirement is implemented?
8. Are requirements associated with performance, behavior, and operational characteristics clearly
stated?
9. Are requirements patterns used to simplify the requirements model?
10.Are the requirements consistent with the overall objective specified for the system/product?
11.Have all hardware resources been defined?
12.Is the provision for possible future modifications specified?
13.Are functions included as desired by the user (and stakeholder)?
14.Can the requirements be implemented in the available budget and technology?
15.Are the resources of requirements or any system model (created) stated clearly?
Other Requirements Validation Techniques
A number of other requirements validation techniques are used either individually or in
conjunction with other techniques to check the entire system or parts of the system. The
selection of the validation technique depends on the appropriateness and the size of the
system to be developed. Some of these techniques are listed below.
1. Test case generation: The requirements specified in the SRS document should be testable. The
test in the validation process can reveal problems in the requirement. In some cases test becomes
difficult to design, which implies that the requirement is difficult to implement and requires
improvement.
2. Automated consistency analysis: If the requirements are expressed in the form of structured or
formal notations, then CASE tools can be used to check the consistency of the system. A
requirements database is created using a CASE tool that checks the entire requirements in
the database using rules of method or notation. The report of all inconsistencies is identified and
managed.
3. Prototyping: Prototyping is normally used for validating and eliciting new requirements of the
system. This helps to interpret assumptions and provide an appropriate feedback about the
requirements to the user. For example, if users have approved a prototype, which consists of
graphical user interface, then the user interface can be considered validated.
Requirements Elicitation techniques
https://www.softwaretestinghelp.com/requirements-elicitation-techniques/
Requirements management in Agile
Agile requirements management is built on the principle of flexibility, so any
potential challenges are identified and resolved much earlier in
the process, minimizing expensive and costly rework. A few benefits of the agile
approach include:
Improved product design and delivery. A recent report suggests that best-in-class
RM solutions can significantly improve product design and delivery
for agile development teams.
products for the internet of things (IoT), and scaling Agile practices, AD&D
[application development and delivery] leaders long for something to bring

Improved traceability. The right RM solution can enhance development

transparency through traceability. Traceability empowers teams to perform impact
analysis more readily, which is critical to product development.
Achieve quicker time to market. Teams are facing more complexity and pressure to
comply with industry regulations, and need to measure customer value to search,
track and connect interdependent requirements. Achieving faster time
to market requires that teams collaborate faster and more effectively, working to
build traceability requirements and test case
Designing with greater flexibility through the agile requirements management lifecycle
The agile requirements management lifecycle is focused on clearly defining a
scope, so that you better understand what needs to happen to meet the desired end goal.
It provides a high-level understanding of business goals, and outlines what is needed for
the project to be a success.
Consider taking the following steps:
Understand user stories. User stories give you powerful information about the problem
include a few sentences about how the user expects the product to perform. A template

Outline the most important requirements. Identify what requirements are most essential
based on the high-level business strategy. These requirements may be supported by user
stories, functional requirements and more based on the specific client goals.
Transform to product features. This stage is about fine-tuning and translating the details
that any requirements are easily understood by anyone working to implement them. User
stories are linked to features and tasks, so that developers understand what they need to
do but also why they are doing it.
Collaboration and Buy-In

buy-in (before or after management approves the project) so the

development process can move forward. With buy-in, the team backs the
best solution, makes a smart decision and does what is necessary to move
forward with the requirements management process.
Team collaboration is key to establishing good requirements. Collaborative
teams work hard to make sure everyone has a stake in the project and
provides feedback. When there is a commitment and understanding of

communication issues arise, people get frustrated and projects get

delayed.
Traceability and Change Management
Requirements traceability is a way to keep everyone in the loop.
It organizes, documents and keeps track of all requirements,
from initial idea to testing. A simple metaphor for traceability is
connecting the dots to identify the relationships between items
within a project. The following figure shows an example of a
common downstream flow.
Companies should be able to trace each requirement back to its
original business objective throughout the development process, not
identify the ripple effect changes have, see if they have completed a
requirement and if they tested it properly. With traceability, and by
managing changes effectively, managers gain the visibility to
anticipate issues and ensure continuous quality.
Traceability also makes sure the product meets all the vital
requirements that come from different stakeholders. By tracing
requirements, all team members stay connected to each other and
to all interdependencies. And by managing changes well, a company
can avoid scope creep unplanned changes that occur when
requirements are not clearly captured, understood and
communicated. The benefit of good requirements is a clear
understanding of the product and the scope involved. This leads to a
better development schedule and budget, which prevents delays and
cost overruns.
 Quality Assurance
Getting requirements right the first time means better quality, faster development cycles and
higher customer satisfaction with the product. Concise, specific requirements can help companies
detect and solve problems earlier rather than later, when they are much more expensive to fix.
Research has shown that project teams can eliminate 50 percent to 80 percent of project defects
by effectively managing requirements. In addition, according to Borland Software (now Micro
Focus), it can cost up to 100 times more to correct a defect later in the development process,

By integrating requirements management best practices into their quality assurance process,
companies can help teams increase efficiency and eliminate rework. According to the Carnegie
Mellon Software Engineering Institute, 60 to 80 percent of the cost of software development is in
rework. In other words, development teams are wasting the majority of their budgets on efforts

simple concept. It helps teams answer the question: Does everyone from business leaders to
product managers and project leaders to developers, QA managers and testers understand
what is being built and why?
When everyone is collaborating and has full context and visibility into the discussions, decisions
and changes involved in product development, they maintain high quality and almost always
ensure success.