1

Course Outline

1. Introduction of Requirement Engineering

2. Software Requirement
3. Classification of Requirements
4. Requirements process
5. Levels/layers of Requirement
6. Requirement Characteristics
7. Analyzing quality requirement
8. Software Requirement in context of System
engineering
9. Requirement evolution
10. Requirement traceability
11. Requirement prioritization
12. Trade-off analysis
13. Risk analysis and impact analysis
14. Requirement management
15. Interaction between Requirement and architecture
16. Requirement elicitation, source and techniques
17. Requirement specification and documentation
18. Specification sources and techniques
19. Requirement validation and techniques
20. Management of Requirement
21. Introduction to Management
22. Requirement management problems
23. Managing Requirement in and Acquisition Organization,
Supplier organization, Project Organization
24. Requirements engineering for agile methods

2
 Introduction to requirement Engineering
What is a requirement?
According to IEEE standard 729, a requirement is defined as follows:
• A condition or capability needed by a user to solve a problem
or achieve an objective.
• A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification or other formally imposed documents.
OR
Requirements are descriptions of the services that a software
system must provide and the constraints under which it must
operate
Requirements can range from high-level abstract statements of
services or system constraints to detailed mathematical functional
specifications
Requirements engineering:-
The requirement of a system is the description of the services that a
system should provide and the constraints on its operation. This is
the process of finding out, analyzing, documenting and checking
these services or constraints is called requirement engineering (RE).
Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering
design/engineering process.
OR
The process to gather the software requirements from client, analyze
and document them is known as requirement engineering (RE).
OR
“Requirements are a specification of what should be implemented.
They are descriptions of how the system should behave, or of a
system property or attribute. They may be a constraint on the
development process of the system.”
Requirements Engineering is the process of establishing the services
that the customer requires from the system and the constraints under which it
is to be developed and operated
Requirements may serve a dual function:
 As the basis of a bid for a contract
 As the basis for the contract itself
3
 Software Requirements
“The software requirements are description of features and
functionalities of the target system”
 A complete description of what the software system will do
without describing how it will do it is represented by the
software requirements
 Software requirements are complete specification of the
desired external behavior of the software system to be built
Some Important Definitions
1) User Requirement:- is the high-level abstract requirement.
User requirement are the statement written in natural
language plus diagram. It is written for the customer. It
describes what the systems do and also describe the services
that the system users want.
. OR
User requirements describe goals or tasks the users must be
able to perform with the product that will provide value to
someone. The domain of user requirements also includes
descriptions of product attributes or characteristics that are
important to user satisfaction
“A goal or task that specific classes of users must be able to
perform with a system, or a desired product attribute”

2) System Requirement:- are more detailed description of the

software systems function, services and operational constraints it
is written for developers. It is the detail description of functional
or non-functional requirement.
“System requirement are more detailed descriptions of the
system service and constraints, written for developer of the
system”
. OR
System requirements describe System requirements describe the
requirements for a product that is composed of multiple
components.
“A top-level requirement for a product that contains multiple
subsystems, which could be all software or software and
hardware.”
System requirement are classified into functional and non-
functional requirements

4
3) Functional Requirement:- The functional requirement for a
system describe “what the system should do”. It is statement of
services the system should provide. It is the actual services which
a system will provide, and user wants from the software.
=> A description of a behavior that a system will exhibit under
specific conditions.
=> The functional Requirements for a system specify what the
system should do.
=> These are the Requirements that the end user specifically
demands as basic facilities that the system should provide.
=> These are basically the requirements stated by the user which
one can see directly in the final product, unlike the non-functional
requirements

4) Non-Functional Requirement:- The requirement that are not

directly concerned with the specific services delivered by the
system to users.
.
=> Non-functional Requirements as the name suggested, are the
requirements that are not directly concerned with the specific
services delivered by the system to its user. .
=> It’s the Requirements that is essentially specifies how the
system should behave and that it is a constraint upon the systems
behavior. .
=> Non-functional requirements could also be think of as quality
attributes of a system
.
=> Non-functional Requirements are often more critical than the
individual functional Requirements, as system user may finds way
to work around a system functional Requirements ,However
failing to meet non-functional Requirements means the system is
unusable.
Most non-functional requirements relate to the system as a
whole. They include constraints on timing, performance,
reliability, security, maintainability, accuracy, the
development process, standards, etc.
There are three major types of non-functional
requirements
 Product
Specify or constraints the runtime behavior of the software
.

5
 Organizational
These requirements are broad system requirement derived
from policies and procedure in the customer and development
organization
Organizational Requirements Examples
• The system development process and deliverable documents
shall conform to the MIL-STD-2167A

• Any development work sub-contracted by the development

organization shall be carried out in accordance with Capability
Maturity Model

 External
Requirement derived from factors external to the system and its
development process

5) Domain Requirement:-
. The requirement which are characteristic
of a particular category or Domain of project. Domain
Requirements are expectations related to a particular type of a
software, purpose or industry. Domain Requirements can be
Functional or Non-functional .the common factor is that they
meet established standard for that category of software project.
Example of domain requirements
• One example is software in medical equipment , the software must be
developed in accordance with IEC 60601 regarding the basic safety and
performance for medical electrical equipment

6
 • In an academic software that maintains the records of a school or
college, the functionality of being able to access the list of faculty and
list of students of each grade is a domain requirements
• A train control system has to take into account the braking
characteristics in different conditions
6) Business Requirement:-
. A high-level business objective of the
organization that builds a product or of a customer who procures
it. It describes the benefits of the business that they hop to
achieve .
Business requirements describe why the organization is
implementing the system—the business benefits the organization
hopes to achieve. The focus is on the business objectives of the
organization or the customer who requests the system

7
 Classification of Requirements
Requirements are usually classified into the following broad
categories namely as:
Functional Requirements
Non- Functional Requirements
Domain Requirements

Levels/layers/types of Requirement
Some types of requirements are as the following:
Functional Requirements
Non- Functional Requirements
User Requirements
System Requirements
Business Requirements etc.

Requirement Characteristics
A requirement needs to meet several criteria to be considered a
“good requirement”. Good requirements should have the following
characteristics:
Testable:
Testers should be able to verify whether the requirement is
implemented correctly. The test should either pass or fail. To be
testable, requirements should be clear, precise, and
unambiguous.
Complete:
Requirement should be specified for all the possible conditions
that can occur. And requirement is not missing the necessary or
relevant information.
Clear:
Requirements should not contain unnecessary verbiage or
information. They should be stated clearly and simply.
Correct:
If a requirement contains facts, these facts should be true.
Requirements meet the actual business or system needs.

8
 Understandable:
Requirements should be grammatically correct and written in a
consistent style. Standard conventions should be used. The word
“shall” should be used instead of “will,” “must,” or “may.”
Feasible:
The requirement should be doable within existing constraints
such as time, money, and available resources.
Consistent:
There should not be any conflicts between the requirements.
Conflicts may be direct or indirect. Direct conflicts occur when, in
the same situation, different behavior is expected.

Requirements process
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.
The process of requirements engineering happens in five steps. The
below figure illustrates the five steps of requirements engineering

9
1. Feasibility Study:-
The main aim of a feasibility study is to create reasons for
the development of the software that the users accept, that is
flexible enough and open to changes.
The main purpose of the feasibility study is to check the given
requirement and analyses that the given software is possible or not
on the technical or economical feasibilities. There are several types
of feasibility. They are:
• Technical Feasibility
. • Operational Feasibility
. • Economic Feasibility
2. Elicitation of Requirements and Analysis:-
This process is also called requirements gathering. It
is the process of the discovering or gathering the requirement of a
system. It is basically collecting requirement form stockholders, user
and customer by requirement elicitation techniques.
During requirements elicitation, software engineers work with
stakeholders to find out about the application domain, work
activities, the services and system features that stakeholders want,
the required performance of the system, hardware constraints, and
so on.
The requirement elicitation and analysis processes

10
The process activities are:

1. Requirements discovery and understanding:- This is the process

of interacting with stakeholders of the system to discover their
requirements. Domain requirements from stakeholders and
documentation are also discovered during this activity.
(Interacting or work with stakeholders to discover their
requirement Domain requirement are also discover)
.
2. Requirements classification and organization:- This activity
takes the unstructured collection of requirements, groups related
requirements and organizes them into coherent clusters.
(Group related requirements are organizes into coherent clusters)
.
3. Requirements prioritization and negotiation:-
Prioritization requirement and resolving
requirement conflicts.
Inevitably, when multiple stakeholders are involved, requirements will
conflict. This activity is concerned with prioritizing requirements and
finding and resolving requirements conflicts through negotiation.
Usually, stakeholders have to meet to resolve differences and agree on
compromise requirements.
4. Requirements documentation:-
Requirement are documentation
and input the next round of spiral.
The requirements are documented and input into the next round of the
spiral. An early draft of the software requirements documents may be
produced at this stage, or the requirements may simply be maintained
informally on whiteboards, wikis, or other shared spaces.

3. Requirements Specification:-
Requirement specification is the process of writing down
the user and system requirements in a requirement document. It
describes what will be the feature, services and behavior of the
software. It provides the detail description of functional and non-
functional requirements.
.
A document consisting of requirements that are collected from
various sources like the requirements from customers expressed in
an ordinary language and created by the software analyst are called
a specification document for software requirements.

11
4. Requirements Validation:-
Requirement specification is the process of
checking that requirements define the system that the customer
really wants. It overlaps with elicitation and analysis, as it is
concerned with finding problems with the requirements. In the
process we check and find problem to requirement. In requirement
validation process, different checks should be carried out on
requirements in requirement documents are:

1. Validity checks:- These check that the requirements reflect the real
needs of system users.
2. Consistency checks:- Requirements in the document should not
conflict.
3. Completeness checks:- The requirements document should
include requirements that define all functions and the constraints
intended by the system user.
4. Realism checks:- By using knowledge of existing technologies, the
requirements should be checked to ensure that they can be
implemented within the proposed budget for the system.
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.

Another diagram of requirement engineering processes

12
Spiral Model of requirement engineering processes

13
 Requirement elicitation, source and
techniques
Elicitation is the process of identifying the needs and constraints of
the various stakeholders for a software system.
This process is also called requirements gathering. It is the process of
the discovering or gathering the requirement of a system. It is
basically collecting requirement form stockholders, user and
customer by requirement elicitation techniques.
The aims of the requirements elicitation process are to understand
the work that stakeholders do and how they might use a new system
to help support that work. During requirements elicitation, software
engineers work with stakeholders to find out about the application
domain, work activities, the services and system features that
stakeholders want, the required performance of the system,
hardware constraints, and so on.
Elicitation is used to discover business, user, functional, and non-
functional requirements, along with other types of information.
Requirements elicitation is perhaps the most challenging, critical,
error-prone, and communication-intensive aspect of software
development.
Requirements Elicitation Stages

1. Objective setting
2. Background knowledge acquisition
3. Knowledge organization
4. Stakeholder requirements collection

Requirement Elicitation Sources

There are several sources of requirement elicitation are as the
following:
 users,
 customers,
 Other stakeholders.

14
 Requirement Elicitation Techniques
There are several techniques available for elicitation, however, the
commonly used techniques are explained below:
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. Multiple
ideas and information give you a repository of knowledge and you can
choose from different ideas.

Interview:-
This is the most common technique used for requirement
elicitation. Interview techniques should be used for building strong
relationships between business analysts and stakeholders. In this
technique, the interviewer directs the question to stakeholders to obtain
information. One to one interview is the most commonly used technique.
If the interviewer has a predefined set of questions then it’s called a
structured interview.
If the interviewer is not having any particular format or any specific
questions then it’s called an unstructured interview.
Workshops:-
For multi-stakeholder, complex projects, workshops are
one of the most resource-efficient methods to elicit requirements.
Intense, focused, and highly productive workshops have a key role to play
in getting all parties onto the same page. Workshop events help Subject
Matter Experts and Stakeholders to collaborate, resolve conflicts, and
come to an agreement.
Focus Group:-
In a focus group, relevant stakeholders provide feedback
to refine processes, ideas, or solutions that emerged as an outcome of
earlier elicitation activities, such as brainstorming and document analysis.
The feedback and comments are recorded for use in later phases of
requirements elicitation.
Questionnaires:-
Questionnaires are a way to survey large groups of
users to understand their needs. They are inexpensive, making them a
logical choice for eliciting information from large user populations, and
they can be administered easily across geographical boundaries. The
analyzed results of questionnaires can be used as an input to other
elicitation techniques.

15
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. Prototypes can be used to create a mock-
up of sites, and describe the process using diagrams .
Document analysis:-
Document analysis entails examining any
existing documentation for potential software requirements. The
most useful documentation includes requirements specifications,
business processes, lessons learned collections, and user manuals for
existing or similar applications .
Some Other Methods
 Interface Analysis
 Observation
 Survey etc.

16
Requirement specification and documentation
“Requirement specification is the process of writing down the user
and system requirements documents. It describes the feature,
services and behavior or the software”
The requirement document is a formal document
used to communicate the requirements to customer, engineers and
managers. It is also known as software Requirement Specification
(SRS). It describes the services and functions which the system
should provide. It describes the detail description of functional and
non-functional requirements.
Typically, requirement document are written in natural languages
(likes, English, Japanese, French etc.). And also the structure
languages can be used with the natural languages to specify the
requirements. For software system, the requirements documents
may include a description of the hardware on which the system is to
run.
SRS document user to describe the behavior of system, functional or
non-functional requirements of the software.

Users of Requirements document’s

 System customers
 Managers
 System engineers
 System test engineers
 Development team
 Maintenance team
 Clients
 Technical writers
An SRS gives you a complete picture of your entire project. It provides a
single source of truth that every team involved in development will
follow.
It is yours plan of action and keeps all yours team from development to
maintenance on the same page.

Characteristics/Features of Good SRS

 Correctness
 Completeness
17
  Consistency
 Modifiability
 Verifiability
 Design Independence
 Testability
 Understandable by customers
 Etc.

Scope of Good SRS

 Used in design implementation
 Used in project monitoring
 Used in verification
 Used in validation
 Used as legal documents of agreement.
Clients/ developers may have their own way of organizing as SRS. In this
regard we have following formats

 IEEE/ANSI 830-1993 standard

 US department of Defense
 NASA

18
 Requirement Specification sources and
techniques
For single source requirements, there will be almost no possible
verification of specifications because no comparable check will exist.

Requirement Specification Sources

1. Buyers:
They are the persons responsible for accepting and executing the
software. They can be individual, organization, trusts or even the
government or public of a country.
2. User/Beneficiaries :
These are the users of the product for which the product is intended
3. Operators:
They are the persons who work on the software to make the services
of the software available to its beneficiaries or the end users.
4. Domain Experts :
They are professionals with experience and expertise of the domain in
which the software provides its services i.e. financials, data transfer
networking etc. Domain experts unwind the hidden or unseen
probable requirements or risk involves in product requirement

5. Developers
The software engineering responsible for developing the software
makes it provide the expected serveries. They are responsible for
software design, prototype development, and technical feasibility.
They work closely with end users, buyers, and application experts

19
 Requirement validation and techniques
Requirements validation is the process of checking that requirements defined
for development, define the system that the customer really wants. To check
issues related to requirements, we perform requirements validation. The
requirements validation process detects errors in the SRS.
Requirements validation makes sure that the requirements written in software
requirements specification (SRS) must be complete and consistent and are
according to the customer’s needs.
During the requirements validation process, different types of checks should
be carried out on the requirements. These checks include:

 Consistency checks:- The requirements should be consistent with other

requirements, which mean no two requirements should conflict or oppose each
other.
 Completeness checks:- The requirements should be complete in every sense.
 Validity checks:- The functions proposed by stakeholders should be aligned with
what the system needs to perform.
 Realism checks:- Ensure the requirements can actually be implemented using
the knowledge of existing technology, the budget, schedule, etc.
 Verifiability:- Requirements should be written so that they can be tested. This
means you should be able to write a set of tests that demonstrate that the
system meets the specified requirements.
 Ambiguity checks:- Req
The output of requirements validation is the list of problems and agreed on
actions of detected problems. The lists of problems indicate the problem
detected during the process of requirement validation. The list of agreed
action states the corrective action that should be taken to fix the detected
problem.

Validation and techniques

There are some techniques you can use to validate the requirements, and you
may use one or more of them together, depending on your needs.
Test case generation:-
The requirements mentioned in the SRS document should be testable. If it is
not testable then that generally means that the test is difficult or impossible to
design and thus the requirements should be reconsidered.
Prototyping:-
In this validation technique, a basic working model (prototype) of the system is
presented before the end-user, to validate and ensure if it meets their needs.
This technique is generally used to take feedback from the user.

20
Requirements Reviews:-
In this approach, a group of people from both organization side and user side
carefully reviews the SRS. They review the document to check for any errors
and ambiguity.
Automated consistency analysis:-
First, the requirement is structured in formal notation then a tool like CASE is
used to check for any in-consistency or errors. For the identified
inconsistencies and errors corrective actions are taken. In this approach,
automated detection tool is used to search for type errors, missing cases, error
in requirement specification, etc.
Walk-through:-
This is not a formally defined procedure. The approach follows few steps, that
are:
• Checking whether the idea is feasible or not
• Obtaining the ideas and opinions of other
• Checking the approval of others and reaching an agreement.
0 Requirement Testing:-
Testing is a powerful tool for both validating and verifying requirements. Each
requirement should be testable i.e. it should be possible to define tests to
check whether or not that requirements has been met.
0 User Manual Development
0 Model Validation

Validation VS verification
• Verification: It is a process to check whether the software meets the
specified requirements that are written during elicitation phase or not. This is a
process of confirming that the designed and built product fully meets the
documented requirements.
• Validation: It is a process to check whether the specifications written
during the elicitation phase captures all the user’s needs. During validation
phase developers use different set of tasks that ensures that the software built
is traceable to user’s requirements.

21
 Introduction to Management
The management of the requirements engineering process is similar to the
management of any other endeavor. We need the Requirement to sorts the
activities that must be undertaken.
Basically, the management involves the followings activities:
 Planning - deciding what is to be done Presentation
 Organizing – making arrangements
 Staffing – selecting the right people for job
 Directing – giving instruction
 Monitoring – checking on progress
 Controlling - taking action to remedy hold-ups
 Representing – liaising with users, etc.
 Innovating - coming up with the new solution

Requirement Management
The process of managing changes to the requirements for a system
Requirement management is the process of documenting, analyzing,
tracing, prioritizing, and agreeing on requirement and then controlling change
and communicating to relevant stakeholders. It is a continuous process
throughout a project life cycle.
Requirement Management is a systematic process of eliciting, organizing,
and documenting the requirements of the system, and also establishes and
maintains agreement between the customer and the project team on the
changing requirements of the system.
Requirements management involves communication between the project
team members and stakeholders, and adjustment to requirements changes
throughout the course of the project. To prevent one class of requirements
from overriding another, constant communication among members of the
development team is critical.
Main Concerns in Requirements Management:
 Managing changes to agreed requirements
 Managing the relationships between requirements
 Managing the dependencies between the requirements document and
other documents produced in the systems engineering process
The Purpose of Requirements Management?
The main purpose of requirements management is to ensure product
development goals are successfully met. It is a set of techniques for
documenting, analyzing, prioritizing, and agreeing on requirements so that
engineering teams always have current and approved requirements

22
Requirement Attributes:
Requirement Attributes are properties of a requirement. Attributes are used to
establish a context and background for each requirement. They can be used to
filter or sort the requirements. Lists of possible attributes are as below:
 Requirement ID (unique)
 Requirement name
 Requirement description
 Requirement version number
 Requirement type
 Requirement change history
 Requirement status
 Requirement priority
 Requirement owner etc.

Requirements Management and Traceability:

One of the most important components of requirements management is
traceability. Requirements cannot be managed effectively without
requirements traceability. Requirements traceability refers to ability to
describe and follow the life of a requirement, in both a forwards and
backwards direction.
A requirement is traceable if we can discover who suggested the requirement,
why the requirement exists, what requirements are related to it and how that
requirement relates to other information such as systems designs,
implementations and user documentation.
Tracing allows us to understand why the requirement exists, the impact of
change, if the set of requirements is complete, and helps prioritize
requirements.
Requirements Change Factors:
Requirements changes occur while the requirements are being elicited,
analyzed and validated and after the system has gone into service.
 Changing customer priorities
 Environmental changes
 Organizational changes
Change Management Stages:

23
Sources of Change:
 New business or market condition
 New customer needs
 Business growth/downsizing
The Five Stages of Requirements Management
Requirements management is often viewed as a five-step development
process. The project manager and key stakeholders will evaluate the
requirements during each step of the process. These steps are outlined below:
Step 1: Investigation:-
The first step will be that of fact-finding or investigation. Participants identify
their goals and examine the requirements necessary for meeting those goals.
They evaluate the resources that they have for meeting the requirements,
identify any obstacles that may exist and propose solutions.
Step 2: Feasibility:-
Feasibility study sometimes called feasibility analysis or feasibility report
The next stage of requirements management involves the feasibility of the
project in terms of cost. This helps to shape the project as it moves forward
toward design and development. The project manager and stakeholders must
determine exactly what is required to ensure the project is viable from an
economic standpoint.
Step 3: Design:-
After the investigation and feasibility stages, the project then moves forward
to the design phase. This is where tangible goals start to come to fruition.
There will inevitably be some changes to the requirements that will need to be
communicated and subsequently addressed by those responsible for various
aspects of the design. An important part of requirements management is
determining if these changes will affect the cost or scope of the project.
Step 4: Construction and Testing:-
Once the design has been approved, a prototype or working model is typically
constructed and put through a series of tests.
This helps the team ensure that the project will be able to progress according
to schedule and stay within budget. The project requirements are often
adjusted and refined during the testing stage of requirements management
and must be documented accordingly
Step 5: Release:-
Once the product is finally approved, it is released. As the product enters into
use, there is still the need for ongoing requirements management related to
proposed upgrades, add-ons, improvements, marketing, sales, and the like.
These will be documented and addressed during the investigation phase of the
next release.

24
Why is requirements management important in project
management?
 Reducing cost
 Improving quality
 Decreasing time taken
 Decreasing risks
 Enabling effective scope management
Requirements management helps ensure project success by avoiding the top reasons for
project failure:
 poor requirements capture,
 scope creep,
 Disagreements about acceptance.
Not having an agreed requirement sets you up for project failure. Requirements capture is
usually led by a requirements manager with support from systems engineering.

Requirement management problems

Requirement management is a set of activity that helps the project team to identify,
control and track requirement and changes to requirement at any time as project
proceeds.
The goal of software development is to develop quality software – on time and on
budget – that meets customers’ real needs. Project success depends on good
requirement management. Requirement management is very important because
80% projects are failing due to poor requirements management.
Some problems that occur in managing the requirement are as the following:
 Unclear Requirements:-
. Unclear requirement are more problematic than they
most people think. They can lead to a complete roadblock or even to a project
disaster. This leads to financial difficulties, which makes it hard to move forward
with the project.
 Changing Requirements:-
. One common characteristic of requirements is that they
are constantly evolving, especially with the nature of today’s market demands.
This brings on the challenge of constantly needing to track and stay updated on
each requirement as well as keep the entire organization.
Requirement changes for 3-main reasons:
o Lack of understanding of the requirements
o Defects are identified
o Requirements are overlooked and missed.
 Requirements definition:-
. Requirements definition often requirement the use of
specialized software to gather all the requirement and document information
about each one, create dependencies, stay updated on each requirement status
and analyze them.
 Requirements Prioritization:-
. When there is a long list of requirements, it can be
challenging to know which ones are worth implementing and which ones should
be handled first

25
Other Problems are:
 People have had significant experience of managing requirements
 People do not properly distinguish between user or stakeholder requirements
and system requirements.
 The way in which requirements are managed will depend upon the type of
organization in which the work is being done.

Requirement Error’s
A deficiency or error in the requirements can slow down software development
process. If these errors were not removed, then it will degrade the design, code, and
even implementation phase. Requirements errors are most expensive to eliminate.
Types of Requirements Errors:
 Errors of omission: - It means skip the requirement. Error or omission is most . . .
. common among requirements errors
 Errors of clarity and ambiguity:- It means are requirements are not clear
 Errors of commission:- It means the human action that should not be performed, .
. but which in fact are performed.
 Errors of speed and capacity:- Your software is working fine but not working in . .
. the required time this is called error of speed.. . . . .
. When it comes to capacity it can be relevant to . . .
. memory.
Negative Impact of Requirements Errors:
The resulting software may not satisfy the real needs of users as well the concerned
organization.
Addressing Requirements Errors :
 Prevention
 Removal
Prevention vs. Removal:
 For requirements errors, prevention is usually more effective than removal.
 Joint application development (JAD), quality function deployment (QFD), and
prototyping are more effective in error prevention.
 Requirements inspections and prototyping play an important role in defect removal.

Requirement Management Tools

 Jama Software
 Modern Requirements
 Visure Requirements
 Orcanos
 IBM Engineering Requirements Managements DOORS Nest
 Accompa
 Cliber
 Pearls
 Perforce Helix RM

26
 Requirement Prioritization
When customer expectations are high, and timelines are short you need to make
sure your project team delivers the most valuable functionality as early as possible.
Prioritization is the only way to deal with competing demands for limited resources.

Requirement Prioritization means giving precedence to some requirements

over other requirements based on feedback from system stakeholders. It helps
you manage your requirements and your resources.
Benefits of Requirements Prioritization
 Stakeholders can decide on the core requirements for the system
 Planning and selection of ordered, optimal set of software requirements for
implementation in successive releases
 Helps in trade-offs of conflicting constraints such as schedule, budget, resources,
time to market, and quality
 Balances the business benefit of each requirement against its cost
 Balances the implications of requirements on the software architecture and
future evolution of the product and its associated cost
 Selects only a subset of the requirements and still produce a system that will
satisfy the customers
 Establish relative importance of each requirement to provide the greatest value
at the lowest cost
Requirements prioritized to minimize risk during development so that the most
important or high risk requirements are implemented first. Prioritization is an
iterative process and might be performed at different abstraction levels and with
different information in different phases during the software lifecycle.

Aspects of Prioritization
Requirements can be prioritized taking many different aspects into account
An aspect is a property or attribute of a project and its requirements that can be
used to prioritize requirements. It is
important for stakeholders to develop a list of aspects to help in decision-making
process

 Importance:- The stakeholders should prioritize which requirements are most

important for the system. Importance is multifaceted, and could be urgency of
implementation, importance for product architecture, strategic importance
 Penalty:- It is possible to evaluate the penalty that is introduced if a requirement
is not fulfilled. Penalty is not just the opposite of importance
 Cost:- The implementation cost is usually estimated by the developing
organization. Measures that influence cost include: complexity of the
requirement, the ability to reuse existing code, the amount of testing and
documentation needed. Cost is often expressed in terms of staff hours
 Time:- Time is influenced by many other factors such as degree of parallelism in
development, training needs, need to develop support infrastructure, complete
industry standards
 Risk:- Every project carries some amount of risk

27
 Other aspects:- Financial benefit, strategic benefit, competitors,
competence/resources, release theme, ability to sell

Prioritization Techniques
The prioritization can be done with various measurement scales and types. There
are different techniques of prioritization are as the following:

Ranking:- When you rank requirements on an ordinal scale, you give each one a
different numerical value based on its importance. For example, the number 1 can mean
that the requirement is the most important and the number n can be assigned to the least
important requirement, n being the total number of requirements.

Numerical Assignment (Grouping):- This method is based on grouping

requirements into different priority groups with each group representing something
stakeholders can relate to. For example, requirements can be grouped into critical
priority, moderate priority and optional
priority.
Bubble Sort Technique:- To prioritize requirements using bubble sort, you take
two requirements and compare them with each other. If you find out that one requirement
should have greater priority over the other, you swap them accordingly.
Hundred Dollar Method:- This simple method is useful anywhere multiple
stakeholders need to democratically vote on which requirements are the most important.
All stakeholders get a conceptual 100 dollars, which they can distribute among the
requirements.
Analytic Hierarchy Process (AHP):- The method actually describes an
entire framework for making correct decisions in fields such as business, healthcare,
government, and many others. In essence, stakeholders decompose their goal into
smaller sub-problems, which can easily be comprehended and analyzed (in the form of a
hierarchy).
MoScoW Technique:- This method uses four priority groups: MUST have,
SHOULD have, COULD have, and WON'T have. With this technique, stakeholders can
prioritise requirements in a collaborative fashion. The acronym represents the following:

 MUST (Mandatory)
 SHOULD (Of high priority)
 COULD (Preferred but not necessary)
 WOULD (Can be postponed and suggested for future execution)

The decisions of stakeholders on requirements' priorities are categorised as shown above.

Requirement evolution

Requirements evolution is a main driver for systems evolution. Traditionally, requirements

evolution is associated to changes in the users’ needs and environments.

Requirement evolution is the changes occur when mapping a theory to another theory
through a process of rational belief revision. The process begins from an incomplete
requirement model, at each step, a new set of requirement changes is brought to bear.

Evolution of requirements refers to changes that take place in a set of requirements after
inital requirements engineering phase. Thus changes in requirements that may happen in
initial elicitation, analysis, specification and validation phases are not evolutionary

28
 Requirement traceability

Requirements traceability is the tracking of requirements throughout the product

development lifecycle. It is a document that provides forward and backward visibility into all
activity of each requirement (including design, development, testing, and support).
Requirements traceability helps minimize the risk of negative outcomes and maximize
productivity. Its benefits include greater team efficiency, easier regulatory compliance,
and higher-quality products.

Quality Requirement

Quality assurance in requirement engineering has a great impact on the product

quality. It checks whether the requirements meet the desired quality attributes i.e.
adequacy, completeness, consistency etc. Quality Assurance of the requirement is
important because the cost of requirements failure is very high.

Risk analysis

Risk analysis has been also shown important in the software design phase to evaluate
criticality of the system, where risk is analyzed and necessary countermeasures are
introduced. However, it may happen that the risk reduction results in the revision of
the entire design and possibly of the initial requirements, introducing thus extra
costs for the project.
A Risk Management strategy can be defined as a software project plan or the risk
management steps. It can be organized into a separate Risk Mitigation, Monitoring
and Management (RMMM) Plan.
The RMMM plan documents all work performed as part of risk analysis and is used
by the project manager as part of the overall project plan. Teams do not develop a
formal RMMM document. Rather, each risk is documented individually using a risk
information sheet (RIS). RMMM documents all work performed as part of risk
analysis and is used by the project manager as part of overall project plan.
1. Risk monitoring is a project tracking activity with three primary objectives:
2. Assess whether predicted risks do, in fact, occur
3. Ensure that risk management steps defended for the risk are being properly
applied
4. Collect information that can be used for future risk analysis

29