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 “A condition or capability
needed by a user to solve a problem or achieve an objective. “
A condition that met 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 engineering:-
The requirement of a system is the description of the services that a system should provide
and the constraints on its operation. The process of finding out, analyzing, documenting and
checking these services or constraints is called requirement engineering (RE).
Requirements engineering (RE) is also refers to the process of defining, documenting,
and maintaining requirements in the engineering process.
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

Software Requirements
“The software requirements are description of features and functionalities of the
target system”. It is a complete description of what the software system will do
without describing how it will do
Software requirements are complete specification of the desired external behavior of the
software system to be built

Some Important Definitions

1) User Requirement:-
. User requirement is the high-level abstract requirement.
It is the statement written in natural language plus diagram. It is written for the
customer understanding. 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. In the domain of user requirements
includes descriptions of product attributes or characteristics that are important to
user satisfaction.

3
2) System Requirement:-
. System Requirement is the more detailed description
of the software systems function, services and operational constraints written for
developers of the system. It is the detail description of functional or non-functional
requirement. .
. OR
System requirements describe System requirements describe the requirements for a
product that is composed of multiple components.

System requirement are classified into functional and non-functional requirements

3) Functional Requirement:-
. The functional requirements of 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.
These are the Requirements that the end user specifically demands as basic facilities that
the system should provide.

4) Non-Functional Requirement:-
. 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 is the Requirements that are specify how
the system should behave in a specific environment. It is the quality attributes of a
system.
Non-functional Requirements are often more critical than the individual 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 .
4
 Organizational
These requirements are broad system requirement derived from
policies and procedure in the customer and development organization
 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
• 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
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

5
 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.
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.
6
 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

1. Feasibility Study:-
A feasibility study is an assessment of the practicality of a proposed plan or
project. The main purpose of the feasibility study is to check the given requirement are the
given software is possible or not on the technical, economical and Operational feasibilities.

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.

7
 The requirement elicitation and analysis processes

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 are
also discovered during this activity. .
2. Requirements classification and organization:-
In the activity, groups related
requirements and organizes them into coherent clusters. .
3. Requirements prioritization and negotiation:-
This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts through
negotiation.
4. Requirements documentation:- The requirements are documented and input into
the next round of the spiral.

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 .
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.
8
Another diagram of requirement engineering processes

Spiral Model of requirement engineering processes

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

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

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.

11
 Requirement specification and documentation
“Requirement specification is the process of writing down the user and system
requirement in 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
 Consistency
 Modifiability
 Verifiability
 Design Independence
 Testability
 Understandable by customers
 Etc.

Scope of Good SRS

 Used in design implementation
 Used in project monitoring
12
  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

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

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

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

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

16
 Introduction to Management
The management of the requirements engineering process is similar to the management of
any other endeavor. We need the Requirement management 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.
It involves communication between the project team members and stakeholders, and
adjustment to requirements changes throughout the 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.
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
Requirement Attributes:
Requirement Attributes are properties of a requirement. Attributes can be used to filter or
sort the requirements. Lists of possible attributes are as below:

17
  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:

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

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

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.

19
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
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:

20
  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

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

21
 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
 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.
22
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

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.

23
 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

SYSTEM ENGINEERING
System engineering is a field of engineering and engineering management that focus on how to
design, integrate and manage complex system over their life cycle. It ensures that all aspects of
system are considered and integrated into a whole.
System is a group of interrelated entities form a unified whole. A system is surrounded by its
environment, described by its boundaries and structure and purpose by its functioning.

24