GROUP B

MAGOMBE PIUS 31673

GWADYA AHAMADA 30575
WASWAGA EMMANUEL 29376
HADENGHNO BADIRU 32649
TOMUSANGE FELIX 32013
KITUTU BRIAN 30506
ABDURAHMAN SHANTIL 31676
ATAGO ROSEMARY 31263
 Qn1:Identify the types of requirements.
which should be captured in a software project

In a software project, there are several types of requirements that

should be captured to ensure a successful outcome. These
requirements help guide the development process and ensure that
the final product meets the expectations of the stakeholders. Some
of the key types of requirements that should be captured include:
1. Functional requirements:
2. Non-functional requirements:
3. Technical requirements:
4. Business requirements:
5. Stakeholder requirements:
6. Constraint requirements:
7. Risk requirements:
 1. Functional requirements:
These are the primary features and capabilities of the
software that it must deliver to solve a problem or meet
a specific need. They describe what the software should
do and are usually documented in the form of use cases,
user stories, or detailed specifications.

2. Non-functional requirements:
These are the qualities or attributes of the software that
are not directly related to its functionality but are
important for the overall success of the project. Non-
functional requirements may include performance,
security, usability, scalability, maintainability, reliability,
and compliance with relevant regulations and standards.
 3. Technical requirements:
These are the specific technical constraints and considerations
that must be taken into account during the development process.
Technical requirements may include hardware and software
compatibility, integration with existing systems, API
specifications, data storage and retrieval, and the choice of
programming languages and tools.

4. Business requirements:
These are the high-level goals and objectives of the organization
that the software project aims to achieve. Business requirements
help to define the scope of the project and align it with the
strategic objectives of the organization. They may include cost
reduction, increased efficiency, improved customer satisfaction,
or market differentiation.
 5. Stakeholder requirements:
These are the needs and expectations of the various
stakeholders involved in the project, such as end-users,
customers, management, and regulatory authorities.
Stakeholder requirements help to ensure that the software
meets the needs of the people who will be using it and
contribute to its success.

6. Constraint requirements:
These are limitations or restrictions that the project must
adhere to, such as budget, time, or resource constraints.
Constraint requirements help to ensure that the project
remains feasible and within the bounds of what is
achievable.
 7. Risk requirements:
These are potential risks and uncertainties that may impact
the project or the software's success. Identifying and
addressing risk requirements helps to mitigate potential
issues and ensure a more predictable and successful
outcome for the project.

By capturing these different types of requirements,

software developers can create a comprehensive
understanding of the project's goals, objectives, and
constraints, leading to a more successful and effective
software product.
 Qn2:
Describe and apply different requirement analysis and specification techniques.

Requirement analysis and specification techniques are essential for

understanding and defining the needs of a software project. These
techniques help in gathering, analysing, and documenting the
requirements to ensure that the final product meets the
expectations of the stakeholders. Here are some common
requirement analysis and specification techniques:

1. Interviews:
2. Questionnaires:
3. Workshops:
4. Use Cases:
5. User Stories:
6. Data Flow Diagrams:
7. State Transition Diagrams:
8. Requirements Traceability Matrix:
 1. Interviews:
2. Interviews with stakeholders, such as clients, end-users,
and domain experts, are a crucial way to gather detailed
information about the project's requirements. This
allows for direct communication and clarification of any
unclear points.
3.
2. Questionnaires:
Questionnaires are a structured way to collect information
from multiple stakeholders. They can be used to gather
both functional and non-functional requirements, and can
be distributed to a large number of people for a more
comprehensive understanding of the project's needs.
 3. Workshops:
Workshops bring together stakeholders in an interactive
environment to discuss, analyze, and prioritize
requirements. This collaborative approach can help
identify gaps, clarify ambiguities, and ensure that all
aspects of the project are considered.

4. User Cases:
Use cases are a popular technique for documenting
functional requirements. They describe a series of actions
or events that a user goes through to achieve a goal, and
the system's response to those actions. Use cases help
provide a clear understanding of how the system should
behave in different scenarios.
 5. User Stories:
User stories are a popular technique for Agile projects.
They describe a user's interaction with the system from
their perspective, usually in the format "As a [type of user],
I want [a feature] so that [a benefit]." User stories help to
prioritize requirements and break them down into smaller,
manageable tasks.

6. Data Flow Diagrams:

Data Flow Diagrams (DFDs) are visual representations of
the flow of data within a system. They help in identifying
the functional requirements by showing how data enters,
moves within, and leaves the system.
 7. State Transition Diagrams:
State Transition Diagrams (STDs) are used to model the different
states that a system can be in and the events that cause
transitions between these states. They are particularly useful for
analysing requirements related to user interactions and system
behaviour.

8. Requirements Traceability Matrix:

A Requirements Traceability Matrix (RTM) is a table that maps
requirements to their sources, tests, and implementations. It
helps track the status of requirements throughout the project
and ensures that nothing is missed or left unverified.

Each of these techniques has its own strengths and weaknesses, and the choice of
technique should be based on the context of the project, the preferences of the
stakeholders, and the expertise of the team. Often, a combination of these
techniques is used to ensure a comprehensive understanding of the project's
requirements.
 Qn3:
Prepare a software requirement specification for a given software problem

1. Introduction:
2. Provide an overview of the software project, including
its purpose, scope, and objectives. Clearly define the
intended audience and the problem the software aims
to solve.
3.
2. Stakeholders and their interests:
Identify the key stakeholders involved in the project and
outline their interests and expectations. This helps in
understanding the needs and priorities of the different
parties involved.
 3. Functional requirements:
List and describe the primary features and capabilities of the
software. Use user cases, user stories, or detailed
specifications to explain what the software should do.
Ensure that each requirement is clear, concise, and traceable
to a specific stakeholder need.

4. Non-functional requirements:
Specify the qualities or attributes of the software that are
not directly related to its functionality but are crucial for the
project's success. These may include performance, security,
usability, scalability, maintainability, and compliance with
relevant regulations and standards.
 5. Constraints:
Identify any constraints that may impact the development
or implementation of the software, such as budget, time,
and technology limitations.

6. Assumptions:
List any assumptions made during the requirement
gathering process. These may include assumptions about
the user population, the technical environment, or the
availability of resources.

7. Glossary:
Define any technical terms, abbreviations, or acronyms used
in the SRS to improve clarity and understanding.
 8. Appendices:
Include any additional information or supporting documents, such
as wireframes, mock-ups, or diagrams, that can help clarify the
requirements.

9. Version control:
Indicate the version number and date of the SRS, and provide a
brief summary of any changes made between versions.

10. Approval:
Obtain signatures from the relevant stakeholders to indicate their
approval of the SRS. This signifies that the requirements are
complete, clear, and agreed upon by all parties involved.

Remember that an SRS is a living document that may need to be revised and updated as the
software project progresses. Regular communication and collaboration with stakeholders are
essential to ensure that the document remains accurate and up-to-date throughout the
development process.
 Requirement validation
Requirements validation is a critical step in the software
development process that ensures the system meets the needs and
expectations of the stakeholders. It involves verifying and validating
that the requirements are complete, correct, and unambiguous, and
that they align with the project goals and objectives. Here are some
key aspects of requirements validation.

Requirement specification is a detailed and comprehensive

description of the desired behaviour, functionality, and performance
of a system or product. It serves as the foundation for the design,
development, and testing phases of a project. A well-defined
requirement specification helps ensure that the final product meets
the needs of the stakeholders and aligns with the project goals and
objectives. Key elements of a requirement specification include:
 1. Review and inspection:
2. Thoroughly review the requirements documentation
to identify any inconsistencies, contradictions, or
missing information. This can be done through
inspections, walkthroughs, or peer reviews.
3.
2. Traceability:
Establish traceability between the requirements and
other artefacts, such as design, testing, and
implementation documents. This helps ensure that the
requirements are accurately implemented and tested.
 5. Testing:
Develop and execute test cases to verify that the system
meets the requirements. This includes functional testing,
performance testing, and usability testing to ensure that all
aspects of the system are validated.

6. Continuous validation:
Continuously validate requirements throughout the
development process to ensure that changes in design or
implementation do not impact the overall requirements. This
includes regular reviews and updates to the requirements
documentation.etc.
 7. System overview:
A high-level description of the system, its purpose, and its
scope. This section should provide an understanding of the
context in which the system will operate.

8. Functional requirements:
A detailed list of the features and functionalities that the
system must provide. These requirements should be clear,
unambiguous, and complete, and should describe how the
system should behave under various conditions.

A well-written requirement specification is crucial for the success of a project, as it

sets the foundation for the development process and serves as a reference for all
stakeholders throughout the project lifecycle.