Lesson 3: Requirements Engineering and Fact-Finding

A requirement is a condition or capability needed by users or the organization. Requirements must be clear enough that the team can design, build, and test the system correctly.

Two major categories appear often in exams.

Functional requirements

These describe what the system should do. Examples:

• The system shall allow students to book clinic appointments.
• The system shall generate daily inventory reports.
• The system shall send an approval notification to the applicant.

Functional requirements are about services, tasks, and behavior.

Nonfunctional requirements

These describe how well the system should perform or under what conditions it should operate. Examples:

• The system shall respond to search queries within 3 seconds.
• The system shall be available from 7:00 AM to 7:00 PM on weekdays.
• The system shall restrict access using role-based permissions.
• The system shall support mobile viewing on standard smartphone browsers.

Nonfunctional requirements often cover:

Another important item is the business rule — a policy or condition that shapes the system. Examples:

• A student cannot enroll with an unsettled balance.
• Only the department head can approve bulk inventory adjustments.
• A loan request above ₱50,000 requires two levels of approval.

Business rules are not optional details. They often decide whether the system is acceptable in real operations.

Requirements do not appear by magic. They are gathered through fact-finding, also called elicitation.

Interview

Direct conversation with users or managers. Best for: deep understanding, clarifying exceptions, learning pain points and priorities. Tips: prepare questions, ask about actual work (not only desired features), confirm understanding before ending.

Observation

Watch how work is actually performed. Best for: detecting real behavior, exposing hidden workarounds, identifying delays. Users sometimes forget steps they do automatically; observation catches those.

Questionnaire or survey

Useful when many respondents are involved. Best for: quick gathering of preferences, measuring common issues, structured responses.

Document analysis

Review forms, reports, manuals, spreadsheets, logs, and policies. Best for: understanding data fields, identifying current outputs, finding compliance rules.

Workshop or JAD-style session

A structured meeting with users, managers, and analysts. Best for: resolving conflicts, speeding up requirement agreement, producing shared understanding.

Prototyping

Show a draft screen or workflow and collect reactions. Best for: interface-heavy systems; users who find it easier to react than to describe.

A strong analyst usually combines methods. For example, interviews plus document review plus observation often produce more reliable requirements than any single method alone.