ABBOTTABAD UNIVERSITY OF SCIENCE AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

NAME: ZURGHUNA GUL

ROLL NO: 13646

COURSE: SOFTWARE REQUIREMENT ENG

ASSIGNMENT:1

SUBMITTED TO: SIR JAMAL

SUBMISSION DATE: 3RD JUNE 2024

QUESTION:1

What factors help software developers to make the choice of using the following process

model for their projects?

1. Waterfall model

2. Spiral model

3. Agile based process model

 WATERFALL MODEL
The waterfall model is a linear, sequential approach that progresses strictly top down It
follows a structured flow, where each phase of the development cycle must be completed
before progressing to the next. This model is ideal for projects with well-defined and stable
requirements.

KEY BENEFITS
 One of the key benefits of the waterfall model is its simplicity. The linear nature of the
process makes it easy to understand and implement.
 Clear documentation and well-defined milestones make managing and tracking progress
easier.

LIMITATIONS
 However, the waterfall model has its limitations. Since it follows a strict sequence, any
changes or modifications to the requirements can be challenging to accommodate.
 The lack of flexibility can lead to delays and increased costs if changes are required later
in the development cycle.

SPIRAL MODEL
 The spiral model is a systems development lifecycle (SDLC) method used for risk
management that combines the iterative development process model with elements of
the Waterfall model
 . The spiral model is used by software engineers and is favored for large, expensive and
complicated projects.
 projects in which frequent releases are necessary;
 projects in which changes may be required at any time;
 long term projects that are not feasible due to altered economic priorities;
 medium to high risk projects;
 projects in which cost and risk analysis is important;
 projects that would benefit from the creation of a prototype; and
 projects with unclear or complex requirements.

KEY BENIFITS
 Flexibility - Changes made to the requirements after development has started can be
easily adopted and incorporated.
 Risk handling - The spiral model involves risk analysis and handling in every phase,
improving security and the chances of avoiding attacks and breakages. The iterative
development process also facilitates risk management.
 Customer satisfaction - The spiral model facilitates customer feedback. If the software is
being designed for a customer, then the customer will be able to see and evaluate their
product in every phase. This allows them to voice dissatisfactions or make changes before
the product is fully built, saving the development team time and money

LIMITATIONS
 High cost - The spiral model is expensive and, therefore, is not suitable for small projects.
 Dependence on risk analysis - Since successful completion of the project depends on
effective risk handling, then it is necessary for involved personnel to have expertise in
risk assessment.
 Complexity - The spiral model is more complex than other SDLC options. For it to
operate efficiently, protocols must be followed closely. Furthermore, there is increased
documentation since the model involves intermediate phases.
 Hard to manage time - Going into the project, the number of required phases is often
unknown, making time management almost impossible. Therefore, there is always a risk
for falling behind schedule or going over budget.
 AGILE MODEL
 The agile model, on the other hand, emphasizes flexibility and adaptive planning. It
promotes iterative development, allowing teams to deliver working software in frequent,
short iterations.
 This model is well-suited for projects with changing requirements and a need for quick
responses to customer feedback.

KEY BENEFITS
 One of the key principles of the agile model is collaboration. The development team
works closely with the stakeholders, constantly seeking feedback and incorporating it into
the development process.
 This iterative approach allows continuous improvement and ensures that the final product
meets customer expectations.
 However, the agile model also has its challenges. The emphasis on flexibility and
frequent iterations can sometimes lead to scope creep, where the project expands beyond
its original boundaries.
 Additionally, the lack of a strict plan can make it difficult to accurately estimate project
timelines and costs.

CHOOSING THE RIGHT SOFTWARE

MODEL FOR PROJECT
Selecting a project management methodology for software development life cycle (SDLC) is
a critical decision that can affect the success of your project. Different methodologies have
different strengths, weaknesses, and suitability for different types of projects, teams, and
customers. Some of the most important factors to consider when choosing a project
management methodology for SDLC, such as project scope, complexity, uncertainty,
flexibility, collaboration, and delivery

FACTORS TO CONSIDER
When selecting a software process model for a project, several factors must be taken into
account:

 Project scope
 Project complexity
 Project uncertainty
 Project flexibility
 Project collaboration
 Project delivery

PROJECT SCOPE
One of the first factors to consider is the scope of your project, which defines the goals,
requirements, deliverables, and boundaries of your project. Depending on the scope, you may
need a more or less formal and detailed methodology to plan, execute, monitor, and control
your project.

For example

If your project has a clear and stable scope, you may benefit from a traditional methodology,
such as waterfall, that follows a sequential and linear process of phases. However, if your
project has a vague or changing scope, you may prefer an agile methodology, such as scrum,
that allows for frequent and iterative feedback and adjustments.

PROJECT COMPLEXITY
Another factor to consider is the complexity of your project, which refers to the number and
interdependence of variables, tasks, resources, and stakeholders involved in your project.
Depending on the complexity, you may need a more or less structured and standardized
methodology to manage the risks, dependencies, and quality of your project.
For example

If your project has a low or moderate complexity, you may use a simple and flexible
methodology, such as kanban, that focuses on visualizing and optimizing the workflow of
tasks. However, if your project has a high or very high complexity, you may need a more
robust and rigorous methodology, such as critical path method (CPM), that helps you identify
and prioritize the critical activities and milestones of your project.

PROJECT UNCERTAINTY
A third factor to consider is the uncertainty of your project, which measures the degree of
unpredictability and variability of your project environment, assumptions, and outcomes.
Depending on the uncertainty, you may need a more or less adaptive and responsive
methodology to cope with the changes, issues, and opportunities of your project.

For example

If your project has a low or moderate uncertainty, you may adopt a plan-driven methodology,
such as PRINCE2, that relies on a predefined and controlled framework of processes, roles,
and documents. However, if your project has a high or very high uncertainty, you may
embrace a value-driven methodology, such as lean software development, that emphasizes
the delivery of customer value and the elimination of waste.

PROJECT FLEXIBILITY
A fourth factor to consider is the flexibility of your project, which indicates the level of
freedom and creativity that you and your team have in defining and delivering your project
solutions. Depending on the flexibility, you may need a more or less prescriptive and
innovative methodology to guide and inspire your project work.

For example

If your project has a low or moderate flexibility, you may follow a conventional
methodology, such as spiral, that incorporates incremental and iterative development cycles
with risk analysis and evaluation. However, if your project has a high or very high flexibility,
you may experiment with a radical methodology, such as extreme programming (XP), that
promotes extreme practices, such as pair programming, test-driven development, and
continuous integration.

PROJECT COLLABORATION
A fifth factor to consider is the collaboration of your project, which reflects the extent and
quality of communication, coordination, and cooperation among your project team members
and stakeholders. Depending on the collaboration, you may need a more or less participatory
and collaborative methodology to facilitate and enhance your project interactions.

For example

If your project has a low or moderate collaboration, you may use a hierarchical methodology,
such as RUP, that defines a clear and formal structure of roles, responsibilities, and artifacts.
However, if your project has a high or very high collaboration, you may apply a democratic
methodology, such as agile manifesto, that values individuals and interactions over processes
and tools.

PROJECT DELIVERY
A sixth and final factor to consider is the delivery of your project, which describes the
frequency, format, and feedback of your project outputs and outcomes. Depending on the
delivery, you may need a more or less incremental and iterative methodology to produce and
present your project results.

For example

If your project has a low or moderate delivery, you may choose a phased methodology, such
as PMBOK, that divides your project into discrete and sequential stages with specific
deliverables and reviews. However, if your project has a high or very high delivery, you may
opt for a continuous methodology, such as DevOps, that integrates development and
operations into a continuous and collaborative process of delivery and improvement
Q3: Discover ambiguities or omissions in the following statement of requirements for part of
ticket-issuing systems:

An automated ticket-issuing system sells rail tickets.Users select their destination and input a
credit card and a personal identification number.The rail ticket is issued and their credit card
account charged.When the user presses the start button, a menu display of potential
destination is activated,along with a message to the user to select a destination.Once a
destination has been selected,users are requested to input their credit card.Its validity is
checked and the user is then requested to input a personal identifier.When the credit
transaction has been validated,the ticket is issued.

AMBIGUITIES ARISES IN REQUIREMENTS FOR PART OF

TICKET-ISSUING SYSTEM ARE FOLLOWING

 User Interface:

The statement does not specify the type of user interface used in the automated ticket-issuing
system. It is unclear whether it is a physical interface with buttons and a display or a digital
interface on a computer or mobile device.

 Destination Selection:

The statement does not provide details on how users can select their destination. It does not
mention whether there is a list of destinations displayed on the screen or if users need to input
the destination manually.

 Credit Card Input:

The statement does not specify how users input their credit card information. It does not
mention whether there is a physical card reader or if users need to manually enter the credit
card number.

 Credit Card Validation:

The statement does not explain how the validity of the credit card is checked. It does not
mention whether it is done through an external payment gateway or if there are specific
validation rules implemented in the system.

 Personal Identifier:

The statement does not provide details on what constitutes a personal identifier. It does not
specify whether it is a password, PIN, or any other form of identification.

 Ticket Issuance:

The statement does not mention how the ticket is issued to the user. It does not specify
whether it is printed on paper or if it is a digital ticket sent to the user's email or mobile
device.

 Error Handling:

The statement does not address how errors or exceptions are handled in the system. It does
not mention what happens if there is an invalid destination selection, credit card error, or
personal identifier mismatch.

 Transaction Confirmation:

The statement does not specify how users are notified about the successful completion of the
transaction. It does not mention whether there is a confirmation message displayed on the
screen or if a receipt is provided.

To ensure a comprehensive and accurate understanding of the requirements, these

ambiguities and omissions should be clarified and addressed in the system's design and
implementation.

Q2: Differentiate between functional and non functional requirements with relevant examples.

FUNCTIONAL VS NON FUNCTIONAL

REQUIREMENTS
Requirements analysis is a very critical process that enables the success of a system or
software project to be assessed. Requirements are generally split into two types: Functional
and Non-functional requirements

FUNCTIONAL REQUIREMENTS
These are the requirements that the end user specifically demands as basic facilities that the
system should offer. All these functionalities need to be necessarily incorporated into the
system as a part of the contract.
These are represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are the requirements stated by the user which one
can see directly in the final product, unlike the non-functional requirements.

Example:
 What are the features that we need to design for this system?
 What are the edge cases we need to consider, if any, in our design?

NON-FUNCTIONAL REQUIREMENTS
These are the quality constraints that the system must satisfy according to the project
contract. The priority or extent to which these factors are implemented varies from one
project to another. They are also called non-behavioral requirements. They deal with issues
like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility

Example:
  Each request should be processed with the minimum latency?
 System should be highly valuable.

Difference between Functional Requirements and Non-

Functional Requirements

Functional Requirements Non Functional Requirements

A functional requirement defines a system A non-functional requirement defines the
or its component. quality attribute of a software system.
It specifies “What should the software It places constraints on “How should the
system do?” software system fulfill the functional
requirements?”
Functional requirement is specified by User. Non-functional requirement is specified by
technical peoples e.g. Architect, Technical
leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the
software. software.
Functional Testing like System, Integration, Non-Functional Testing like Performance,
End to End, API testing, etc are done. Stress, Usability, Security testing, etc are
done.
Usually easy to define. Usually more difficult to define.
Example Example
1) Authentication of user whenever he/she 1) Emails should be sent with a latency of no
logs into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber 2) The processing of each request should be
attack. done within 10 seconds
3) A Verification email is sent to user 3) The site should load in 3 seconds when
whenever he/she registers for the first time the number of simultaneous users are >
on some software system. 10000