UNIT 1: FACT FINDING TECHNIQUES

1. What is Fact Finding?

Fact finding (also called information gathering or data collection) is the process of discovering and documenting facts about the current system, user needs, business processes, constraints, and stakeholder expectations.

Purpose: To replace assumptions, opinions, and guesses with verifiable truth before designing a new system.

1.1 Why Fact Finding is Critical

• Avoids “analysis paralysis” – Provides structured ways to gather data.
• Reduces rework – Correct facts early prevent costly changes later.
• Builds stakeholder trust – Users see that their input matters.
• Supports all SAD phases – Feasibility, requirements, design, testing.

1.2 Types of Facts Needed

2. Common Fact Finding Techniques

There are seven core techniques. Each has strengths and weaknesses. Use a combination for triangulation.

3. Technique 1: Interview

3.1 Definition

A face-to-face or remote conversation between an analyst and a stakeholder to gather information.

3.2 Types of Interviews

3.3 Step-by-Step Interview Process

1. Planning

   • Define objective (e.g., “Understand inventory reorder process”)
   • Select interviewees (managers, operators, customers)
   • Schedule 30–60 minutes
   • Prepare question list

2. Question Design (avoid common errors)

   • Open-ended: “Describe the steps when a customer returns a product.”
   • Closed-ended: “Do you use the return form? Yes/No.”
   • Probing: “You mentioned delays. Can you give an example?”
   • Avoid leading: ❌ “Don’t you think the system is slow?” → ✅ “How would you rate system response time?”

3. Conducting the Interview

   • Start with rapport (thank, explain purpose, confidentiality)
   • Listen more than talk (80/20 rule)
   • Take notes or record (with permission)
   • Use active listening: “What I hear you saying is…”

4. Post-Interview

   • Write summary within 24 hours
   • Send to interviewee for validation
   • Extract facts and requirements

3.4 Advantages & Disadvantages

3.5 Example Interview Question Set (for a Library System)

Objective: Understand book borrowing process.

• Open: “Walk me through what happens when a member brings a book to the counter.”
• Closed: “Does the system automatically calculate the due date? Yes/No.”
• Probing: “You mentioned fines – how are they calculated? Are there exceptions?”
• Opinion: “What is the biggest frustration with the current system?”

4. Technique 2: Questionnaire / Survey

4.1 Definition

A set of written questions distributed to many people (often geographically dispersed) to collect standardized data.

4.2 When to Use

• Large number of stakeholders (100+)
• Need for statistical validity
• Sensitive topics where anonymity is desired
• Preliminary fact gathering before interviews

4.3 Types of Questions

4.4 Designing an Effective Questionnaire

Rules:

• Keep it short (10–15 questions, <10 minutes)
• Use simple, unambiguous language
• Group related questions
• Avoid double-barreled questions (e.g., “Do you like the speed and reliability?” – two separate issues)
• Pilot test with 2–3 users

Example structure:

• Demographics (role, department, experience)
• Current system usage (frequency, tasks)
• Satisfaction ratings (scale)
• Problems (checkboxes + open “other”)
• Future needs (priorities)

4.5 Advantages & Disadvantages

4.6 Response Rate Improvement Tips

• Offer small incentive (gift card, donation)
• Send reminder after 1 week
• Keep it very short
• Explain how results will be used
• Get endorsement from a manager

5. Technique 3: Observation

5.1 Definition

Watching users perform their actual work in their real environment, without interfering (or with minimal interference).

5.2 Types of Observation

5.3 Structured Observation Methods

• Time and motion logs – Record how long each task takes.
• Work sampling – Observe at random intervals (e.g., every 30 minutes) and note what the user is doing.
• Video recording (with permission) – Allows review later.

5.4 Steps

1. Get permission from management and users (explain purpose, confidentiality).
2. Schedule observation during typical and peak periods.
3. Prepare a checklist of what to look for (e.g., steps, delays, errors, workarounds).
4. Observe without judging – users may be nervous.
5. Take detailed notes – include timestamps, screens, physical actions.
6. Follow up with users to clarify anything seen.

5.5 Advantages & Disadvantages

5.6 Example Observation Checklist (Warehouse Picking)

6. Technique 4: Document Analysis

6.1 Definition

Examining existing written materials that describe the current system, business rules, data, or procedures.

6.2 Types of Documents to Analyze

6.3 How to Perform Document Analysis

1. Collect all relevant documents (ask users: “What forms do you fill out?”)
2. Scan for obvious facts (data elements, rules, frequencies).
3. Analyze in detail:
   • For a form: list every field, its source, validation rules, optional/mandatory.
   • For a report: who uses it, when, why, and what decisions are based on it.
4. Look for discrepancies between what documents say and what users do (indicates outdated procedures).
5. Extract requirements (e.g., “The form has a field for ‘Tax ID’ → system must capture tax ID.”)

6.4 Advantages & Disadvantages

6.5 Example: Analyzing an Expense Report Form

Form fields: Employee name, date, description, amount, client code, manager signature.
Findings:

• “Client code” is a free text field but users often write “N/A” → missing validation.
• Manager signature is handwritten → no digital approval workflow.
• No field for receipt attachment → users keep paper receipts.
  Requirements derived:
• Client code must be selected from a validated list.
• Digital approval with audit trail.
• Receipt image upload.

7. Technique 5: Sampling

7.1 Definition

Selecting a representative subset of data or transactions to analyze, rather than examining every single instance.

7.2 When to Use

• Large volume of transactions (e.g., 1 million invoices per year)
• Need to understand error rates or patterns
• Time or budget constraints

7.3 Sampling Methods

7.4 Determining Sample Size

Rule of thumb for SAD:

• For error rate estimation: at least 30–50 items.
• For process discovery: 10–20 typical examples + 5 edge cases.
• Use formula for confidence level: n = [Z^2 * p(1-p)] / e^2 (simplified: for 95% confidence, 5% margin, use ~400 for large populations).

7.5 Advantages & Disadvantages

7.6 Example: Sampling Customer Complaints

Population: 5,000 complaints last year.
Sample: 200 randomly selected.
Analysis reveals: 40% are about slow delivery, 30% about wrong items, 20% about website errors, 10% other.
Conclusion: Focus requirements on delivery tracking and inventory accuracy.

8. Technique 6: Research / Benchmarking

8.1 Definition

Studying external sources to learn about best practices, industry standards, available technologies, or competitor systems.

8.2 Sources of Research

8.3 Benchmarking Process

1. Identify what to benchmark (e.g., order processing time, customer satisfaction score).
2. Find comparable organizations (same industry, similar size).
3. Collect data (surveys, public reports, site visits).
4. Compare your current metrics to the benchmark.
5. Set target requirements based on best-in-class.

8.4 Advantages & Disadvantages

8.5 Example: Benchmarking for a Help Desk System

Benchmark data (industry average):

• First response time: 2 hours.
• Resolution time: 24 hours.
• Customer satisfaction: 85%.
  Current system: 8 hours first response, 72 hours resolution, 60% satisfaction.
  Requirement: “First response time shall not exceed 2 hours for high-priority tickets.”

9. Technique 7: Workshop / JAD (Joint Application Development)

9.1 Definition

A facilitated, structured meeting that brings together key stakeholders (users, managers, analysts, developers) for a short, intensive period (1–5 days) to define requirements or solve problems.

9.2 JAD Roles

9.3 JAD Session Structure (Typical 3-day)

• Day 1: Orientation, scope definition, high-level processes. Identify actors and use cases.
• Day 2: Detail use cases, business rules, exception flows. Prototyping (paper or digital).
• Day 3: Prioritize requirements (MoSCoW). Identify conflicts and resolve. Draft SRS outline.

9.4 Advantages & Disadvantages

9.5 JAD Success Factors

• Clear objectives and agenda shared beforehand.
• Right participants (decision-makers must be present).
• Neutral facilitator (not the analyst).
• Comfortable, off-site location if possible.
• Follow-up within 48 hours.

10. Selecting the Right Fact Finding Technique(s)

No single technique is sufficient. Use a multi-method approach.

10.1 Decision Matrix

10.2 Fact Finding Plan Template

11. Documenting Fact Finding Results

Always organize findings. Common formats:

11.1 Fact Finding Summary Table

11.2 Requirements Log (Traceable to Facts)

11.3 Action Log for Follow-up

12. Common Pitfalls in Fact Finding

• Relying on only one technique – Biased or incomplete facts. Use triangulation (3+ methods).
• Asking leading questions – False confirmation of your own assumptions. Use neutral, open-ended wording.
• Not documenting as you go – Forgetting details; relying on memory.
• Interviewing only managers – Missing operational realities. Always interview frontline users.
• Observing only during normal periods – Missing peak load problems.
• Ignoring “silent” stakeholders (e.g., IT operations) – Non-functional requirements missed.
• No follow-up validation – Misinterpreted facts cause wrong requirements.

13. Summary Table – Fact Finding Techniques at a Glance

14. Real-World Example: Fact Finding for a Hospital Patient Registration System

Context: A hospital wants to reduce patient wait time during registration. Current process is paper-based.

Key requirements derived:

• Auto-verification with insurance API.
• Tablet self-check-in for returning patients.
• Real-time patient data to nurse station.
• Registration time ≤ 3 minutes for 90% of patients.

15. Key Takeaways

• Fact finding is the foundation of all SAD work. Garbage in = garbage out.
• Use multiple techniques to cross-check facts (triangulation).
• Talk to all levels – managers, users, technical staff, and support.
• Watch what people do, not just what they say (observation is powerful).
• Document everything with traceability from fact to requirement.
• Validate your findings with stakeholders before moving to design.