How does observation differ from other research methods?

Observation captures real user behavior rather than relying on self‑reports. This provides insight into actual workflow patterns, including shortcuts or informal practices. It is especially valuable when users may not articulate all steps.

What is the key distinction between functional and non-functional requirements?

Functional requirements define what the system must do, such as tasks or processes. Non‑functional requirements describe qualities like speed, usability, or reliability. Both are needed to create a system that works well in practice.

How do interviews and questionnaires differ in purpose?

Interviews provide detailed insights by allowing follow‑up questions and clarification. Questionnaires gather broad feedback quickly from large groups. The choice depends on the depth and scale of information required.

What mistake occurs when analysts rely on only one research method?

Using only one method risks capturing a narrow or biased view of the system. Mixing methods allows triangulation, increasing accuracy and reducing blind spots. Analysts should always combine at least two complementary techniques.

Why is it an error to document symptoms instead of underlying problems?

Symptoms may describe inconveniences or errors users encounter, but they rarely reveal the root cause. Addressing only symptoms often leads to temporary fixes rather than meaningful system changes. Proper analysis identifies the underlying cause.

Why is assuming users accurately describe workflows a mistake?

Users often omit steps that feel routine or unimportant, even when those steps are crucial to system operation. This can mislead analysts into designing incomplete processes. Observation helps correct this gap.

What is a functional requirement?

A functional requirement specifies a task or behavior the system must perform. It describes how the system should respond to inputs or user actions. Such requirements guide the core features of the new system.

What are information requirements?

Information requirements describe the data a system must capture, store, process, and output. They ensure the system supports accurate and efficient information flow. This helps prevent data gaps and inconsistencies.

What is the purpose of a requirements specification?

A requirements specification summarizes all findings from the analysis stage. It describes what the new system must achieve and sets constraints for its design. This prevents misunderstandings later in development.

Why are Data Flow Diagrams useful during analysis?

DFDs show how information moves through a system, making invisible processes visible. By mapping data inputs, outputs, and transformations, analysts can identify inefficiencies. This supports clearer system redesign.

The Systems Life Cycle: Analysis | Cambridge International Examinations IGCSE ICT

1. Definition and Core Concepts

Systems analysis is the first major stage of the systems life cycle in which analysts investigate an existing system to determine how it works, what problems exist, and what users need from an improved version. This stage is essential because decisions made here directly influence the success of all later stages.
Stakeholder requirements refer to the set of needs, expectations, and constraints expressed by individuals or groups who will use or be affected by the system. Collecting these ensures the new system is aligned with practical, operational, and strategic goals.
Functional requirements describe what the system must do, such as tasks, processes, and outputs. This enables designers to later translate real-world tasks into system behaviors.
Information requirements specify the data the system must capture, process, store, and output. Understanding these ensures that the new system supports accurate, efficient information flow.
Analysis of the current system involves studying inputs, outputs, processing, and problems so that the new system can address deficiencies rather than recreate them.

A simple diagram illustrating inputs flowing into processing and producing outputs.

2. Underlying Principles

Systematic investigation ensures that analysis follows a logical, structured approach rather than relying on assumptions. This principle minimises the risk of designing a system that fails to meet real user needs.
Triangulation of data sources strengthens accuracy by comparing findings from multiple research methods. When different methods reveal the same issues, analysts can be confident the problem is genuine.
User-centered analysis emphasises the idea that systems must match human workflows rather than forcing users to adapt to poorly designed processes. This principle guides analysts to prioritize usability and operational efficiency.
Abstraction and decomposition allow complex systems to be broken into manageable parts such as inputs, processes, outputs, and user interactions. This makes it easier to identify bottlenecks and opportunities for improvement.
Feasibility thinking involves early consideration of practical constraints—such as budget, technical limits, and resource availability—so that requirements remain realistic and achievable.

3. Methods and Techniques

Observation involves watching users interact with the current system to understand authentic workflows. This method is valuable because it reveals actions users may not mention in interviews, especially routine shortcuts or workarounds.
Interviews involve structured conversations where analysts ask probing questions to uncover hidden requirements and deeper insights. Interviews are best used when detailed explanations or clarifications are needed.
Questionnaires gather information from large groups quickly using standardized questions. They help reveal trends and general attitudes, especially when anonymity encourages honest responses.
Document examination involves reviewing existing records, forms, manuals, and logs. This method reveals formal procedures, data structures, and operational constraints that may not be visible in day‑to‑day activity.
Data Flow Diagrams (DFDs) model how data moves through the system, showing inputs, processes, data stores, and outputs. They help analysts visualize inefficiencies and understand how information is transformed.

4. Key Distinctions

Comparison of Research Methods

Feature	Observation	Interviews	Questionnaires	Document Analysis
Best for	Real behavior	Deep insights	Large groups	Formal structure
Weakness	Observer effect	Time‑intensive	Low detail	May be outdated

Functional vs non-functional requirements differ in purpose: functional requirements specify what the system must do, while non‑functional requirements define quality attributes such as reliability, usability, or performance. Understanding both ensures the new system is both effective and efficient.
User requirements vs information requirements help distinguish between what users want to accomplish and what data the system must manage. Keeping these separate prevents confusion between actions and data needs.
Current issues vs future needs must be distinguished so the new system does not merely replicate existing workflows but supports long‑term improvements.

5. Exam Strategy and Tips

Identify the most suitable research method based on user characteristics, such as availability, group size, or need for detail. Exams often test the ability to match methods to scenarios.
Clarify whether a question refers to user requirements or system requirements, as mixing these leads to vague answers. Always specify what the user wants to achieve and how the system will support it.
When describing analysis tasks, include inputs, outputs, processing steps, and problems. Examiners expect full coverage rather than partial descriptions.
Use precise terminology such as "processing", "data flow", or "functional requirement" to show technical understanding. Vague language suggests weak conceptual grasp.
Always justify research method choices by linking the method to the situation—such as the need for anonymity, speed, depth, or accuracy.

6. Common Pitfalls and Misconceptions

Assuming users always describe their behavior accurately is a misconception; many real workflows rely on undocumented shortcuts. Analysts must confirm statements with observation or documentation.
Believing the current system must be replicated ignores the purpose of analysis, which is to identify improvements. A new system should solve problems, not preserve them.
Confusing problems with symptoms leads analysts to propose fixes that address surface issues but not underlying causes. Correct analysis requires examining workflow logic and data needs.
Over‑reliance on a single research method can produce biased or incomplete requirements. A balanced combination yields more accurate insights.
Assuming technical constraints are secondary overlooks how limitations affect feasibility. Realistic solutions depend on early constraint identification.

7. Connections and Extensions

Analysis connects directly to the design stage, where findings such as data requirements and process summaries guide file structures, interfaces, and validation routines.
Analysis principles apply beyond ICT, such as in business process improvement or workflow redesign. The same logic—understand before changing—applies universally.
Well-structured analysis supports testing, because clear requirements make it easier to define expected outcomes for test plans.
Analysis contributes to evaluation, since final system performance is judged against the requirements documented in this stage.
Modelling tools like DFDs extend into advanced topics, such as system architecture mapping and process optimization.

The Systems Life Cycle: Analysis

Summary

1. Definition and Core Concepts

2. Underlying Principles

3. Methods and Techniques

4. Key Distinctions

5. Exam Strategy and Tips

6. Common Pitfalls and Misconceptions

7. Connections and Extensions

The Systems Life Cycle: Analysis

Summary

1. Definition and Core Concepts

2. Underlying Principles

3. Methods and Techniques

4. Key Distinctions

Comparison of Research Methods

5. Exam Strategy and Tips

6. Common Pitfalls and Misconceptions

7. Connections and Extensions

Comparison of Research Methods