Software Engineering
FYBCA 2025-26 Part-I
UNIT - II
INDEX
1.
Software Requirement Engineering:
1.
2.
3.
4.
5.
6.
7.
2.
Functional and non-functional requirements
The Software requirements document
Requirement specification
Requirements engineering process
Requirement elicitation and analysis
Requirements validation
Requirements management
Risk management:
1.
2.
3.
4.
5.
6.
Reactive Vs proactive risk strategies
Software risks
Risk identification
Risk projection
Risk refinement
RMMM, RMMM plan
Software Requirement Engineering
➢
Software requirement engineering is the process of understanding documenting and managing the needs
and expectation of stakeholders to define what a software system should do.
➢
It’s crucial initial phase in software development that bridges the gap between client needs and technical
solutions though activities like elicitation, analysis, specification, and validation.
➢
This process ensures that the final product is aligned with business goals, meets user expectations, and is
built efficiently.
Importance of Software Requirement Engineering
➢ Foundation for Success: It serves as the foundation for all subsequent development activities from design
and coding to testing and project planning.
➢ Avoids errors: A clear definition of requirements helps to prevent misunderstandings and costly errors or
scope creep later in the project.
➢ Aligns expectation: It ensures that developers, clients and other stakeholders share a common
understanding of the project goals and the final product.
➢ Improves efficiency: By properly defining requirements upfront, development teams can work more
efficiently and focus on building the right solution.
Software Requirement Engineering
Types of Software Requirements:
1.
functional Requirement
2.
Non-functional Requirement
3.
Domain Requirement
Functional Requirement
1.
Functional Requirement:
➢
Functional requirements describes what the software should do. They define the functions or features that
the system must have.
➢
Functional requirements are the requirements that the end user specifically demands as basic facilities the
system should offer.
➢
Functional requirements in software engineering are also called as functional specification.
➢
They focus on system behavior and functionality.
➢
It represent the features that can be directly observed and tested in the final product.
➢
Common examples include user authentication, data processing, search, payment handling and report
generation.
Functional Requirement
Characteristics of Functional Requirement:
➢
Describes inputs, outputs and data processing.
➢
Defines system behavior under specific conditions.
➢
Often represented using use cases or user stories.
➢
Must be testable and measurable.
Example:
➢
The system should allow users to log in using a username and password.
➢
The system should send an email notification after successful registration.
➢
The system should allow users to search for products by name or category.
➢
The system should generate monthly sales reports.
➢
The system should store and retrieve student records.
Non-Functional Requirement
2.
Non-Functional Requirement:
➢
Non-functional requirements (NFRs) define how a system should operate, focusing on performance,
reliability, and user experience rather than specific features.
➢
They ensure the system is efficient, secure, and maintainable over time.
➢
These are basically the quality constraints that the system must satisfy according to the project contract.
➢
Nonfunctional requirements, not related to the system functionality, rather define how the system should
perform.
➢
The priority or extent to which these factors are implemented varies from one project to other.
➢
They are also called non-behavioral requirements.
Non-Functional Requirement
Characteristics of Non-Functional Requirement:
➢
Concerned with quality attributes (performance, reliability, usability).
➢
Often measurable using metrics or benchmarks.
➢
Affects user satisfaction and system performance.
➢
Usually apply to the whole system, not just individual features.
Example:
➢
The website should load within 3 seconds.
➢
The system should handle up to 10,000 concurrent users.
➢
The application should be compatible with Windows, macOS, and Linux.
➢
The system should have 99.9% uptime availability.
➢
The system should encrypt all sensitive data.
Domain Requirement
3.
Domain Requirement:
➢
Domain requirements are specific to the domain or industry in which the software operates.
➢
They include terminology, rules, and standards relevant to that particular domain.
➢
Domain requirements are the requirements that are characteristic of a particular category or domain of
projects.
➢
Domain requirements can be functional or nonfunctional.
➢
Domain requirements engineering is a continuous process of proactively defining the requirements for all
foreseeable applications to be developed in the software product line.
➢
The basic functions that a system of a specific domain must necessarily exhibit come under this category.
Domain Requirement
Characteristics of Domain Requirement:
Domain-Specific:
➢ These requirements are unique to the field where the software is used.
➢ They cannot be reused across different domains easily.
(e.g., hospital software cannot use banking rules directly).
Derived from Domain Knowledge:
➢ Often gathered from domain experts, industry standards, or regulatory documents.
Influence Both Functional and Non-Functional Requirements:
➢ A domain rule may dictate specific functions (functional requirement) or performance/security
constraints (non-functional requirement).
Can Be Implicit or Hidden:
➢ Some domain rules are so obvious to domain experts that they might not explicitly mention them
during requirement gathering.
➢ This can lead to requirement gaps if developers are unfamiliar with the domain.
Domain Requirement
Example:
➢
Healthcare: The software must comply with HIPAA regulations for handling patient data.
➢
Finance: The system should adhere to GAAP standards for financial reporting.
➢
E-commerce: The software should support various payment gateways like PayPal, Stripe, and credit
cards.
Examples of Functional and Non-Functional Requirement
1. Online Banking System
Functional Requirements:
➢ Users should be able to log in with their username and password.
➢ Users should be able to check their account balance.
➢ Users should receive notifications after making a transaction.
Non-functional Requirements:
➢ The system should respond to user actions in less than 2 seconds.
➢ All transactions must be encrypted and comply with industry security standards.
➢ The system should be able to handle 100 million users with minimal downtime.
Examples of Functional and Non-Functional Requirement
2. Food Delivery App
Functional Requirements:
➢ Users can browse the menu and place an order.
➢ Users can make payments and track their orders in real time.
Non-functional Requirements:
➢ The app should load the restaurant menu in under 1 second.
➢ The system should support up to 50,000 concurrent orders during peak hours.
➢ The app should be easy to use for first-time users, with an intuitive interface.
Difference between Functional and Non-Functional Requirements
Aspect
Functional Requirements
Non-Functional Requirements
Definition
Define what the system should do
Define how the system should perform
Focus
Behavior and features
Quality and performance
Example
Login, registration, reports
Speed, reliability, usability
Test Type
Functional Testing
Performance, Security, Usability Testing
Scope
Specific features
Entire system
Expression
Described in use cases
Described in metrics or quality attributes
Other Common Types of Requirements
1.
User requirements:
➢
These requirements describe what the end-user wants from the software system.
➢
User requirements are usually expressed in natural language and are typically gathered through
interviews, surveys, or user feedback.
2.
System requirements:
➢
These requirements specify the technical characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces.
➢
System requirements are typically expressed in technical terms and are often used as a basis for system
design.
3.
Business requirements:
➢
These requirements describe the business goals and objectives that the software system is expected to
achieve.
➢
Business requirements are usually expressed in terms of revenue, market share, customer satisfaction, or
other business metrics.
Other Common Types of Requirements
4.
Regulatory requirements:
➢
These requirements specify the legal or regulatory standards that the software system must meet.
➢
Regulatory requirements may include data privacy, security, accessibility, or other legal compliance
requirements.
5.
Interface requirements:
➢
These requirements specify the interactions between the software system and external systems or
components, such as databases, web services, or other software applications.
6.
Design requirements:
➢
These requirements describe the technical design of the software system.
➢
They include information about the software architecture, data structures, algorithms, and other technical
aspects of the software.
The Software Requirement Document
➢
A Software Requirements Document (SRD) is a complete document or description of the requirements of
a system or software application.
➢
In other words, “SRD is a document that describes what the features of the software will be and
what its behavior will be, i.e. how it will perform.”
➢
It is prepared after the requirement analysis phase of the Software Development Life Cycle (SDLC).
➢
The advantage of SRD is that it takes less time and effort for developers to develop software.
➢
What SRD is like the layout of the software which the user can review and see whether it (SRD) is made
according to his needs or not.
➢
Software Requirement Document is also called as Software Requirements Specification (SRS), System
Requirement Specification (SysRS), Requirements Definition Document.
The Software Requirement Document
Purpose of Software Requirement Document:
➢
Define clear and complete requirements for the system.
➢
Serve as a contract between the client and the development team.
➢
Avoid misunderstandings during development.
➢
Provide a reference for design, coding, and testing.
➢
Facilitate maintenance and future upgrades.
Advantages of Software Requirement Document
Sr. No.
Aspects
Advantage
1.
Clear Understanding
Ensures both client and developers share the same understanding.
2.
Accurate Estimation
Helps estimate project cost, time, and resources.
3.
Design Foundation
Acts as a blueprint for design, coding, and testing.
4.
Reduces Errors
Minimizes missed or misunderstood requirements.
5.
Aids Testing
Provides clear, testable requirements.
6.
Eases Maintenance
Useful reference for future updates or fixes.
7.
Improves Communication
Serves as a common reference for all stakeholders.
8.
Supports Traceability
Links requirements to design, code, and tests.
9.
Ensures Consistency
Maintains standard and uniform documentation.
10.
Legal Reference
Serves as a formal, contractual agreement.
Dis-Advantages of Software Requirement Document
Sr. No.
Aspects
Dis-Advantage
1.
Time-Consuming
Requires significant time and effort to prepare.
2.
Becomes Outdated
Needs regular updates as requirements change.
3.
Hard to Capture All Needs
Some requirements are implicit or unclear.
4.
Possible Miscommunication
May still be misunderstood if unclear.
5.
Overhead for Small Projects
Too detailed for simple or short projects.
6.
Less Flexible
Not suitable for rapidly changing agile projects.
7.
Complex for Large Systems
Can be long and difficult to manage.
8.
Needs Skilled Analysts
Poorly written SRD can cause confusion.
Characteristics of Software Requirement Document
Sr. No.
Characteristic
Description
1.
Correct
Accurately describes the system’s intended functionality
2.
Complete
Includes all significant requirements
3.
Unambiguous
Clear and understandable to all stakeholders
4.
Verifiable
Each requirement can be tested or validated
5.
Consistent
No conflicts or contradictions between requirements
6.
Modifiable
Easy to update and maintain
7.
Traceable
Each requirement is linked to its source or objective
Structure of a Software Requirement Document:
1.
Introduction
➢
Describes the purpose, scope, and overview of the document and the system.
Includes:
➢ Purpose: Why the SRD is written and who will use it.
➢ Scope: What the software will do and what it will not do.
➢ Definitions, Acronyms, and Abbreviations: Clarifies all terms used.
➢ References: Lists related documents, manuals, or standards.
➢ Overview: Explains how the document is organized.
2.
Overall Description
➢
Provides a general view of the system and its environment before going into detailed requirements.
Includes:
➢ Product Perspective: Relation of this system to other systems.
➢ Product Functions: Summary of major features or functions.
➢ User Characteristics: Describes the types of users (admin, customer, etc.).
➢ Constraints: Hardware, software, or regulatory limitations.
➢ Assumptions and Dependencies: Any external factors the system depends on.
3.
Functional Requirements
➢
Specifies what the system must do — its functions, operations, and features.
Includes:
➢ Inputs, processing, and outputs.
➢ System behavior for different situations.
➢ Use cases or user stories.
4.
Non-Functional Requirements
➢
Defines how well the system performs — quality attributes and performance criteria.
Includes:
➢ Performance: Response time, throughput.
➢ Security: Access control, data encryption.
➢ Usability: User interface design and ease of use.
➢ Reliability and Availability: Fault tolerance, backup requirements.
➢ Portability: Supported platforms.
➢ Maintainability: Ease of updates and modifications.
5.
Domain Requirements
➢
Specifies rules, constraints, or laws specific to the domain or industry.
6.
External Interface Requirements
➢
Describes how the system interacts with external components or users.
Types:
➢ User Interface (UI): Layouts, menus, forms, navigation flow.
➢ Hardware Interface: Sensors, printers, or scanners.
➢ Software Interface: APIs, libraries, or databases used.
➢ Communication Interface: Network protocols or message formats.
7.
System Features
➢
Breaks down the system’s key features into detailed subsections.
Each feature should include:
➢ Description and purpose
➢ Inputs and outputs
➢ Preconditions and postconditions
➢ Normal and alternate workflows
8.
Other Requirements
➢
Covers any additional requirements not mentioned earlier.
Includes:
➢ Safety requirements (e.g., emergency data backup).
➢ Quality attributes (performance standards).
➢ Database requirements (storage capacity, type).
➢ Legal requirements (data protection laws).
9.
Appendices
➢
Provides supporting information to help understand the document.
Includes:
➢ Glossary of terms
➢ Sample data formats
➢ References or diagrams
➢ Revision history
10. Index
➢
Alphabetical listing of terms, features, or sections for quick reference.
Requirement Engineering Process
➢
Requirements Engineering is the process of identifying, eliciting, analyzing, specifying, validating, and
managing the needs and expectations of stakeholders for a software system.
➢
A systematic and strict approach to the definition, creation, and verification of requirements for a
software system is known as requirements engineering.
➢
To guarantee the effective creation of a software product, the requirements engineering process entails
several tasks that help in understanding, recording, and managing the demands of stakeholders.
➢
It focuses on what the system should do rather than how it will do it.
Requirements Engineering Process:
1.
Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below.
➢
Technical Feasibility:
Assesses whether the current hardware, software, and technologies are adequate for project development.
It also evaluates the technical skills of the team, ease of maintenance and upgradation, and availability of
required tools.
➢
Operational Feasibility:
Examines how effectively the proposed system will meet user requirements and how easy it will be to
operate and maintain after deployment. It also checks whether the suggested solution is acceptable to
users.
➢
Economic Feasibility:
Analyzes the costs and financial benefits of the project. It includes estimating development, resource, and
operational costs and determines if the project is financially viable for the organization.
➢
Legal Feasibility:
Ensures the project complies with laws, regulations, and standards. It reviews contracts, intellectual
property rights, and other legal constraints that may impact project development.
➢
Schedule Feasibility:
Evaluates whether the project timeline and deadlines are realistic. It identifies major milestones, checks
resource availability, and ensures the project can be completed on time.
2.
Requirements Elicitation
➢
Requirements elicitation is the process of gathering information from stakeholders to understand their
needs and expectations for a software system.
➢
It involves gaining domain knowledge from sources like customers, business manuals, existing systems,
and standards.
➢
Common techniques include interviews, brainstorming, task analysis, the Delphi technique, and
prototyping.
➢
This step helps analysts understand the problem and user requirements, providing input for the next stage
of software development.
Several techniques can be used to elicit requirements:
1.
Interviews:
➢
2.
Surveys:
➢
3.
These are one-on-one conversations with stakeholders to gather information about their needs and expectations.
These are questionnaires that are distributed to stakeholders to gather information about their needs and
expectations.
Focus Groups:
➢
These are small groups of stakeholders who are brought together to discuss their needs and expectations for the
software system.
4.
Observation:
➢
5.
This technique involves observing the stakeholders in their work environment to gather information about
their needs and expectations.
Prototyping:
➢
This technique involves creating a working model of the software system, which can be used to gather
feedback from stakeholders and to validate requirements.
Steps of Requirements Elicitation:
Identify Stakeholders
➢ The first step is to figure out who all the key players are in the project. These are the people who will
either use the product, help develop it, or be impacted by it. This could include users, developers, project
managers, and customers.
Gather Requirements
➢ Once you've identified the stakeholders, the next step is to gather their requirements. This means
understanding what they need from the system or product.
Prioritize Requirements
➢ Not all requirements are equal in terms of importance. After gathering them, you’ll need to prioritize
which ones should be addressed first.
Categorize Feasibility
➢ Achievable: These are requirements that are realistic and can be done within the available resources (time,
budget, etc.).
➢ Deferred: These requirements are important but can’t be implemented in this phase. They’ll be put on hold for
now with a clear reason why.
➢ Impossible: These requirements can't be done because of technical or other limitations, and they should be
removed from the list.
3.
➢
➢
➢
➢
➢
Requirements Specification
Requirements Specification is the process of formally documenting functional, non-functional requirements,
and constraints in a clear and consistent way.
It may involve gathering additional information if needed. Common models used include ER diagrams, DFDs,
FDDs, and data dictionaries.
The goal is to create a comprehensive document (SRS) that is easily understood by both developers and
stakeholders.
To make the requirements specification clear, the requirements should be written in a natural language and use
simple terms, avoiding technical jargon, and using a consistent format throughout the document.
It is also important to use diagrams, models, and other visual aids to help communicate the requirements
effectively.
Types of requirements are commonly specified in this step, including:
1.
Functional Requirements:
➢
These describe what the software system should do. They specify the functionality that the system must
provide, such as input validation, data storage, and user interface.
2.
Non-Functional Requirements:
➢
These describe how well the software system should do it. They specify the quality attributes of the
system, such as performance, reliability, usability, and security.
3.
Constraints:
➢
These describe any limitations or restrictions that must be considered when developing the software
system.
4.
Acceptance Criteria:
➢
These describe the conditions that must be met for the software system to be considered complete and
ready for release.
4.
➢
Requirements Verification and Validation
Verification: It refers to the set of tasks that ensures that the software correctly implements a specific
function.
➢ Validation: It refers to a different set of tasks that ensures that the software that has been built is
traceable to customer requirements.
The main steps for this process include:
➢ The requirements should be consistent with all the other requirements i.e. no two requirements should conflict
with each other.
➢ The requirements should be complete in every sense.
➢ The requirements should be practically achievable.
➢
➢
➢
➢
Requirements verification and validation (V&V) is the process of checking that the requirements for a
software system are complete, consistent, and accurate and that they meet the needs and expectations of
the stakeholders.
Verification ensures that requirements are complete, consistent, clear, and error-free, through reviews,
walkthroughs, and document checks.
Validation ensures the requirements meet stakeholder needs using simulations, prototypes, or final
testing.
Both are iterative processes carried out throughout the software development life cycle with stakeholder
involvement.
5.
Requirements Management
➢
Requirements management is the process of tracking, analyzing, and controlling requirements throughout
the software development life cycle.
➢
It ensures requirements remain valid, clear, and aligned with project goals, allowing for controlled
changes
➢
This step helps deliver software that meets stakeholder needs on time, within budget, and with required
quality, while preventing scope creep.
Several key activities are involved in requirements management:
1.
Tracking and controlling changes:
➢
2.
Version control:
➢
3.
This involves monitoring and controlling changes to the requirements throughout the development process,
including identifying the source of the change, assessing the impact of the change, and approving or rejecting
the change.
This involves keeping track of different versions of the requirements document and other related artifacts.
Traceability:
➢
This involves linking the requirements to other elements of the development process, such as design, testing,
and validation.
4.
Communication:
➢
5.
This involves ensuring that the requirements are communicated effectively to all stakeholders and that any
changes or issues are addressed promptly.
Monitoring and reporting:
➢
This involves monitoring the progress of the development process and reporting on the status of the
requirements.
Advantages of Requirement Process:
➢ Clear Understanding of Requirements:
▪
➢
Improved Project Planning:
▪
➢
Early identification of requirements minimizes rework and system defects.
Enhanced Communication:
▪
➢
Well-defined requirements help in accurate cost, time, and resource estimation.
Reduced Development Errors:
▪
➢
Ensures that developers and stakeholders have a shared understanding of what the system should do.
Facilitates better communication between clients, users, and the development team.
Higher Quality Software:
▪
Leads to software that meets user needs and performs reliably in real-world scenarios.
Dis-Advantages of Requirement Process:
➢ Time-Consuming Process:
▪
➢
Changing Requirements:
▪
➢
Detailed requirement analysis may require significant upfront investment.
Complexity in Large Systems:
▪
➢
Frequent changes by stakeholders can complicate documentation and delay progress.
High Cost in Early Stages:
▪
➢
Gathering and analyzing requirements can take significant time, especially for large projects.
Managing and validating requirements in large-scale projects can be difficult.
Dependency on Stakeholder Input:
▪
Poor or unclear communication from stakeholders can lead to incomplete or incorrect requirements.
Stages in Software Engineering Process
1.
Elicitation:
➢
2.
Analysis:
➢
3.
In this stage, the requirements are documented in a clear, concise, and unambiguous manner. The aim is to
provide a detailed description of the requirements that can be understood by all stakeholders.
Validation:
➢
5.
In this stage, the requirements are analyzed to determine their feasibility, consistency, and completeness. The
aim is to identify any conflicts or contradictions in the requirements and resolve them.
Specification:
➢
4.
In this stage, the requirements are gathered from various stakeholders such as customers, users, and domain
experts. The aim is to identify the features and functionalities that the software system should provide.
In this stage, the requirements are reviewed and validated to ensure that they meet the needs of all stakeholders.
The aim is to ensure that the requirements are accurate, complete, and consistent.
Management:
➢
In this stage, the requirements are managed throughout the software development lifecycle. The aim is to ensure
that any changes or updates to the requirements are properly documented and communicated to all stakeholders.
Risk Management
➢
Risk Management is a systematic process of recognizing, evaluating, and handling threats or risks that
have an effect on the finances, capital, and overall operations of an organization.
➢
These risks can come from different areas, such as financial instability, legal issues, errors in strategic
planning, accidents, and natural disasters.
➢
It ensures that risks are detected early and handled effectively to minimize project failure and ensure
timely, quality delivery.
Types of Risks in Software Engineering:
1.
Project Risks:
➢
2.
Technical Risks:
➢
3.
Risks that affect project management and execution (e.g., schedule delays, budget overruns).
Example: Inaccurate time estimation or resource shortage.
Risks arising from technology or system performance.
Example: Use of untested tools or integration failures.
Business Risks:
➢
Risks that affect the organization or end-user satisfaction.
Example: Product not meeting customer needs.
Risk Management
4.
Operational Risks:
➢
5.
Risks related to maintenance, support, or deployment.
Example: Lack of skilled staff to maintain the system.
External Risks:
➢
Risks caused by external factors.
Example: Market changes, legal issues, or natural disasters.
The risk management process:
Risk management process consists of
➢ Risks Identification
➢ Risk Assessment
➢ Risks Planning
➢ Risk Monitoring
Risk Management
1.
Risk Identification
➢
➢
2.
Risk analysis
➢
➢
3.
Risk analysis is the process of evaluating and understanding the potential impact and likelihood of identified
risks on an organization.
It helps determine how serious a risk is and how to best manage or mitigate it. Risk Analysis involves
evaluating each risk's probability and potential consequences to prioritize and manage them effectively.
Risk Planning
➢
➢
4.
Risk identification refers to the system atic process of recognizing and evaluating potential threats or hazards
that could negatively impact an organization, its operations, or its workforce.
This involves identifying various types of risks, ranging from IT security threats like viruses and phishing
attacks to unforeseen events such as equipment failures and extreme weather conditions.
Risk planning involves developing strategies and actions to manage and mitigate identified risks effectively.
It outlines how to respond to potential risks, including prevention, mitigation, and contingency measures, to
protect the organization's objectives and assets.
Risk Monitoring
➢
➢
Risk monitoring involves continuously tracking and overseeing identified risks to assess their status, changes,
and effectiveness of mitigation strategies.
It ensures that risks are regularly reviewed and managed to maintain alignment with organizational objectives
and adapt to new developments or challenges.
Risk Management
Advantages of Software Engineering:
1.
Early Problem Detection:
➢
2.
Improved Project Planning:
➢
3.
Minimizes the chances of cost overruns, missed deadlines, or software defects.
Enhanced Decision-Making:
➢
5.
Enables better scheduling, budgeting, and resource allocation by anticipating challenges.
Reduced Project Failures:
➢
4.
Helps identify potential risks early in the project life cycle before they become major issues.
Provides data-driven insights for making informed and proactive project decisions.
Increased Stakeholder Confidence:
➢
Builds trust among clients and management by showing preparedness for uncertainties.
Risk Management
Dis-Advantages of Software Engineering:
1.
Time-Consuming Process:
➢
2.
High Initial Cost:
➢
3.
Managing numerous risks in big projects can become complicated and hard to track.
Unpredictable Factors:
➢
5.
Implementing a detailed risk management plan may require additional tools and resources.
Complexity in Large Projects:
➢
4.
Identifying, analyzing, and monitoring risks can take significant time and effort.
Not all risks can be foreseen—some external or sudden issues may still occur.
Resistance from Team Members:
➢
Some teams may consider risk management unnecessary or may not follow mitigation plans properly.
Reactive Vs Proactive Risk Strategies
Sr. No
Basis
Reactive Risk Strategy
Proactive Risk Strategy
1
Meaning
Actions are taken after the risk
occurs.
Actions are taken before the risk
occurs.
2
Approach
Corrective – focuses on solving
problems once they arise.
Preventive – focuses on identifying
and avoiding risks early.
3
Focus
Deals with damage control and
recovery.
Focuses on risk avoidance and
mitigation.
4
Planning
No detailed risk plan is created in
advance.
Detailed risk management plan is
prepared early.
5
Timing
Implemented after the problem
appears.
Implemented before the problem
occurs.
6
Cost
Impact
May lead to higher costs due to
emergency fixes.
Reduces costs by preventing major
issues.
7
Example
Fixing a server crash after it
happens.
Setting up backup servers to prevent
downtime.
8
Outcome
Often causes delays and stress.
Ensures smoother and more reliable
project execution.
Software Risks
➢
A software risk refers to the possibility of an undesirable event that can negatively affect the software
development process, product quality, budget, or schedule.
➢
Risk is uncertain events associated with future events that have a probability of occurrence but it may or
may not occur and if occurs it brings loss to the project.
➢
Risk identification and management are very important tasks during software project development
because the success and failure of any software project depend on it.
Risks in Software Development
1.
Schedule Risk :
➢
Schedule related risks refers to time related risks or project delivery related planning risks.
➢
The wrong schedule affects the project development and delivery.
➢
These risks are mainly indicating to running behind time as a result project development doesn't progress
timely and it directly impacts to delivery of project.
➢
Finally, if schedule risks are not managed properly, it gives rise to project failure and at last it affect to
organization/company economy very badly.
Software Risks
2.
Budget Risk:
➢
Budget related risks refers to the monetary risks mainly it occurs due to budget overruns.
➢
Always the financial aspect for the project should be managed as per decided but if financial aspect of
project mismanaged then their budget concerns will arise by giving rise to budget risks.
➢
So proper finance distribution and management are required for the success of project otherwise it may
lead to project failure.
3.
Operational Risk:
➢
Operational risk refers to the procedural risks means these are the risks which happen in day-to-day
operational activities during project development due to improper process implementation or some
external operational risks.
4.
Technical Risk:
➢
Technical risks refers to the functional risk or performance risk which means this technical risk mainly
associated with functionality of product or performance part of the software product.
Software Risks
5.
Programmatic Risk:
➢
Programmatic risks refers to the external risk or other unavoidable risks. These are the external risks
which are unavoidable in nature.
➢
These risks come from outside and it is out of control of programs.
Risks Identification
➢ Risk Identification is the process of finding, recognizing, and describing risks that may affect a software
project.
➢ By chance, if failure occurs in identifying any specific or particular risk, then all other steps that are
involved in risk management will not be implemented for that particular risk.
➢ For identifying risk, project team should review scope of program, estimate cost, schedule, technical
maturity, parameters of key performance, etc.
➢ Generally, identification of risk is an iterative process. It basically includes generating or creating
comprehensive list of threats and opportunities that are based on events that can enhance, prevent,
degrade, accelerate, or might delay successful achievement of objectives.
➢ There are many different types of risks which affects the software project:
1.
2.
3.
4.
5.
6.
Technology risks
Tools risks
Estimation risks
People risks
Requirement risks
Organizational risks
Risks Identification
Methods for Identifying Risks :
1.
Checklist Analysis :
➢
➢
➢
2.
Checklist Analysis is type of technique generally used to identify or find risks and manage it.
The checklist is basically developed by listing items, steps, or even tasks and is then further analyzed against
criteria to just identify and determine if procedure is completed correctly or not.
It is list of risk that is just found to occur regularly in development of software project. Below is the list of
software development risk by Barry Boehm- modified version.
Brainstorming :
➢
➢
➢
➢
➢
➢
This technique provides and gives free and open approach that usually encourages each and everyone on project
team to participate.
It also results in greater sense of ownership of project risk, and team generally committed to managing risk for
given time period of project.
It is creative and unique technique to gather risks spontaneously by team members.
The team members identify and determine risks in ‘no wrong answer’ environment.
This technique also provides opportunity for team members to always develop on each other’s ideas.
This technique is also used to determine best possible solution to problems and issue that arises and emerge.
Risks Identification
3.
Casual Mapping :
➢
➢
4.
SWOT Analysis :
➢
➢
➢
5.
Causal mapping is method that builds or develops on reflection and review of failure factors in cause and effect
of the diagrams.
It is very useful for facilitating learning with an organization or system simply as method of project-post
evaluation. It is also key tool for risk assessment.
Strengths-Weaknesses-Opportunities-Threat (SWOT) is very technique and helpful for identifying risks within
greater organization context.
It is generally used as planning tool for analyzing business, its resources, and also its environment simply by
looking at internal strengths and weaknesses and opportunities and threats in external environment.
It is technique often used in formulation of strategy. The appropriate time and effort should be spent on thinking
seriously about weaknesses and threats of organization for SWOT analysis to more effective and successful in
risk identification.
Flowchart Method :
➢
➢
This method allows for dynamic process to be diagrammatically represented in paper.
This method is generally used to represent activities of process graphically and sequentially to simply identify
the risk.
Risks Projection
➢ Risk projection in software engineering is a proactive process of estimating potential risks by assessing
both the likelihood of a risk occurring and the consequences if it does.
➢ The goal is to prioritize risks by rating them, which involves four main steps: establishing a probability
scale, describing the risk's potential consequences, estimating the overall impact on the project, and
maintaining the accuracy of the projection.
➢ This process helps in allocating resources to the most critical risks before they become major problems.
➢ Key components of risk projection:
➢ Probability assessment: Estimating the likelihood that a risk will actually occur, often on a defined
scale (e.g., low to high).
➢ Consequence assessment: Analyzing the potential negative effects and problems that would arise if
the risk materializes. This involves identifying which parts of the project would be affected and to
what degree.
➢ Impact estimation: Combining the probability and consequence assessments to estimate the overall
impact a risk could have on the project's budget, schedule, or product quality.
➢ Accuracy maintenance: Regularly reviewing and updating the risk projection to ensure it remains
accurate and relevant as the project progresses.
Risks Projection
Importance of Risks Projection :
➢ Proactive approach: It allows teams to address potential issues before they escalate, rather than
reacting to problems as they occur.
➢ Resource allocation: By prioritizing risks based on their potential impact, teams can focus their time
and resources on the most critical threats.
➢ Maximizes project success: It helps minimize uncertainties and increases the chances of a successful
project outcome.
➢ Risk prioritization: It makes it practical to consider risks from various sources (business, project,
product/technical) by focusing on the most influential ones.
Risks Refinement
➢ Risk refinement is a software engineering process where initial, high-level risks are analyzed in greater
detail to break them down into smaller, more manageable sub-risks.
➢ This helps in gaining a deeper understanding of the risk's causes and potential impacts, which then allows
for more accurate prioritization and the development of effective mitigation strategies.
➢ Risk refinement systematically examines each projected risk in greater detail. It moves beyond a general
understanding to pinpoint the specific factors that might cause a risk to materialize.
Purpose of Refinement:
➢ To identify root causes of a risk
➢ To break one major risk into sub-risks with clear triggers
➢ To make mitigation plans more precise and effective
➢ To avoid vague or generic risk handling
Risks Refinement
Purpose of Refinement:
➢ To identify root causes of a risk
➢ To break one major risk into sub-risks with clear triggers
➢ To make mitigation plans more precise and effective
➢ To avoid vague or generic risk handling
Benefits of Risks Refinement:
➢ Increased Specificity:
• It transforms broad, general risks into precise, actionable problems. This specificity makes risks much
easier to understand and manage.
➢ Improved Analysis:
• More detailed sub-risks allow for a more accurate and in-depth assessment of their individual
probabilities and potential impacts. This enhances the overall risk projection.
➢ Targeted Mitigation:
• It enables the creation of highly focused and effective mitigation strategies, as the specific underlying
causes of the risks are clearly understood. This means solutions are more likely to succeed.
Risks Refinement
➢ Better Monitoring:
• Refined risks are considerably easier to monitor, as specific indicators can be tracked for each
individual sub-risk. This provides clearer signals of potential issues.
➢ Enhanced Control:
• With a clearer and more comprehensive understanding of the nuances of each risk, project managers
can exercise better control over potential threats and make more timely interventions.
Advantages of Risks Refinement:
1.
Helps understand risks more clearly by breaking them into smaller parts.
2.
Makes probability and impact estimation more accurate.
3.
Allows targeted and effective mitigation plans for each sub-risk.
4.
Improves prioritization by identifying which sub-risks are most critical.
5.
Supports better decision-making and resource allocation in the project.
Risks Refinement
Dis-Advantages of Risks Refinement:
1.
Time-consuming process and adds extra analysis work.
2.
Requires skilled and experienced team members for accurate refinement.
3.
Can overcomplicate the risk management process if too detailed.
4.
Wrong assumptions lead to misleading sub-risks and poor mitigation.
5.
Increases documentation effort and needs continuous tracking.
Risks Refinement
Risks Refinement Involves:
1. Breaking down risks:
• A high-level risk is dissected into its constituent parts, making it easier to analyze and manage. For
example, a broad risk like "project delay" might be refined into more specific risks like "key
developer leaves unexpectedly" or "unexpected integration issues with a third-party component".
2.
Analyzing details:
•
Each refined risk is analyzed more deeply to clarify its specific likelihood, potential consequences,
and contributing factors.
3.
Prioritizing:
•
After refinement, the risks are ranked by severity, probability, and impact, allowing the team to focus
on the most critical issues first.
4.
Developing strategies:
•
The detailed understanding gained from refinement helps in creating more precise and effective
mitigation plans to manage the most significant risks.
RMMM and RMMM Plan
➢ RMMM in software engineering stands for Risk Mitigation, Monitoring, and Management.
➢ It is a systematic process to proactively identify, analyze, and handle risks in software projects to minimize
their negative impact and increase the likelihood of success.
Key components of RMMM:
➢ Risk Mitigation:
• This involves developing plans to reduce the probability or impact of potential risks. Examples
include cross-training team members to mitigate the risk of a key person leaving or conducting
frequent meetings with customers to prevent requirement changes.
➢ Risk Monitoring:
• This is the continuous tracking of identified risks and the effectiveness of mitigation strategies
throughout the project's lifecycle. It includes monitoring for changes in risk status and the emergence
of new risks.
➢ Risk Management:
• This is the overarching process of managing risks, which includes taking action when risks occur. It
involves implementing contingency plans and updating risk assessments as needed.
RMMM and RMMM Plan
RMMM Plan:
➢ A risk management technique is usually seen in the software Project plan. This can be divided into Risk
Mitigation, Monitoring, and Management Plan (RMMM).
➢ In this plan, all works are done as part of risk analysis. As part of the overall project plan project manager
generally uses this RMMM plan.
1.
Risk Mitigation :
➢ It is an activity used to avoid problems (Risk Avoidance).
➢ Steps for mitigating the risks as follows:
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
RMMM and RMMM Plan
2.
Risk Monitoring :
➢
It is an activity used for project tracking.
➢
It has the following primary objectives as follows:
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
3.
Risk Management and planning :
➢
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project manager
when risk becomes reality and causes severe problems.
➢
If the project manager effectively uses project mitigation to remove risks successfully then it is easier to
manage the risks. This shows that the response that will be taken for each risk by a manager. The main
objective of the risk management plan is the risk register. This risk register describes and focuses on the
predicted threats to a software project.