Task 7.

4D
Name: Ansh Taneja
Student ID:2310994764

1. Observation based on the uncertainty of requirements for

LC’s case study
The uncertainty of requirements is a critical factor influencing the selection of a
suitable life cycle for the project. These requirements can be further categorized
into functional, non-functional, and business requirements
1.1 Functional Requirements:
Functional requirements define what the system should do and encompass the
specific features, functions, and capabilities that the system must provide to
fulfill its intended purpose. In the case of LC, functional requirements could
include:
• Online order submission functionality
• Customer profiling and purchase history tracking
• Loyalty program management
• Inventory management and tracking
• Marketing campaign management tools

1.2 Non-Functional Requirements:

Non-functional requirements specify the quality attributes or constraints that the
system must meet, often related to performance, security, usability, and
reliability. Examples of non-functional requirements for LC's system might
include:
• Response time for order processing
• Security measures for protecting customer data
• Usability and user interface design standards
• Reliability and availability of the system

1.3 Business Requirements:

Business requirements outline the broader goals, objectives, and constraints that
drive the project from a business perspective. These requirements focus on
achieving specific business outcomes and may include factors such as:
• Increasing online sales revenue
• Improving customer satisfaction and retention rates
• Streamlining internal processes and workflows
• Enhancing competitive advantage in the market

The uncertainty surrounding these requirements stems from various factors such
as the subjective nature of current operations, differing perspectives among
stakeholders, and the lack of clarity on how the proposed system will impact
existing workflows. This uncertainty makes it challenging to fully define and
prioritize requirements upfront, as they are likely to evolve as stakeholders gain
a better understanding of their needs and the system's capabilities

2. Observation based on process uncertainty, company’s

expectations and their impact on requirement change for
LC’s case study for selection of a life cycle of the project

2.1 Process Uncertainty

LC's current manual operations and lack of clarity on how the proposed system
will integrate with existing processes introduce significant process uncertainty.
The subjective views and distinct perspectives among departments further
contribute to the uncertainty, making it challenging to define requirements
definitively. There may be resistance to change, varying levels of technological
expertise among employees, and uncertainty about how the new system will
affect daily workflows.

2.2 Company's Expectations:

LC likely has specific expectations for the new system, driven by strategic goals
such as increasing efficiency, improving customer satisfaction, or streamlining
internal processes. Expectations may include desired functionalities,
performance standards, timeline, budget, and post-implementation support
requirements. LC's expectations may evolve as stakeholders gain a better
understanding of their needs and the system's capabilities throughout the
project.

2.3 Impact on Requirement Change:

The impact of process uncertainty and evolving company expectations on

requirement changes throughout the project lifecycle can be observed across
functional, non-functional, and business requirements:
2.3.1 Functional Requirements:
• Process Uncertainty: Process uncertainty may lead to ambiguity in
defining functional requirements initially. Departments with manual
operations may have varying perspectives on how the new system should
function, contributing to uncertainty.
• Evolving Company Expectations: As stakeholders gain clarity on their
needs and the system's capabilities, they may identify new functional
requirements that were not initially considered. For example, stakeholders
may realize the need for additional features or functionalities to better
streamline their processes.

2.3.2 Non-Functional Requirements:

• Process Uncertainty: Process uncertainty can also impact the definition
of non-functional requirements, such as performance, security, usability,
and reliability. Without a clear understanding of how the new system will
integrate with existing processes, it may be challenging to specify these
requirements accurately.
• Feedback-driven Changes: Feedback from stakeholders during the
development process, particularly regarding usability and performance
issues encountered with prototypes, may prompt changes in non-
functional requirements. Stakeholders may request improvements to user
interface design or enhancements to system performance based on their
experiences.

2.3.3 Business Requirements:

Process Uncertainty: Process uncertainty can impact the identification and
prioritization of business requirements, such as increasing revenue, improving
customer satisfaction, or streamlining internal processes. Without a clear
understanding of how the new system will affect existing workflows, it may be
challenging to define these requirements definitively
Feedback-driven Changes: Feedback from stakeholders on prototypes or early
versions of the software may prompt changes in business requirements.
Stakeholders may identify new opportunities or challenges based on their
experiences with the system, leading to adjustments in strategic goals or
business priorities.

3. Selection of Life Cycle:

Considering the requirement and process uncertainties, as well as the

capabilities and risks involved, an Agile software development approach
appears to be the most suitable for LC's case study. Agile methodologies,
such as Scrum, emphasize iterative development, close collaboration with
stakeholders, and the ability to adapt to changing requirements. Given the
subjective nature of requirements and the need for frequent feedback loops
to refine them, Agile's flexibility and responsiveness make it well-suited for
this project. It allows LC to incrementally implement features, gather
feedback, and make adjustments accordingly, reducing the risk of delivering
a solution that does not meet stakeholders' expectations.

3.1 Predictive Lifecycle:

A predictive approach, often associated with traditional Waterfall or V-
model methodologies, follows a sequential process where requirements are
gathered upfront, followed by design, implementation, testing, and
deployment phases.
https://lucid.app/lucidchart/a8a815b5-6f7f-4fe4-a345-
d8a78b815e36/edit?viewport_loc=-159%2C-
28%2C1707%2C917%2C0_0&invitationId=inv_759291ea-11ba-4d57-
bcd8-1f1d244438ee
Requirements Gathering: In a predictive lifecycle, requirements are
gathered upfront based on initial analysis. This phase involves documenting
all requirements as comprehensively as possible.
Design: Once requirements are finalized, the design phase begins, where the
system architecture and detailed design specifications are created based on
the gathered requirements.
Implementation: With the design in place, development teams start coding
the software according to the predefined specifications.
Testing: After development, the system undergoes testing to ensure it meets
the documented requirements and functions correctly.
Deployment: Once testing is complete, the system is deployed to production
and made available to users.
Advantages:
Provides a clear roadmap and timeline for the project. Well-defined
requirements and milestones.
Risks:
Susceptible to changes in requirements, which may lead to costly rework.
Limited flexibility to adapt to changing business needs or stakeholder
feedback.
Capabilities:
Well-suited for projects with stable and clearly defined requirements.
Requires less involvement from stakeholders during development phases.

3.2 Adaptive Lifecycle:

An adaptive approach, such as Agile methodologies (e.g., Scrum),
emphasizes iterative development, continuous stakeholder involvement, and
flexibility to accommodate changes.

https://lucid.app/lucidchart/d19d8b6d-ae3d-42a5-986e-
4a96e76fc2ca/edit?viewport_loc=-621%2C-
161%2C2048%2C1101%2C0_0&invitationId=inv_d936f2a6-6364-4928-
9320-c87717e4dc9b

3.3 Advantages:
Flexibility to accommodate requirement changes and uncertainties. Close
collaboration with stakeholders promotes alignment and ensures the
delivered solution meets their needs.
3.4 Risks:
Requires active involvement and commitment from stakeholders throughout
the project. May require a cultural shift within the organization to embrace
iterative development practices.
3.5 Capabilities:
Well-suited for projects with evolving or uncertain requirements. Promotes
transparency, adaptability, and responsiveness to stakeholder needs.
4. The second most appropriate life cycle for LC’s case study
4.1 Iterative Life Cycle Model:
The Iterative Life Cycle Model is a software development approach where
the project is divided into small increments or iterations. Each iteration goes
through the phases of planning, analysis, design, implementation, testing,
and evaluation.
4.2 Structured Approach:
Structured Iterations: The Iterative model breaks the project into
manageable iterations, each of which follows a structured sequence of
phases (e.g., planning, analysis, design, implementation, testing).
Balanced Structure: While not as flexible as Agile, the Iterative model still
offers a structured approach to development, providing a framework for
iterative improvements while ensuring some level of predictability.

https://lucid.app/lucidchart/867c37b9-283c-46c2-87d5-
b12c2398fd38/edit?viewport_loc=18%2C200%2C1877%2C1009%2C0_0&i
nvitationId=inv_63090a71-6a95-4609-85e2-6729238c4e97

Incremental Development and Stakeholder Feedback:

Similarity to Agile: The Iterative Life Cycle model shares similarities with
Agile methodologies in terms of enabling incremental development and
providing opportunities for stakeholder feedback and requirement
refinement.
Iterative Improvements: LC can utilize each iteration to make incremental
improvements to the software, incorporating feedback from stakeholders to
refine requirements and enhance the product over time.
Risks and Limitations:
Less Flexibility than Agile: The Iterative model may not offer the same
degree of flexibility and adaptability as Agile, potentially limiting LC's
ability to respond rapidly to changing market conditions or stakeholder
needs.
Potential for Overhead: Each iteration in the Iterative model requires
overhead for planning, analysis, design, implementation, and testing, which
may result in longer development cycles compared to Agile.

5. Least Suitable SDLC Model:

5.1 Waterfall model:
In the waterfall model, the SDLC phases are completed in sequence to
progress toward a complete system. It is considered the traditional
methodology due to its position as an early academic model of software
 system creation. Variations of the model have since been explored, creating
the adaptive lifecycles that we will look at next.
In the waterfall model, each phase addresses a specific aspect of software
system’s development and the phases are completed in sequence. The sequence
is crucial since a phase can’t commence until certain activities from the
previous phase are completed.

The least suitable SDLC model for LC's case study would be the Waterfall
model. This model follows a linear sequential approach, with distinct phases for
requirements gathering, design, implementation, testing, and deployment.
However, given the uncertainty surrounding requirements and the likelihood of
changes during development, the rigid nature of the Waterfall model makes it
ill-suited for this project. It lacks the flexibility to accommodate evolving needs
and does not provide mechanisms for frequent stakeholder involvement or
iterative refinement, increasing the risk of delivering a solution that does not
align with LC's evolving business needs.

5.2 Advantages:
Clear Structure: The Waterfall model provides a clear and structured approach
to software development, with distinct phases that follow a linear progression.
Comprehensive Documentation: Each phase of the Waterfall model produces
comprehensive documentation, facilitating better understanding and
communication among team members and stakeholders.
Predictability: The Waterfall model offers predictability in terms of project
scope, schedule, and budget, as everything is planned upfront before
development begins.
Well-suited for Stable Requirements: Best suited for projects with well-
defined and stable requirements, where changes are minimal or unlikely to
occur.
Quality Assurance: The Waterfall model includes a dedicated testing phase at
the end of the development cycle, ensuring thorough testing and quality
assurance before deployment.
5.3 Disadvantages:
Limited Flexibility: The rigid nature of the Waterfall model makes it
challenging to accommodate changes once the project has started, increasing the
risk of delivering a solution that does not meet stakeholders' evolving needs.
Late Feedback: Stakeholder feedback is typically collected at later stages in the
Waterfall model, increasing the risk of discovering issues late in the
development process when they are more costly to address.

Uncertain Outcomes: Changes in requirements or market conditions may not

be adequately addressed within the structured framework of the Waterfall
model, leading to uncertainty regarding the final outcome.
Risk of Overruns: Any deviation from the initial plan can lead to budget and
schedule overruns, as adjustments are not easily accommodated within the
structured framework.
Limited Stakeholder Involvement: The Waterfall model does not provide
mechanisms for frequent stakeholder involvement or iterative refinement,
potentially leading to misunderstandings or misalignment between the final
product and stakeholders' expectations.

5.4 Risks:
Requirement Volatility: In a rapidly changing environment like LC's, where
requirements are subject to change, the Waterfall model's inability to adapt to
evolving needs increases the risk of delivering a solution that does not align
with LC's evolving business needs.
Late Discovery of Issues: Since stakeholder feedback is collected at later
stages, there is a higher risk of discovering issues late in the development
process, when they are more costly and challenging to address.
Limited Adaptability: The Waterfall model's lack of adaptability hinders its
ability to respond to changes in requirements or market conditions, increasing
the risk of project failure or dissatisfaction among stakeholders.