SAD Project report
Functional analysis 4mks
Role or Function of the department in the university
The fucntional structure i.e. how is the department structured in terms of sections/units
What’s the relationship between the units
How do they support the core function of the department
Work breakdown structure (WBS) 3mks
List all the activities your group will engage in
Represent them in form of a WBS
Project Execution plan 3mks
How do you plan to execute the project
Present the sequence of activities in a network diagram
Map the network diagram onto a Gantt chart
Modelling the activities 10mks
Identify the business processes used to execute the functions
List the activities in each process and capture them using a use-case diagram
Use DFDs to model data flow, flow charts to model the flow of logic and sequence of actions
Use the Activity diagram in Swimlanes to model the activities and the people involved
Systems requirements specification (SRS)
The following are the key components of an SRS document and their significance in the software
development process.
Introduction: The introduction section sets the context for the SRS document. It provides an
overview of the software project, including its purpose, objectives, and intended audience. The
introduction helps stakeholders understand the scope and importance of the software, creating
a foundation for the rest of the document.
Scope: The scope section defines the boundaries of the software project. It clearly outlines what
functionalities and features are included in the software and, equally important, what
functionalities are excluded. The scope sets realistic expectations and ensures that both the
clients and the development team have a shared understanding of the project's limitations.
Functional Requirements: Functional requirements describe the specific functionalities and
features that the software should possess. These requirements articulate what the software is
expected to do, including its core functionalities and any additional features requested by the
clients. Functional requirements provide a clear roadmap for the development team, guiding
them in building the software according to the clients' needs.
Non-Functional Requirements: Non-functional requirements define the qualities and
constraints that the software must adhere to. These example of software requirement go
beyond the core functionalities and focus on aspects such as performance, security, usability,
reliability, and scalability. Non-functional requirements help shape the overall user experience
and ensure that the software meets specific quality standards.
User Interface (UI) Requirements: UI requirements outline the design and layout of the
software's user interface. This includes details such as the visual elements, navigation, user
interactions, and overall user experience. UI requirements help create a user-friendly and
intuitive interface, enhancing user satisfaction and usability.
System Architecture: The system architecture section provides an overview of the software's
overall structure and design. It includes details about the hardware and software components,
subsystems, and their interactions. System architecture diagrams, such as block diagrams or
flowcharts, may be included to visualize the system's structure and help stakeholders
understand the software's technical aspects.
Data Dictionary: The data dictionary is a critical component of an SRS document, especially for
database-driven software projects. It provides a detailed description of the data entities used in
the software, including data definitions, data types, and relationships between entities. The data
dictionary ensures that all stakeholders have a common understanding of the data used in the
software and helps maintain data integrity and consistency.
Assumptions and Constraints: Assumptions and constraints highlight any assumptions made
during the requirements-gathering process and any external factors or limitations that may
impact the software development. This component helps stakeholders understand the context
and constraints within which the software is being developed.
Dependencies: The dependencies section identifies any external systems, software, or hardware
that the software relies on. This includes any APIs, libraries, or third-party services that need to
be integrated into the software. Identifying dependencies ensures that the necessary
components are available and compatible with the software.
Use Cases: Use cases provide specific scenarios or interactions between the users and the
software. They describe step-by-step sequences of actions and expected outcomes, helping
stakeholders understand how the software will be used in real-world situations. Use cases assist
the development team in designing the software's behavior and functionality.
System Constraints: System constraints outline any technical or operational limitations that the
software must adhere to. These constraints may include compatibility example software
requirements, hardware or software limitations, performance thresholds, or regulatory
constraints. System constraints ensure that the software is developed within the specified
technical boundaries.
Risk Assessment: The risk assessment component identifies and assesses potential risks
associated with the software project. It includes an analysis of the risks and proposes mitigation
strategies to address them. Risk assessment helps stakeholders understand the potential
challenges and uncertainties that may arise during the development process, allowing for
proactive risk management.
Glossary: A glossary is an important component of an SRS document, especially when technical
terms and acronyms are used. It provides definitions for these terms, ensuring clarity and
understanding among stakeholders. The glossary promotes effective communication and avoids
confusion caused by unfamiliar terminology.
