Software-Requirements, ch.1. Introduction.pdf

Software Requirements, Chapter I: Introduction
© 2024, UKH, Dr.Ibrahim Ismael Hamarash, ibrahim.hamad@ukh.edu.krd
Software Requirements
Engineering
Chapter I
Introduction
Professor Dr. Ibrahim Ismael Hamarash
ibrahim.hamad@ukh.edu.krd

The Software Industry
✓ Everyone needs a website,
and/or a mobile app.
The first thing that we think about
when we open a business …
✓ Chatbots will become popular in
the next few years, dominating
the computing industry.
Example:
Mobile applications got so
popular that restaurants,
gyms, coaches, everybody
basically needs a mobile
application that makes the
business to the next level.

How Customers Approach
You as a Software
Professional
➢ The customer usually knows they
need technology but might not
know exactly what that entails.
➢ They might say: “I need an app to
manage my business,” or “We need
a website to reach more
customers.”

Software as a Business Project
Starting a Project: What Do You
Want?
• The first question: "What do
you want?"
• Simple and direct: No tools, no
complex processes.
• Focus on business needs.

Getting Ideas on Paper
• Start with brainstorming – empty
your head of all ideas.
• Write everything down.
• No structure initially, just free flow
of ideas.

Organizing Ideas
Adding Structure to Your Ideas
• After the brainstorming phase,
start organizing the ideas.
• Use tools only to structure ideas.
• Popular tools: Command
structures, mind maps, Excel.
https://thoughtflow.io/blog/best-miro-alternatives

• Mind maps and Excel are
effective tools to organize
ideas.
• Choose the tool that works
best for you.
• Practice with both and
understand when each one is
most effective.
UX

Adding Structure to Requirements
• Take each idea one by one.
• Define its description, what’s
expected to be delivered, and
acceptance criteria.
• Focus on clarity and precision.

Getting into Technical and Legal Details
• Define the technical aspects and system
integration.
• Consider legal requirements like data
protection, terms, and privacy policies.
• Compliance with international
standards is essential.

Diving Deeper into the Details
• Refine each part of the project.
• Revisit technical and legal
aspects for more detail.
• Understand how they relate to
the core business vision.

Peer Review and Finalization
• Always have a peer review for your
requirements document. Submit your
requirements for review.
• Fresh eyes can spot what you’ve
missed.
• Encourage feedback from others.

Software Requirement
Specification (SRS)

Software
Requirements
Lifecycle
Software
Requirements
Lifecycle

Module
Assessment

Case Study: Fitness App
Requirement
• What do you want? Start by asking
yourself or the client, “What do you
want from this fitness app?”
• The business needs could be: “We
want to help users track their
workouts, monitor progress, and set
fitness goals.”

Requirement
Using Tools to Structure the Needs
• After gathering basic ideas, it’s time to structure them.
• Tools like mind maps or Excel can help. Start organizing features:
Workout tracking, Progress monitoring, Goal setting, Nutritional advice,
etc.

Requirement
Detailing the Needs
• Workout Tracking: What kind of
workouts? Cardio, strength, or flexibility?
• Progress Monitoring: Will the app show
daily, weekly, or monthly reports? What
metrics will it track—calories burned,
distance, or weight lifted?
• Goal Setting: How will users set goals?
Will they receive notifications if they miss
targets?

Requirement
Describing Limitations and Functions
• Functions: Define what the app will do. For instance, the app
can:
• Log exercises (functionality for data input from users).
• Provide suggestions for workouts based on goals.
• Limitations: Also, set expectations on what the app won’t do.
For example:
• The app won’t offer personalized meal plans (to avoid
over-complication).
• The app won’t track real-time heart rate without external
hardware.

Requirement
Documenting the Ideas
• Create a clear, written document that lists all features and
specifications (e.g., the app will track cardio and strength
workouts, users can set goals for weekly calorie burn, etc.).
• This document becomes the blueprint for the development
team, guiding them through the process.
• Ensure everything is written in a clear, understandable
manner so there’s no ambiguity.

Requirement
Peer Review
• Before moving forward with development, it’s crucial to
have a peer review of the requirements document.
• For example, someone from the development team or
another business analyst might review the document and
provide feedback like, “Should the app also offer a social
sharing feature so users can share their progress?”
• Peer reviews help spot missing details, incorrect assumptions,
or opportunities to improve the functionality.

Case Study: Fitness App Requirement
SRS Document
Software requirements specification (SRS) is a technical
document describing the project’s functionality, features,
design, limitations, and goals. An SRS outlines how an
application should operate and how the product
development team should build it. While a client may use it
to define his/her project expectations and deliverables, the
development company will use it to assess the amount of
work, define the technology stack, and estimate the project
cost.

Module Assessment

Discussion

Software-Requirements, ch.1. Introduction.pdf

More Related Content

Similar to Software-Requirements, ch.1. Introduction.pdf (20)

More from Salahaddin University-Erbil, University of Kurdistan Hewler (10)

Recently uploaded (20)

Software-Requirements, ch.1. Introduction.pdf