Lesson 2

Systems Analysis and Design: Requirements Gathering and Analysis

 Types of Requirements: Functional and non-functional requirements.

 Requirements Elicitation Techniques: Interviews, surveys, observations, document
analysis, and prototyping.
 Modelling Tools: Use Case Diagrams, Data Flow Diagrams (DFD), Entity-Relationship
Diagrams (ERD).
 Functional vs Non-Functional Requirements: Defining what the system will do and how
well it will perform.

1. Introduction to Requirements Gathering

Requirements gathering is one of the most crucial stages in the Systems Analysis and Design
(SAD) process.

The goal: is to gather detailed and accurate information about what the system should do, as
well as the constraints it must operate within. This information forms the foundation for the
design and development phases.

Key Points:

 Requirements must be clear, complete, and unambiguous.

 They serve as the basis for designing, building, and testing the system.

 Inadequate or incorrect requirements can lead to project failure or costly rework.

2. Types of Requirements

1. Functional Requirements:

o Describe what the system should do,i.e., the specific functionality.

o Examples: User login, data processing, reporting features, etc.

o Login System:

 Requirement: The system must allow users to log in using a username

and password.

 Explanation: This defines the specific functionality of the login process.

2. Non-Functional Requirements:

Page 1 of 10
 o Describe how the system should perform the tasks rather than what tasks it
performs.

o Examples: Performance, security, usability, and scalability.

o Examples:

1. Performance
 Definition: Performance refers to how well a system responds to requests or how
efficiently it performs its tasks, often measured in terms of speed, responsiveness, and
resource usage.
 Aspects:
o Response time: How quickly the system reacts to a user’s input or request.
o Throughput: The amount of work the system can handle in a given period.
o Efficiency: How optimally the system uses computational resources (CPU,
memory, bandwidth).
 Example: A website that loads within 2 seconds under normal traffic is performing well.

2. Scalability
 Definition: Scalability is the ability of a system to handle increasing amounts of work or
its potential to accommodate growth, whether it's more users, data, or transactions.
 Aspects:
o Vertical Scalability (Scaling Up): Adding more resources (CPU, memory, storage)
to a single server to increase capacity.
o Horizontal Scalability (Scaling Out): Adding more servers or instances to
distribute the load.
 Example: A cloud-based application that can handle more users by adding additional
servers to meet demand during peak hours.

3. Security
 Definition: Security refers to the measures taken to protect the system and its data from
unauthorized access, breaches, and attacks.
 Aspects:
o Authentication: Verifying the identity of users (e.g., username and password,
biometrics).
o Authorization: Defining what authenticated users are allowed to do (e.g., user
roles, permissions).
o Encryption: Protecting sensitive data by converting it into unreadable format
unless decrypted with a proper key.
o Vulnerability management: Identifying and fixing security flaws or weaknesses
in the system.

Page 2 of 10
 Example: Implementing HTTPS, encrypting user data, and protecting against SQL
injection are all part of securing an application.

4. Usability
 Definition: Usability refers to how easy, intuitive, and user-friendly the system is for its
intended users.
 Aspects:
o Ease of use: How easy it is for users to understand and interact with the system.
o Learnability: How quickly users can learn how to use the system.
o Accessibility: Making sure the system is usable by people with disabilities (e.g.,
voice commands, screen readers).
o User experience (UX): Overall satisfaction with the system's interface and
design.
 Example: A mobile app with clear navigation, simple interfaces, and user-friendly design
is considered highly usable.

5. Availability
 Definition: Availability refers to the proportion of time a system is operational and
accessible to users, often expressed as a percentage (e.g., 99.99% uptime).
 Aspects:
o Uptime: The time when the system is running and accessible.
o Downtime: The time when the system is unavailable due to maintenance,
failure, or other issues.
o Fault tolerance: The ability of a system to continue functioning even when
certain components fail.
o Redundancy: Having backup systems and components to maintain availability
during failures (e.g., backup servers, load balancers).
 Example: A web service that has an uptime of 99.9% (which means it's down for about
8 hours a year) is highly available.

3.User Requirements:

a. These are the high-level needs or expectations from the system

from the user's perspective.

b. Examples: "The system should allow users to search for

products."

4.System Requirements:

o More detailed and technical requirements that define how the system will meet
user needs.

Page 3 of 10
 o Examples: "The system must handle 1000 concurrent users."

5. Business Requirements:

a. Higher-level needs that align the system with the business goals and strategy.

b. Examples: "The system should increase operational efficiency by 20%."

3. Requirements Elicitation Techniques

Eliciting requirements involves collecting information from various stakeholders to understand

their needs. This is often done using several techniques:

1. Interviews:

o One-on-one interviews with stakeholders (users, managers, developers) to

understand their needs.

o Pros: Direct, personal insight; clarifies specific requirements.

o Cons: Time-consuming, may lead to biased or incomplete data if not structured

properly.

2. Surveys/Questionnaires:

o Structured forms that ask specific questions to a large group of people.

o Pros: Can gather data from a large number of stakeholders quickly.

o Cons: May lack depth; respondents might misunderstand questions.

3. Workshops:

o Group discussions or focus groups involving stakeholders.

o Pros: Facilitates collaboration and idea sharing, quickly gathers feedback.

o Cons: May lead to conflicts or difficulty in reaching consensus.

4. Observation:

o Observing users while they interact with existing systems or perform tasks.

o Pros: Provides a realistic view of how tasks are performed in the actual
environment.

o Cons: Time-consuming and potentially disruptive; users might alter behavior

when observed.

Page 4 of 10
 5. Document Analysis:

o Reviewing existing documents such as business plans, user manuals, or legacy

system documentation.

o Pros: Helps identify existing processes and requirements.

o Cons: Documents might be outdated or incomplete.

6. Prototyping:

o Creating a preliminary version of the system (a prototype) that allows users to

interact with it and provide feedback.

o Pros: Users get to see and feel the system early; feedback can refine the design.

o Cons: Users might focus on the prototype itself rather than the system’s actual
purpose.

7. Use Cases:

o Describing interactions between users (actors) and the system. Use cases
capture functional requirements.

o Pros: Clarifies functional requirements from the user’s perspective.

o Cons: May not capture non-functional requirements.

4. Final Requirements Documenting

Once the requirements are gathered, they need to be carefully documented to avoid
misunderstandings. Common documentation techniques include:

1. Requirements Specification Document (RSD):

o A detailed, formal document that outlines all system requirements.

o Includes both functional and non-functional requirements, often broken down

into detailed sections.

Key Sections of the RSD:

i. Introduction:

a. Overview of the Hospital Management System (HMS), its goals, and the
stakeholders involved.

ii. Functional Requirements:

Page 5 of 10
 a. Detailed descriptions of the system's key features, such as patient registration,
appointment scheduling, medical records management, billing, and reporting.

iii. Non-Functional Requirements:

a. Security, performance, scalability, usability, and compliance requirements for

the system.

iv. Data Flow Diagrams (DFD):

a. Diagrams that show the flow of patient data and how it will be processed across
the system.

v. Use Cases:

a. Descriptions of typical user interactions with the system, such as the process
for registering a new patient or scheduling an appointment.

vi. System Architecture Requirements:

a. Overview of the technical architecture, including integration with other hospital

systems, third-party applications, and hardware requirements.

2. Use Case Diagrams and Descriptions:

o A visual representation of interactions between users and the system, often

used in conjunction with use cases.

o Describes specific scenarios of how the system will be used.

3. Data Flow Diagrams (DFD):

o Shows how data moves through the system and how different entities interact
with the system.

o DFDs can help in understanding and documenting the flow of information.

4. Entity-Relationship Diagrams (ERD):

o Shows the relationships between entities in the system’s database.

o Helps in modeling the data structure and identifying important system

components.

5. User Stories (Agile Methodology):

Page 6 of 10
 o Short, informal descriptions of features or system functions from the
perspective of the end-user.

o Often used in Agile development to capture requirements in a simpler, more

user-focused manner.

6. Analyzing and Validating Requirements

Verification and Validation in Systems Analysis

 Verification and Validation are two important concepts in systems analysis and
software development that ensure the system meets the required standards
and performs as expected.
Verification:
 Meaning: Verification is the process of evaluating a system or its components to
ensure that it complies with the specified requirements. It answers the question,
"Are we building the system, right?"
 Focus: It checks whether the system was designed and built correctly according to
the specifications.
 Activities: It involves reviews, inspections, walkthroughs, and other formal methods
to ensure that the product is developed according to the specifications.
 Example:
In a banking software system, verification would involve checking if the system
correctly implements the requirement that users can log in using a username and
password. This includes reviewing the code to ensure that the login functionality
matches the design and specification documents.

Validation:

 Meaning: Validation is the process of evaluating a system during or at the end

of the development process to determine if it satisfies the intended business
needs and requirements. It answers the question, "Are we building the right
system?"
 Focus: It ensures that the system fulfills the objectives and requirements set by
the stakeholders and the business.
 Activities: It typically involves user testing, acceptance testing, and feedback
from stakeholders to ensure that the system meets their needs.
 Example:
In the same banking software system, validation would involve testing the login
feature with real users to ensure it meets their needs, such as ensuring that it
is user-friendly, secure, and works under various conditions.

Page 7 of 10
Once requirements are gathered, they must be analyzed and validated to ensure they are:

1. Complete: All necessary requirements are included.

2. Consistent: No conflicting requirements are present.

3. Feasible: Requirements are achievable within the project’s time, budget, and
technology constraints.

4. Verifiable: There must be a way to verify the requirement has been met during testing.

5. Unambiguous: Requirements should be clear and not open to multiple interpretations.

Functional Requirements:

 Patient Registration: The system should allow receptionists to register new patients,
capturing details like name, age, medical history, and contact information.

 Appointment Scheduling: Patients and staff should be able to schedule, modify, and
cancel appointments. It should avoid double-booking and send reminders to patients.

 Medical Records Management: The system must store and organize patient medical
records, including diagnosis, treatment history, prescriptions, and lab results.

 Billing and Insurance: The system should generate invoices based on services provided,
handle insurance claims, and allow payment processing.

 Staff Scheduling: The system should manage schedules for doctors, nurses, and other
medical staff, allowing them to request leave and shift changes.

Non-Functional Requirements:

 Security: Patient data must be securely stored and transmitted, following healthcare
privacy regulations (e.g., HIPAA).

 Scalability: The system should support scaling as the hospital grows, allowing for more
patients and staff to be added over time.

 Usability: The user interface must be simple and intuitive for non-technical users (e.g.,
receptionists, nurses).

 Performance: The system must provide real-time access to patient data and minimize
delays in processing information.

 Compliance: The system must comply with healthcare standards and regulations,
including data retention and auditing requirements.

Page 8 of 10
Validation Techniques:

 Review Meetings: Requirements are reviewed by stakeholders, such as the

development team, clients, and end-users.

 Prototyping: Prototypes are used to clarify requirements by allowing users to interact

with early versions of the system.

 Test Cases: Test cases are created to check if the requirements can be verified during
the testing phase.

6. Managing Requirements

Effective management of requirements is essential for successful project execution. This

includes:

1. Traceability:

o Keeping track of the origin of each requirement, ensuring that it is implemented

in the design and testing phases.

2. Version Control:

o As requirements can evolve over time, maintaining a version-controlled

document ensures the team works with the most up-to-date version.

3. Change Management:

o Managing any changes to requirements throughout the project. This includes

assessing the impact of changes, obtaining approval, and updating
documentation.

4. Prioritization:

o Not all requirements are of equal importance. Prioritizing them helps focus on
the critical functionalities first, often using techniques like MoSCoW (Must have,
should have, Could have, Won't have).

7. Tools for Requirements Gathering and Analysis

Several software tools can help with requirements gathering, documentation, and analysis:

Page 9 of 10
 1. Microsoft Visio: Often used for creating diagrams, such as DFDs, ERDs, and use case
diagrams.

2. IBM Rational RequisitePro: A requirements management tool used to capture and track
requirements.

3. JIRA: A popular tool in Agile environments for managing user stories and requirements.

4. Balsamiq or Axure: Tools for creating wireframes or prototypes to validate

requirements with stakeholders.

5. Enterprise Architect: A tool used for modeling and designing system architectures and
requirements.

8. Challenges in Requirements Gathering and Analysis

1. Elicitation Difficulties:

o Users may not know what they want or may struggle to articulate their needs.

2. Ambiguities and Misunderstandings:

o Ambiguous language or lack of clear communication can lead to incorrect or

misunderstood requirements.

3. Scope Creep:

o As requirements evolve during the project, new features or changes can be

added without proper evaluation, leading to delays or cost overruns.

4. Stakeholder Conflicts:

o Different stakeholders may have conflicting requirements, making it difficult to

find consensus.

Lesson 2 Revision Questions

1. Explain why requirements gathering is important in the software development

process.
2. What are the potential consequences of insufficient or poorly collected
requirements?
3. Discuss the purpose of using models (such as Data Flow Diagrams, Entity
Relationship Diagrams, or UML) in requirements analysis.
4. What are some methods for prioritizing requirements (e.g., MoSCoW method,
Kano model)?

Page 10 of 10