System Analysis & Design

Lab 02
Instructor: Dr.Nesreen El saber
TA : Eng.Saja Saadoun , Eng.Pansy Youssef
 2

System Request Plan :

A formal document used to initiate a new system development project. It provides key
information about the project’s purpose, objectives, and justification.

Consists of :
1.​ Project Title : A clear, concise name for the proposed system .
2.​ Requestor Information : Details of the person or department requesting the system
(name, department, contact details).
3.​ Business Need / Problem Statement : Describes the current issue or business problem
that the new system aims to solve.
4.​ Proposed Solution : A brief description of how the new system will address the business
need.
5.​ Expected Benefits : Lists the benefits the system will provide, such as improved
efficiency, cost savings, accuracy, and user experience.
6.​ Project Scope : Defines what the system will and will not include.
7.​ Stakeholders : Identifies key people involved in the project, such as system users, IT
teams, and management.
8.​ Constraints and Assumptions : Constraints: Time, budget, technology limitations.
Assumptions: Availability of required data, third-party API access, regulatory compliance.
9.​ Estimated Timeline : A rough estimate of how long the system will take to develop and
implement.
10.​Approval Section : A signature or approval section for management to authorize the
project.
 3

Types of Requirements and Their Differences

Requirements define what a system, product, or project should do. They are typically categorized into
different types:

1. Business Requirements

●​ High-level objectives that describe why the project or system is needed.

●​ Examples:
o​ "Increase customer retention by 20%."
o​ "Enable online payment for faster transactions."

2. User Requirements

●​ Definition: Statements describing what users expect from the system . used to capture user
needs, expectations, and goals to ensure usability and satisfaction.
●​ Examples:
o​ "Users should be able to reset their password easily."
o​ "The mobile app should be available on both Android and iOS."
o​ "The interface should be simple and intuitive for non-technical users."

3. Functional Requirements

●​ Definition: Describe what the system should do in terms of functionality, these are specific
actions the system must perform (What system must do?).
●​ Examples:
o​ "The system shall allow users to log in using a username and password."
o​ "The software shall generate monthly sales reports."

4. Non-Functional Requirements (NFRs)

●​ Definition: Define system qualities, constraints, and performance metrics, They specify how the
system should work rather than what it should do (How system should perform)
●​ Examples:
o​ "The system should handle 1,000 transactions per second." (Performance)
o​ "Users should authenticate within 3 seconds." (Usability)
 4

5. Technical Requirements

●​ Definition: Describe the technologies, platforms, or standards required for implementation,

These are implementation constraints.
●​ Examples:
o​ "The system must be developed using Java and MySQL."
o​ "The application should support both iOS and Android."

How to extract requirements?

Requirements Elicitation Techniques : Elicitation is the process of gathering requirements from
stakeholders, users, and other sources to ensure a system meets business and user needs. Below are five
key techniques used in requirement elicitation:

1. Interview
Definition : A direct conversation between a business analyst and stakeholders to extract detailed
requirements.
Types:

●​ Structured Interview – Predefined set of questions.

●​ Unstructured Interview – Open-ended discussion.
●​ Semi-Structured Interview – A mix of both.

Steps:

1.​ Identify the stakeholders to be interviewed.

2.​ Prepare key questions and discussion points.
3.​ Conduct the interview and document responses.
4.​ Validate the gathered information with the interviewee.
 5

Pros:
✔ Provides deep insights.​
✔ Allows clarification in real-time.​
✔ Helps understand stakeholder priorities.

Cons:
✘ Time-consuming.​
✘ Responses can be biased or unclear.​
✘ Requires skilled interviewers.

2. Joint Application Development (JAD)

Definition: A collaborative workshop where stakeholders, business analysts, and developers gather to
define requirements interactively.
Steps:

1.​ Identify key stakeholders (users, developers, business leaders).

2.​ Conduct a structured workshop with facilitators.
3.​ Use visual aids (diagrams, mockups) for better understanding.
4.​ Document agreed-upon requirements.
5.​ Review and finalize.

Pros:
✔ Reduces development time.​
✔ Ensures stakeholder alignment.​
✔ Encourages collaboration.

Cons:
✘ Requires full stakeholder availability.​
✘ Can be expensive and time-consuming.​
✘ Needs skilled facilitators.
 6

3. Questionnaires
Definition: A set of structured questions sent to stakeholders to gather information from multiple
sources.
Types:

●​ Open-Ended – Allows detailed responses.

●​ Closed-Ended – Provides specific choices (e.g., Yes/No, Multiple Choice).

Steps:

1.​ Define the objective of the questionnaire.

2.​ Design clear, concise, and unbiased questions.
3.​ Distribute the questionnaire to relevant stakeholders.
4.​ Analyze responses and extract requirements.

Pros:
✔ Quick and efficient for large groups.​
✔ Cost-effective.​
✔ Provides quantitative data.

Cons:
✘ Low response rate.​
✘ Limited opportunity for clarification.​
✘ May not capture deep insights.
 7

4. Document Analysis
Definition: Reviewing existing documentation (manuals, reports, system logs, previous project files) to
extract useful requirements.
Steps:

1.​ Identify relevant documents.

2.​ Extract key requirements.
3.​ Validate findings with stakeholders.
4.​ Cross-check consistency with business goals.

P Pros:
✔ Saves time by leveraging existing knowledge.​
✔ Helps understand historical context.​
✔ Useful for compliance and legal requirements.

Cons:
✘ Documents may be outdated or incomplete.​
✘ Requires interpretation, which may lead to misunderstandings.​
✘ Not suitable for gathering user expectations.
 8

5. Observation
Definition: Studying users in their work environment to understand their real-world needs and
challenges.

Types:

●​ Passive Observation (Fly-on-the-Wall) – Watching users without interaction.

●​ Active Observation (Participatory) – Engaging with users while they perform tasks.

Steps:

1.​ Select users and activities to observe.

2.​ Record actions, workflows, and challenges.
3.​ Identify pain points and areas for improvement.
4.​ Validate observations with users.

Pros:
✔ Provides real-world insights.​
✔ Helps uncover hidden requirements.​
✔ Reduces reliance on user memory or bias.

Cons:
✘ Time-consuming.​
✘ May not capture all use cases.​
✘ Users may alter behavior when being observed.
 9

Lab tasks:
Extract the functional and non-Functional requirements from this case study.
1- “Holiday Travel Vehicles, a fictitious recreational vehicle dealership”.
 10

2-

Write down the functional and non-functional requirements of the following case
studies(choose one case study):
1.​ Hospital Appointment Management System : allows patients to book, reschedule, or cancel
appointments online or via a mobile app

2.​ University Course Registration System : An Automated Course Registration System that allows
students to register for courses online, view available slots, and receive instant confirmation.

3.​ Library Management System : automates book check-ins and check-outs using a barcode or RFID
system, tracks due dates, and alerts users about overdue books.