Unit-3

Analysis
Introduction to System Requirements
System requirements define what the system must do and how it must
perform. It is the process of uncovering the needs of the stakeholders and
translating them into a set of specifications.

System requirements are the primary "contract" between the developers and
the stakeholders. If this phase fails, the project fails.

The Goal: To translate vague business needs into precise technical

specifications.

•Functional Requirements: Describe the specific behaviors or functions of

the system (e.g., "The system must generate a monthly sales report").
•Non-Functional Requirements: Describe the quality attributes or
constraints (e.g., "The system must load within 2 seconds").
Performing Requirement Determination
Requirement determination is the bridge between the current system and the
proposed new system. It involves gathering data from users, managers, and
existing documentation.

This is the "investigative" phase. Analysts must act like detectives to find the truth
behind what users say they want vs. what they actually need.

•Characteristics of Good Requirements:

• Consistent: No two requirements contradict each other.
• Complete: No missing logic (e.g., what happens if the payment fails?).
• Traceable: Every requirement can be tracked back to a business need.

The Key Deliverables:

•Context Diagrams: To show system boundaries.
•Requirement Specifications: A formal document (SRS) listing all features.
•Process Models: Showing how data flows through the system.
Traditional Methods for Determining Requirements
These are manual, human-centric techniques for gathering data.

•Interviews: The most common method.

• Structured: Fixed questions.
• Unstructured: Open-ended conversations.
•Questionnaires: Useful for broad feedback (e.g., asking 500 bank tellers about a
new interface).
•Observation (Ethnography): Watching a user's workflow to see "workarounds"
they might forget to mention in interviews.
•Document Analysis: Studying existing "artifacts" like invoices, organizational
charts, and policy manuals.
Contemporary Methods for Determining Requirements
Modern methods focus on speed and group collaboration to reduce the time
spent in the analysis phase.
Contemporary methods focus on reducing the "gap" between users and IT by
bringing them into the same room.

1. Joint Application Design (JAD): * Participants: Users, Managers,

Systems Analysts, and a "Scribe."
Result: A massive reduction in the time taken to finalize requirements
(weeks turned into days).
2. Prototyping: * Evolutionary: The prototype eventually becomes the real
system.
Throwaway: Used only to confirm requirements, then discarded.
3. CASE Tools (Computer-Aided Software Engineering): Software that
helps draw diagrams (like UML) and maintains a central repository of
requirements.
Radical Methods for Determining System Requirements
These methods are used when a business needs a complete overhaul rather than
incremental change.
Radical methods don't just "fix" a system; they rethink the business from scratch.
The "Clean Slate" Approach: If we started this company today with modern tech,
how would we do it?
• Business Process Reengineering (BPR): The search for, and implementation
of, radical change in business processes to achieve breakthrough improvements
in products and services.
Example (Banking): Instead of moving a paper file through 5 desks, use a
centralized digital workflow where all departments work on the same file
simultaneously.

• Disruptive Technologies: Forcing the requirement to include tech like IoT or

Blockchain to create a competitive advantage that didn't exist before.
Requirement Management Tools
In large-scale projects (like building an aircraft or a global banking app), a simple
document isn't enough.
Requirement management is about handling change. In a project with 2,000
requirements, you cannot use a Word document.

Traceability Matrix (RTM): A table that ensures every requirement is tested. If

Requirement #10 says "Must support French," the RTM points to Test Case #45
"Verify French Translation.“

Versioning: Tracking who changed a requirement and why.

•Common Tools:
• Jira: For task-based requirement tracking.
• IBM DOORS: For high-compliance industries (Aerospace, Medical).
• Jama Connect: For complex product development.
Requirement Determination using Agile Methodologies
Agile shifts the focus from "up-front" heavy documentation to continuous discovery.
Agile replaces the "Big Up-Front Design" with "Just-in-Time" requirements.

User Stories: Written on index cards or digital boards.

Format: "As a [User], I want [Feature], so that [Value].“

The Backlog: A living document of all features. The Product Owner prioritizes the
most valuable items to the top.

MoSCoW Prioritization:
M: Must have.
S: Should have.
C: Could have (Nice to have).
W: Won't have (this time).
Introduction to System Process Requirements
System process requirements define what the system must do (the functions) and how data
moves through it. Unlike business requirements, which focus on goals (e.g., "We need to
process payments faster"), process requirements focus on the logic: the inputs, the
transformations, and the outputs.
The primary goal is to eliminate ambiguity between stakeholders and developers by creating a
"single source of truth" for the system's behavior.

Process Modeling
Process modeling is the graphical representation of an organization’s business processes. It
maps out the workflows so that anyone can understand the sequence of events.
•As-Is vs. To-Be: Modeling helps identify the current state of a process (As-Is) and the
proposed optimized version (To-Be).
•Standardization: Most professionals use BPMN (Business Process Model and Notation),
which uses standardized symbols like circles for events, rectangles for activities, and diamonds
for decision points.
•Purpose: It identifies bottlenecks, manual steps that can be automated, and potential points of
failure.
Data Flow Diagrammatic (DFD) Mechanics
Data Flow Diagrams (DFD) are the backbone of process requirements. They visualize how data
enters a system, how it is modified, and where it is stored.

The Four Essential Components

To create or read a DFD, you must understand these four symbols:

Component Symbol Description

Sources or destinations of
External Entity Square/Rectangle data (e.g., a Customer, a
Bank).
The "work" being done (e.g.,
Process Circle/Rounded Box "Calculate Tax," "Verify
Password").
Where data sits at rest (e.g.,
Data Store Open Rectangle
a Database, a File, a Folder).
The path data takes between
Data Flow Arrow
the other three components.
DFD Levels (The "Drill-Down" Method)
DFDs are organized into levels to manage complexity:
[Link] 0 (Context Diagram): A high-level view showing the entire system as a single process
and its relationship with external entities.
[Link] 1 (Overview Diagram): Breaks the system into major sub-processes.
[Link] 2 (Detailed Diagram): Breaks Level 1 processes into even finer functional steps.

Rules of DFD Mechanics

•No "Miracles": A process cannot have output data without input data.
•No "Black Holes": A process cannot have input data without producing an output.
•Data Consistency: Data must stay consistent across levels (e.g., if "Customer Info" enters the
system at Level 0, it must appear in the breakdown at Level 1).
Using DFD in the Analysis Process
During analysis, DFDs are used to partition the system into manageable functional components. The
"analysis" happens through Decomposition:
•Context Diagram (Level 0): Used to define the scope and boundaries with stakeholders. It
identifies every external entity (people or other systems) that interacts with your system.
•Level 1 DFD: Breaks the system into its major high-level functions. At this stage, you begin to
identify the primary Data Stores (where information "rests").
•Level 2+ DFDs: These are "child diagrams" that zoom into a single process from Level 1 to show its
inner workings.
• Analytic Tip: If a process has too many inputs and outputs (more than 7), it's a sign that the
process is too complex and needs to be decomposed further.

DFD Example: The "Route" (Analysis)

During the analysis phase, we use the DFD to identify where data comes from and where it must go.
•Process 1.0 (Receive Application): The Customer submits a form.
•Process 2.0 (Evaluate Risk): The system pulls a Credit Score from an external Credit Bureau and
combines it with the application data.
•Process 3.0 (Determine Outcome): This is where the logic happens. It needs the Credit Score and
the Loan Amount to decide.
Modeling Logic with Decision Tables
A DFD shows that a process transforms input into output, but it doesn't show the logic (the "if/then"
rules). For complex processes, analysts use a Decision Table to document this logic.

When to use a Decision Table

You should use a Decision Table when a single DFD process involves:
•Multiple variables or conditions.
•Complex business rules (e.g., "If the customer is a Gold Member AND the order is over $100, apply a
20% discount, otherwise...").
•Scenarios where logic might be missed if written in plain text.
Decision Table Example: The "Judgment" (Modeling Logic)
When we get to Process 3.0 (Determine Outcome), a simple flowchart might get messy.
Instead, we use a Decision Table to map out the business rules for the loan officer or the
automated system.
Scenario: The "Bank’s Rulebook"
•Condition 1: Is the Credit Score > 700?
•Condition 2: Is the Loan Amount < $50,000?
•Condition 3: Does the user have a Co-signer?
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Credit Score > 700 Y Y N N
Loan Amount <
Y N - -
$50k
Has Co-signer? - - Y N
Actions
Approve Instantly X
Manual Review X X
How toReject
read this logic: X
•Rule 1: If the score is high and the loan is small, approve it immediately
regardless of a co-signer (the dash - means "doesn't matter").
•Rule 4: If the score is low and there is no co-signer, reject it immediately.
System Data Requirements

System data requirements define the specific information a system needs (sources, formats,
volume, quality) and how it should function (functional/non-functional), ensuring it meets business
goals, user needs, and technical standards for performance, security, and integration, acting as a
blueprint for design and development.

System data requirements define:

 What data is needed
 Where the data comes from
 How the data is stored
 How the data is processed
 How the data is output and used
They ensure that the system has accurate, timely, relevant, and sufficient data to support
operations and decision-making.
Key Types of Data Requirements
[Link] Data Requirements
Data that must be entered into the system.
[Link] Data Requirements
Rules and operations used to process the data.
[Link] Data Requirements
Information produced by the system (reports, results).
[Link] Data Requirements
How and where data is stored (files, databases).
[Link] Quality Requirements
Accuracy, completeness, consistency of data.
[Link] & Privacy Requirements
Data protection, access control, and confidentiality.
Example (Student Information System)
Data Requirements:
•Student ID, Name, Address
•Course details
•Marks and grades
•Attendance records
Quality Requirement:
•Student ID must be unique
•Marks must be between 0–100
 Conceptual Data Modeling
Conceptual data modeling is the very first step in designing a database or data system. It is a
high-level, business-focused view of "what" data is needed and how different pieces of information
relate to each other, without worrying about "how" it will be stored technically.

Think of it as the architect’s sketch of a house—it shows where the rooms are and how they
connect, but it doesn't specify the type of plumbing or the brand of the bricks.

Conceptual data modeling describes what data the system needs and how different data
entities are related, without worrying about how the data will be stored.
The Core Building Blocks
A conceptual model typically uses the Entity-Relationship (ER) Model and consists of three main
elements:
• Entities: The "nouns" of your system. These are the objects or concepts you want to track (e.g.,
Customer, Product, Order).
• Attributes: The "adjectives." These are properties that describe an entity (e.g., a Customer has a
Name, Email, and Address).
• Relationships: The "verbs." These define how entities interact (e.g., a Customer places an
Order).
Gathering Information for Conceptual Data Modeling
Gathering information for conceptual data modeling is the process of collecting and understanding
data requirements needed to identify entities, attributes, and relationships of a system.
It is a collaborative process focused on capturing the "what" rather than the "how."
Key Methods of Information Gathering What Information is Collected?
[Link] •Entities (e.g., Student, Course)
[Link] with users, managers, and stakeholders •Attributes (e.g., ID, Name, Marks)
[Link] data usage and business rules •Relationships (e.g., enrolls, teaches
[Link] / Surveys •Business rules and constraints
[Link] information from many users quickly
[Link] for standardized data requirements
[Link]
[Link] how current systems and users work Importance
[Link] identify actual data flow and data usage •Ensures accurate conceptual data mod
[Link] Review •Reduces errors in later design stag
[Link] existing forms, reports, files, and manuals
•Improves user satisfaction
[Link] data items and relationships
[Link] System Analysis
[Link] current databases and applications
[Link] find data redundancy and missing data
[Link] / Group Discussions
[Link] sessions with stakeholders
[Link] data definitions and resolves conflicts
Introduction to ER Model (Entity–Relationship Model)
The Entity–Relationship (ER) Model is a conceptual data model used to describe the structure
of a database by representing data as entities, attributes, and relationships.
The Three Core Components
The ER model is built using three primary building blocks. In an ER Diagram (ERD), these are
represented by specific shapes:
Component Description ERD Shape Example
Student, Course,
Entity A "thing" or object in the real world (nouns). Rectangle
Employee
Student_Name, Age,
Attribute A property or characteristic of an entity. Oval
Salary
To make the modelHow
more precise, designers use specialized Enrolls_in, Teaches,
Relationship two or more entities interact (verbs). types of these components:
Diamond
•Strong vs. Weak Entities: Works_at
•Strong Entity: Can exist on its own (e.g., Customer). It has a Primary Key.
•Weak Entity: Depends on another entity to exist (e.g., Dependent depends on Employee). It is shown with a
Double Rectangle.
•Types of Attributes:
•Key Attribute: Uniquely identifies an entity (e.g., Roll_Number). The text is underlined.
•Composite Attribute: Can be broken down into smaller parts (e.g., Address $\rightarrow$ Street, City, Zip).
•Multivalued Attribute: Can have more than one value (e.g., Phone_Number). Shown with a Double Oval.
•Derived Attribute: Calculated from others (e.g., Age from Date_of_Birth). Shown with a Dashed Oval.
Conceptual Data Modeling and the ER Model

Conceptual Data Modeling and the Entity–Relationship (ER) Model are closely related concepts
used in the early stage of database design to represent data requirements clearly.

Conceptual data modeling is the process of identifying what data is needed by a system and how
data items are related, without considering how the data will be stored.

The ER Model is a tool/technique used to perform conceptual data modeling.

Example
Conceptual Data Modeling:
Identify Student, Course, Teacher as required data.
ER Model:
Draw an ER diagram showing Student enrolls in Course.
[Link]
A supertype is a general entity that contains common attributes shared
by all its subtypes.
Example:
Person (PersonID, Name, Address)
2. Subtype
A subtype is a specialized entity that inherits attributes from the
supertype and may have its own unique attributes.
Example:
•Student (RollNo, Program)
•Teacher (EmployeeID, Salary)
Business Rules
Business rules are statements that define or constrain how data is used
and processed in an organization.
They reflect the policies, procedures, and constraints of the business.

Examples:
•A student can enroll in maximum 6 courses per semester.
•Employee ID must be unique.
•Marks must be between 0 and 100.

Role in Conceptual Data Modeling:

•Help identify entities, attributes, and relationships
•Define constraints (cardinality, participation)
•Ensure the data model reflects real business operations

Business rules guide the structure and constraints of the conceptual data
model.
Packaged Conceptual Data Models (Database Patterns)
Packaged conceptual data models, also called database patterns, are
predefined, reusable data models designed for common business domains.

Examples:
•Customer–Order model
•Employee–Department model
•Student–Course model

Role of Database Patterns

Speeds up design
Designers don’t start from scratch.
Ensures best practices
Based on proven and tested designs.
Improves consistency
Standard structure across systems.
Reduces errors
Fewer design mistakes.
Easy customization
Can be modified to fit specific business needs.