COURSE TITLE: Software Development

LECTURER: MR BESSONG RAWLINGS E

OBJECTIVE: familiarize the students with the object-oriented development

approach based on UML language

CONTENT

• System/software development methodologies

• Software development life cycle
• Requirement specification
• System Design: System static architecture, system dynamics
• coding and testing
• Installation: creating a package of installation

OUTCOME

At the end of the course the students should understand the object oriented
development approach based on the UML language

1)REQUIREMENT SPECIFICATION
In the world of project management and software development, the user
requirement specification (URS) plays a central role. This comprehensive
document serves as the foundation upon which successful projects are built.
The requirement specification, which is composed of the German word “Lasten”
(requirements) and “Heft” (booklet), is essentially a booklet of requirements. It is
an official document that records the specific needs, expectations, and features
of a project or software to meet the user’s requirements. Consider it as a
roadmap that guides the entire project team toward a common goal.
The significance of the specification sheet
• Ensuring clarity and consistency: One of the main goals of specifications is to
eliminate ambiguity. Clearly defining the project scope, functionalities and
constraints ensures that all stakeholders are on the same page. This clarity is
critical to project success.
• Managing expectations: A specification helps manage user expectations.
When customers and users have a clear understanding of what the project
will deliver, it minimizes the likelihood of misunderstanding and
disappointment along the way.

Components Of A Specification
1. Introduction: The specification begins with an introduction that provides an
overview of the purpose and scope of the document. It provides the
framework for what follows.
2. Project description: This section provides a detailed description of the project,
including its background, objectives, and stakeholders.
3. Functional requirements: This is the heart of the specification. It outlines
the specific functionalities that the project or software must possess. Each
requirement should be clearly defined and prioritized.
4. Non-functional requirements: In addition to functionalities, non-functional
aspects such as performance, security and scalability are also addressed
here. These are critical to the user’s overall experience.
5. Constraints: This section discusses any limitations or constraints that may
impact the project, such as budget, time, or resources.
6. Acceptance criteria: How is the project judged to be successful? Acceptance
criteria are the measurable conditions that must be met for the project to be
considered complete.
7. Stakeholder Release: Before proceeding with the project, it is important to
obtain formal approval from stakeholders confirming their agreement with
the specifications.

Design Of An Effective Specification Sheet

Below are some best practices to ensure effectiveness:

1. Collaboration: Involve all relevant stakeholders, including end users, in the

creation process. Their input is invaluable in setting accurate requirements.
2. Clarity: Avoid jargon and use language that is easily understood by all
stakeholders. The document should be crystal clear to avoid
misinterpretation.

3. Traceability: Ensure that every requirement can be traced back to its source,
whether it is a user need or a regulatory requirement. This traceability helps
with accountability.

4. Prioritization: Prioritize requirements so that the most critical functionalities

are addressed first. This is helpful when resources are limited or the project
scope changes.

User Required Specification

What is a User Requirement Specification? User Required Specification (URS)
is a crucial document in the development of any product, software, or system. It
is a document that specifies what the product should do and outlines the
requirements of the customer or user in detail, making sure that the product
meets the expectations of the end user.

In this article, we will navigate you through the meaning of the User Required
Specifications and their importance. Also, we will give you a general template
you can use if you need a URS.

User Required Specification And Its Importance

A User Required Specification (URS) is a comprehensive document that defines

the requirements of the customer (user). It outlines the features of the
product, its functions, and its performance that are needed to satisfy the
user’s requirements.

The User Required Specification document needs to be created at the early

stages of the product development process. It represents an essential tool for
communication between the development team and the user. The URS
document explains exactly what the user needs and this will act as a guide for
the development team.

The Importance
The importance of URS cannot be overemphasized. This is a document
that ensures that your product fits the user’s needs. This will result in a
 product that is more likely to be recognized and successful in the market. User
Required Specification document helps developers and businesses reduce the
risk of misinterpretation of user requirements.

This template includes several steps that you can use as a starting point.

1. Introduction
In the Introduction part, you should:

• Provide a short overview of the product (or system) that is being developed and
what its purpose is.
• Explain the purpose of the URS document.
• Mention the intended audience.
2. Defining User Needs
After the Introduction, you need to:

• Identify and describe the user needs.

• Explain how your product will address each one of the described needs.
3. Product’s Functional Requirements
When you want to list the product’s functional requirements, you should:

• Identify and describe some of the key functions that your product will perform.
• Identify any requirements that need to be met for each function.
4. Non-Functional Requirements
When you want to list the product’s non-functional requirements, you should:

• Identify and describe all the non-functional requirements that your product
needs to meet.
• Be prepared that these may include usability, performance, scalability, security,
and other factors.
5. Safety Requirements
When there are safety requirements in question, you need to:

• Identify and describe any safety requirements that your product needs to meet
if there are any.
• Be aware that these may include industry standards, regulations, or other
requirements.
6. Environmental Requirements
If it is possible, you should:

• Identify and describe any environmental requirements that your product must
meet.
• Know that this may include humidity, temperature, or other environmental
factors.
7. Regulatory Requirements
If it is needed, you should:

• Identify and describe any regulatory requirements that your product needs to
meet.
• These may include some industry and/or legal standards that need to be
followed.
8. Acceptance Criteria
Regarding the acceptance criteria, you should:

• Identify the acceptance criteria

• Use the criteria and determine if the product or system has met the
requirements.
• Clarify the process for testing and validating your product.
9. Limitations
Limitations can cause several drawbacks to your project. For this, you should:

• Identify and describe any limitations that should be taken into account while
developing your product.
• Know that these may include schedule, budget, or other factors.
10. Assumptions
When it comes to the assumptions segment, you should:

• Identify and describe all the assumptions that you made during the
development of the URS document.
• Clarify how these assumptions might affect the development of your product.
11. Sign-Off
At the end of the document, you should save a section for signatures from the
development team and the user team, which will show that the URS document
has been properly reviewed and approved.

We have provided you with a basic user-required specification template, and

this might help you if you need to know where to start. However, you can
customize and change this template to fit your needs and the needs of your
specific product.

However, it should provide a good starting point for developing your own URS
document.

SYSTEM DESIGN
Systems Design is the process of defining the architecture, components,
modules, interfaces, and data for a system to satisfy specified requirements. It
involves translating user requirements into a detailed blueprint that guides the
implementation phase. The goal is to create a well-organized and efficient
structure that meets the intended purpose while considering factors
like scalability, maintainability, and performance.

In any development process, be it Software or any other tech, the most

important stage is Design. Without the designing phase, you cannot jump to the
implementation or the testing part. The same is the case with the System as
well. Systems Design not only is a vital step in the development of the system
but also provides the backbone to handle exceptional scenarios because it
represents the business logic of software.

The importance of System Design phase in SDLC

From the above SDLC steps, it is clear that system design acts as a backbone
because no matter how good the coding part is executed, it, later on, becomes
irrelevant if the corresponding design is not good. So here we get crucial vital
information as to why it is been asked in every Product Based Company.

Below are the main 5 reasons why to learn system design:

1. System Design is crucial in FAANG interviews.

2. You need to have good expertise in System Design to be hired for Senior
positions.
 3. System Design proficiency enhances job security.
4. Understanding System Design will help you to have good communication.
5. Learning System Design improves decision-making.

Objectives Of Systems Design

Below are the main objectives of Systems Design:

1. Practicality: We need a system that should be targeting the set of

audiences(users) corresponding to which they are designing.
2. Accuracy: Above system design should be designed in such a way it fulfills
nearly all requirements around which it is designed be it functional o non-
functional requirements.
3. Completeness: System design should meet all user requirements
4. Efficient: The system design should be such that it should not overuse
surpassing the cost of resources nor under use as it will by now we know
will result in low thorough put (output) and less response time(latency).
5. Reliability: The system designed should be in proximity to a failure-free
environment for a certain period of time.
6. Optimization: Time and space are just likely what we do for code chunks
for individual components to work in a system.

Scalable(flexibility): System design should be adaptable with time as per

different user needs of customers which we know will keep on changing on
time. The best example here out is the well-known firm: Nokia. It is the most
important aspect while designing systems and is the result of why 1 of 100
startups succeed over the long run, the best example here out is
GeeksforGeeks.
 System Design Life Cycle (SDLC)
The System Design Life Cycle (SDLC) is a comprehensive process that outlines the steps
involved in designing and developing a system, be it a software application, hardware
solution, or an integrated system combining both. It encompasses a series of phases that
guide engineers through the creation of a system that aligns with the user’s needs and
organizational goals. The SDLC aims to ensure that the end product is reliable, scalable, and
maintainable.

System Design Life Cycle (SDLC)

System Architecture

System architecture is a way in which we define how the components of a design are
depicted design and deployment of software. It is basically the skeleton design of a software
system depicting components, abstraction levels, and other aspects of a software system. In
order to understand it in a layman’s language, it is the aim or logic of a business should be
crystal clear and laid out on a single sheet of paper. Here goals of big projects and further
guides to scaling up are there for the existing system and upcoming systems to be scaled up.

System Architecture Patterns

There are various ways to organize the components in software or system architecture. And
the different predefined organization of components in software architectures are known as
software architecture patterns. A lot of patterns were tried and tested. Most of them have
successfully solved various problems. In each pattern, the components are organized
differently for solving a specific problem in software architectures.

Different types of System Architecture Patterns include:

Client-Server Architecture Pattern: Separates the system into two main components: clients
that request services and servers that provide them.
Event-Driven Architecture Pattern: Uses events to trigger and communicate between
decoupled components, enhancing responsiveness and scalability.

Microkernel Architecture Pattern: Centers around a core system (microkernel) with additional
features and functionalities added as plugins or extensions.

Microservices Architecture Pattern: Breaks down applications into small, independent

services that can be developed, deployed, and scaled independently.

System Architecture Patterns

Modularity and Interfaces In Systems Design

Modularity and interfaces in systems design are essential concepts that enhance flexibility
and usability by breaking down complex systems into manageable components and
providing intuitive user interactions.

1. Modularity

Modular design involves breaking down complex products into smaller, independent
components or modules. This allows each module (e.g., a car’s engine or transmission) to be
developed and tested separately, making the overall system more flexible and easier to
manage. The final product is assembled by integrating these modules, enabling changes
without affecting the entire system.

2. Interfaces

In systems design, interfaces are the points where users interact with the system. This
includes navigation elements, data input forms, and report displays. Effective interfaces are
intuitive and user-friendly, enhancing the overall user experience and ensuring efficient data
collection and system navigation.
System static architecture
A system's static architecture is the structure and behavior of a system that is defined during
compilation and cannot be changed during runtime. Static architectures are often used in
safety-critical applications and hard real-time applications.

Static architectures are often used in safety-critical applications and hard real-time
applications.

SYSTEM DYNAMICS
System Dynamics is a computer-aided approach for strategy and policy design. The main goal
is to help people make better decisions when confronted with complex, dynamic systems.
The approach provides methods and tools to model and analyzes dynamic systems.

The purpose of System Dynamics is to help people understand complex and dynamic
systems and help them make better decisions. The field provides a philosophy and tools to
model and analyze dynamic systems. Equally important, the field provides techniques and
tools to investigate current decision making and to help decision makers learn.

System Dynamics is a methodology and mathematical modeling technique for strategy

development. The main goal is to help people make better decisions when confronted with
complex, dynamic systems.

System Dynamics uses simulation modeling based on feedback systems theory that
complements systems thinking approaches. It applies to dynamic problems arising in
complex social, managerial, economic, or ecological systems.

Systems thinking is a way to describe and understand the causality and interrelations
between variables within a system. System Dynamics quantifies the impact of those
interactions.