Coursify

Software Reverse Engineering: Meaning, Need, and Core Activities

Software Reverse Engineering: Meaning, Need, and Core Activities

Verified Sources
Sep 11, 2026

Software reverse engineering is the process of working backward from a deployed software product—such as a binary executable, mobile application, firmware image, or running service—to understand how it works. Unlike forward engineering, which transforms requirements into a new system, reverse engineering begins with an existing artifact and reconstructs knowledge about its requirements, design, algorithms, data structures, interfaces, and behavior.

The original source code and design documentation may be unavailable, incomplete, outdated, or deliberately obscured. Reverse engineering therefore uses evidence from several sources:

  • Executable code and machine instructions
  • Program metadata and file formats
  • Libraries and imported functions
  • Strings, configuration files, and embedded resources
  • Runtime behavior, memory state, and system calls
  • Network communication and external interfaces
  • Existing documentation, logs, and user observations

The objective is not necessarily to reproduce the original source code exactly. Rather, the objective is to create a sufficiently accurate model of the system so that engineers, security analysts, maintainers, or researchers can make informed decisions.

A useful conceptual model is:

Reverse engineering is legitimate in many contexts, including legacy-system maintenance, vulnerability research, malware analysis, debugging, interoperability, migration, and software assurance. However, authorization, licensing restrictions, intellectual-property law, and responsible disclosure requirements must be considered before analysis begins.

Footnotes

  1. Software Reverse Engineering & AI Source Code Analysis and Software Patent Disputes - Defines reverse engineering as analyzing compiled or deployed software to understand internal logic, architecture, and algorithms. ↩

  2. What is Reverse Engineering? - Discusses ethical considerations, authorization, intellectual property, and legitimate security purposes. ↩

Central idea

Reverse engineering does not magically recover the original source code. It reconstructs useful knowledge about an existing system from observable evidence.

Why is software reverse engineering required?

Software reverse engineering is required when the knowledge needed to maintain, secure, integrate, or evaluate a system is not available through ordinary documentation or source-code access. Its importance can be understood through several major objectives.

1. Maintaining legacy software

Many organizations depend on systems written years or decades ago. Their original developers may no longer be available, documentation may be missing, and the source code may use obsolete languages or build tools. Reverse engineering helps recover:

  • Module boundaries
  • Data formats
  • Control flow
  • External dependencies
  • Undocumented assumptions
  • Interfaces between old and new components

This recovered knowledge supports legacy modernization and reduces the risk of changing a critical system without understanding its dependencies.

2. Recovering missing documentation

Documentation frequently becomes inaccurate as software evolves. Reverse engineering can produce:

  • Architecture diagrams
  • Call graphs
  • Data-flow descriptions
  • Interface specifications
  • State-transition models
  • Configuration references
  • Operational runbooks

The result is often called redocumentation: documenting what the system actually does rather than what an old specification claims it does.

3. Debugging and fault diagnosis

When a defect appears in a binary-only product, reverse engineering can reveal:

  • The instruction sequence causing the failure
  • Invalid memory accesses
  • Incorrect assumptions about input
  • Error-handling paths
  • Race conditions or state errors
  • Compatibility problems with operating systems or hardware

A debugger and runtime trace can connect a visible failure to the internal path that produced it.

4. Security assessment

Security analysts reverse engineer software to identify vulnerabilities, suspicious behavior, insecure cryptographic use, privilege boundaries, and attack surfaces. In malware analysis, reverse engineering helps determine what malicious code does, how it persists, what data it collects, and how it communicates.

Important outputs may include:

  • Indicators of compromise
  • Behavioral signatures
  • Vulnerability reports
  • Detection rules
  • Patches or mitigations
  • Incident-response guidance

5. Malware analysis and incident response

Malware often arrives without source code and may be packed, encrypted, obfuscated, or designed to detect analysis. Reverse engineering allows analysts to reconstruct capabilities and determine impact. Carnegie Mellon’s Software Engineering Institute describes reverse engineering as a means of understanding what malware does, what it affects, and how it can be removed.

6. Interoperability and integration

A proprietary system may not publish enough information for another system to communicate with it. Reverse engineering can reveal:

  • File formats
  • Protocol messages
  • API conventions
  • Serialization rules
  • Authentication sequences
  • Device communication behavior

This supports interoperability and integration with compatible tools. The work must remain within applicable law, contracts, licenses, and permitted purposes.

7. Software migration and reimplementation

Organizations may need to move software to:

  • A new operating system
  • A different processor architecture
  • A cloud platform
  • A modern programming language
  • A replacement vendor
  • A safer or more maintainable architecture

Reverse engineering identifies externally visible behavior that the replacement must preserve. This is especially important when the old implementation is available only as a binary.

8. Quality assurance and software assurance

Reverse engineering can verify whether an implementation matches its stated requirements. It can expose:

  • Hidden functionality
  • Unused or dangerous components
  • Hard-coded credentials
  • Weak security controls
  • Unintended data collection
  • Unexpected third-party dependencies

9. Research, education, and compatibility testing

Researchers use reverse engineering to study compilers, operating systems, file formats, virtual machines, embedded devices, and software protection mechanisms. The same techniques help students understand how high-level constructs become machine-level operations.

Footnotes

  1. Reverse Engineering for Beginners: A Step-by-Step Guide to Analyzing Software - Describes reverse engineering applications in maintenance, modernization, documentation, security, and interoperability. ↩

  2. Reverse Engineering for Malware Analysis - Explains how reverse engineering helps determine malware behavior, impact, and removal strategies. ↩ ↩2

Common objectives of software reverse engineering

Relative emphasis varies by project; these values represent an instructional comparison, not industry market-share statistics.

Important distinctions

The main analytical perspectives

Black-box analysis

In black-box analysis, the analyst treats the software as an unknown component. Inputs are supplied and outputs, errors, timing, files, and network behavior are recorded.

Black-box analysis is useful when:

  • Source code is unavailable
  • Execution is possible but internal inspection is restricted
  • The goal is to characterize an interface
  • The analyst wants to avoid assumptions about implementation

Its limitation is that many internal paths remain invisible.

White-box analysis

In white-box analysis, the analyst examines internal structures directly. This may include source code, assembly, debug symbols, control-flow graphs, and data-flow relationships.

White-box analysis provides deeper insight but still has limitations when code is optimized, obfuscated, dynamically generated, or incomplete.

Gray-box analysis

Gray-box analysis combines both perspectives. An analyst may know the operating environment, API documentation, or some source modules while treating other components as opaque.

The three perspectives can be summarized as follows:

PerspectiveMain evidenceStrengthLimitation
Black boxInputs, outputs, observable behaviorLow assumptions; useful for interfacesInternal logic is hidden
White boxSource, binary, symbols, internal structuresDetailed implementation insightRequires access and interpretation
Gray boxPartial internals plus runtime behaviorPractical balance of depth and realismFindings may be incomplete

A disciplined reverse-engineering workflow

  1. 1
    Step 1

    State why the artifact is being analyzed: maintenance, security assessment, interoperability, migration, or research. Confirm ownership, permission, licensing, scope, and rules for handling discovered vulnerabilities.

  2. 2
    Step 2

    Collect the executable, libraries, firmware, configuration, documentation, logs, and test inputs. Record hashes, versions, timestamps, architecture, and acquisition sources so that findings are reproducible.

  3. 3
    Step 3

    Identify the file type, processor architecture, operating-system target, compiler clues, packing, encryption, embedded resources, imports, exports, and readable strings. Do not execute an unknown artifact on a production system.

  4. 4
    Step 4

    Disassemble instructions, decompile selected functions, identify entry points, construct control-flow and call graphs, inspect data references, and label functions according to their likely purpose.

  5. 5
    Step 5

    Prepare an isolated laboratory using snapshots, restricted networking, non-production credentials, monitoring, and a reversible state. Define the observations needed before running the artifact.

  6. 6
    Step 6

    Execute selected scenarios while recording processes, files, registry or configuration changes, memory, system calls, exceptions, network traffic, and user-visible effects.

  7. 7
    Step 7

    Map runtime events to functions and instructions. Use observed addresses, strings, API calls, and state changes to refine the static model and investigate unresolved paths.

  8. 8
    Step 8

    Describe modules, data structures, state transitions, algorithms, interfaces, trust boundaries, dependencies, and failure modes in a form that other engineers can review.

  9. 9
    Step 9

    Create test cases that distinguish competing explanations. Repeat observations across inputs and environments, compare versions, and record confidence levels for conclusions.

  10. 10
    Step 10

    Deliver documentation, compatibility specifications, defect diagnoses, vulnerability reports, detection rules, migration requirements, patches, or a controlled reimplementation.

  11. 11
    Step 11

    Maintain analysis notes, tool versions, hashes, screenshots, traces, and limitations. Report security findings to the responsible party using an appropriate coordinated-disclosure process.

Activities undertaken during software reverse engineering

Reverse engineering is not one operation. It is a collection of related activities performed iteratively. The order may change depending on the goal, artifact, and risk.

Activity 1: Scoping and threat modeling

The analyst first establishes:

  • What is known and unknown
  • What questions must be answered
  • Which artifacts are in scope
  • Whether execution is safe
  • Which findings would be high impact
  • What legal or contractual restrictions apply

For security work, threat modeling helps prioritize analysis around sensitive data, privilege boundaries, exposed interfaces, and trust relationships.

Activity 2: Artifact acquisition and preservation

The analyst gathers the original artifact and related evidence. Preservation is essential because later analysis may modify files, unpack content, alter timestamps, or change runtime state.

Typical records include:

  • Cryptographic hashes
  • File size and format
  • Version and build identifiers
  • Operating-system and processor architecture
  • Digital signatures
  • Source and acquisition date
  • Tool versions and analysis settings

Activity 3: File-format and platform identification

Before interpreting instructions, the analyst determines what the artifact is. Examples include:

  • Portable Executable files on Windows
  • ELF files on Unix-like systems
  • Mach-O files on Apple platforms
  • Android application packages
  • Java archives
  • Firmware images
  • Shared libraries
  • Scripts or bytecode

Incorrect architecture identification can make valid bytes appear to be meaningless instructions.

Activity 4: Triage and metadata extraction

Triage extracts inexpensive clues before intensive investigation.

Common triage actions include:

  • Listing imported and exported functions
  • Extracting strings
  • Examining section names and permissions
  • Identifying embedded resources
  • Detecting packers or compression
  • Reviewing certificates and signatures
  • Comparing the artifact with known versions
  • Finding configuration files and URLs

Triage does not prove what a program does. It produces hypotheses for further testing.

Activity 5: Disassembly

Disassembly represents binary instructions in assembly language. It exposes operations such as:

  • Register manipulation
  • Arithmetic and comparisons
  • Branches and loops
  • Function calls and returns
  • Memory reads and writes
  • System calls
  • Exception handling

Disassembly is close to the processor but far from the original programmer’s abstractions. Compiler optimization, inlining, register allocation, and removed symbols can make interpretation difficult.

Activity 6: Decompilation

Decompilation translates low-level instructions into C-like or language-specific pseudocode. It can make loops, conditions, structures, and function relationships easier to understand.

Decompiled output is an interpretation, not the original source. Variable names, comments, types, macros, formatting, and some control structures are normally lost. Analysts must validate decompiler output against assembly and runtime evidence.

Activity 7: Control-flow analysis

Control-flow analysis identifies:

  • Basic blocks
  • Conditional branches
  • Loops
  • Switch statements
  • Exception paths
  • Function entry and exit points

A control-flow graph provides a visual representation of these paths.

Activity 8: Call-graph and dependency analysis

A call graph helps reveal program organization. Dependency analysis identifies relationships with:

  • Operating-system APIs
  • Runtime libraries
  • Cryptographic libraries
  • Databases
  • Network services
  • Device drivers
  • Third-party components

These relationships help locate security-sensitive or business-critical functionality.

Activity 9: Data-flow and program-slicing analysis

Data-flow analysis follows information through variables, memory, functions, and modules.

A program slice removes unrelated code from an investigation. For example, a slice centered on a password variable can help identify:

  • Where the value enters the program
  • Whether it is validated
  • Whether it is encrypted
  • Where it is stored
  • Whether it is transmitted externally

NIST references program slicing as a technique relevant to reverse engineering and software maintenance research.

Activity 10: String, resource, and configuration analysis

Readable strings and embedded resources often expose useful clues:

  • Error messages
  • File paths
  • URLs and domain names
  • Registry keys
  • Command names
  • Protocol markers
  • Debug messages
  • User-interface text
  • Embedded certificates

Strings must be interpreted cautiously because they may be unused, generated, encrypted, or intentionally misleading.

Activity 11: Dynamic execution and behavioral observation

Dynamic analysis reveals facts that may be difficult to infer statically:

  • Actual execution paths
  • Runtime-decrypted code
  • Memory allocations
  • Loaded modules
  • File modifications
  • Process creation
  • Network connections
  • API calls
  • Exceptions
  • Timing-dependent behavior

Dynamic analysis should be conducted in an isolated environment because execution may alter systems, contact external infrastructure, destroy data, or trigger harmful payloads.

Activity 12: Debugging and breakpoint analysis

A debugger allows analysts to pause execution and inspect:

  • CPU registers
  • Stack frames
  • Heap objects
  • Memory buffers
  • Instruction pointers
  • Function arguments
  • Return values
  • Thread state

Breakpoint analysis is useful for confirming hypotheses, tracing sensitive operations, and examining code that is unpacked or generated only at runtime.

Activity 13: System-call and API tracing

API and system-call tracing records interactions between the program and its environment. Examples include:

  • Opening or modifying files
  • Creating processes
  • Accessing the registry or configuration store
  • Allocating memory
  • Loading libraries
  • Opening sockets
  • Changing permissions
  • Accessing devices

This activity connects internal logic to externally observable effects.

Activity 14: Network and protocol analysis

When a program communicates over a network, analysts inspect:

  • Destination addresses
  • Ports and protocols
  • Request and response structure
  • Serialization formats
  • Authentication exchanges
  • Encryption usage
  • Retry and timeout behavior
  • Command-and-control patterns

The purpose may be to document an undocumented protocol, diagnose integration failures, or identify suspicious communication.

Activity 15: Memory analysis

Memory inspection is especially important when software:

  • Decrypts content only at runtime
  • Unpacks itself
  • Uses dynamically generated code
  • Stores secrets temporarily
  • Modifies code in memory
  • Removes evidence from disk

Memory analysis can recover runtime strings, keys, unpacked modules, object structures, and execution state that are absent from the original file.

Activity 16: Obfuscation and anti-analysis assessment

Obfuscation may include:

  • Renamed or removed symbols
  • Control-flow flattening
  • Dead-code insertion
  • String encryption
  • Packing
  • Virtualized instructions
  • Indirect calls
  • Self-modifying code

Anti-debugging may alter behavior when a debugger, virtual machine, or sandbox is detected. Analysts compare static and dynamic evidence and document uncertainty rather than assuming that an incomplete trace represents the entire program.

Activity 17: Algorithm and data-structure recovery

Reverse engineers infer higher-level concepts from low-level evidence, such as:

  • Sorting and searching routines
  • Hashing and encryption operations
  • Compression
  • Parsers
  • State machines
  • Linked structures
  • Tables and indexes
  • Serialization formats

Recognizing standard compiler patterns and library functions can significantly reduce analysis time.

Activity 18: Vulnerability and weakness analysis

Security-focused reverse engineering searches for:

  • Unsafe memory operations
  • Integer overflow or truncation
  • Missing authentication
  • Improper authorization
  • Insecure deserialization
  • Weak cryptographic practices
  • Hard-coded secrets
  • Unsafe update mechanisms
  • Trust-boundary violations
  • Inadequate input validation

Findings should be reproduced safely, minimized to necessary evidence, and disclosed responsibly.

Activity 19: Architecture reconstruction

The analyst combines evidence into a system-level model. The model may describe:

  • Components and responsibilities
  • Communication paths
  • Data stores
  • Trust boundaries
  • Initialization sequence
  • State transitions
  • External dependencies
  • Error-handling behavior

This activity converts isolated observations into an explanation of how the whole system operates.

Activity 20: Documentation and knowledge transfer

The final documentation should distinguish:

  • Confirmed facts
  • Strong inferences
  • Open questions
  • Assumptions
  • Unreachable or untested paths
  • Tool limitations
  • Reproduction steps

Useful deliverables include annotated disassembly, architecture diagrams, API specifications, data dictionaries, test cases, vulnerability reports, and migration guidance.

Activity 21: Reimplementation, patching, or modernization

The reverse-engineering results may support:

  • A compatible replacement
  • A security patch
  • A wrapper or adapter
  • A new protocol implementation
  • A migrated data format
  • A modernized component
  • A detection or prevention rule

A replacement should be tested against externally observable requirements, including normal behavior, error behavior, boundary conditions, and performance expectations.

Footnotes

  1. Unravel: References to Program Slicing - Provides NIST references concerning program slicing and its use in reverse engineering and software maintenance. ↩

  2. Reverse Engineering: Static vs. Dynamic Analysis - Compares static and dynamic approaches, including their strengths, limitations, and safety considerations. ↩

Examines files, instructions, metadata, strings, control flow, data flow, and dependencies without executing the target. It is safer and can cover code that is not reached during a particular run, but it may be hindered by packing, encryption, obfuscation, missing symbols, and indirect control flow.

Footnotes

  1. Reverse Engineering: Static vs. Dynamic Analysis - Compares static and dynamic approaches, including their strengths, limitations, and safety considerations. ↩

How static and dynamic activities complement one another

Neither static nor dynamic analysis is universally sufficient.

Static analysis can inspect broad portions of a program, including branches that a test run never reaches. However, it may not reveal decrypted or generated code and can be confused by obfuscation.

Dynamic analysis shows what actually happened during selected executions. However, it can miss behavior guarded by a particular date, environment, user, input, or remote command. It can also be dangerous if isolation is inadequate.

A practical investigation uses an iterative loop:

For example:

  1. Static triage identifies a reference to a suspicious network API.
  2. A controlled run records when that API is called.
  3. The analyst maps the call to a function and identifies its input data.
  4. A data-flow slice traces the input back to configuration or user input.
  5. Additional tests determine whether the behavior is always active or conditional.

Execution safety

Never execute an unknown binary on a production machine or connected personal system. Use isolation, snapshots, restricted networking, disposable credentials, monitoring, and a recovery plan. Dynamic analysis can trigger destructive or self-propagating behavior.

Typical tools and their roles

Tools vary by platform and purpose, but the following categories are common:

Tool categoryPrimary purpose
File-identification utilitiesIdentify format, architecture, sections, and metadata
DisassemblersConvert machine code into assembly instructions
DecompilersProduce approximate high-level pseudocode
DebuggersPause execution and inspect registers, memory, and stack state
Static-analysis platformsBuild cross-references, graphs, and searchable program databases
SandboxesExecute suspicious software in an isolated environment
API and system-call tracersRecord interactions with the operating system
Network analyzersCapture and interpret communications
Memory-analysis toolsInspect runtime processes and memory images
Binary-diffing toolsCompare versions or variants
Emulators and virtual machinesReproduce target architectures or controlled environments

Tools do not replace reasoning. Automated output may contain incorrect function boundaries, wrong data types, misleading names, or incomplete paths. Human review and evidence correlation remain essential.

Evolution of a reverse-engineering investigation

Question and authorization

1. Scope

Define the purpose, boundaries, permitted artifacts, risks, and expected deliverables."

Artifact characterization

2. Triage

Identify format, architecture, version, metadata, dependencies, strings, resources, and possible protection mechanisms."

Code and structure recovery

3. Static model

Disassemble, decompile, label functions, build graphs, inspect data flow, and identify important components."

Runtime behavior

4. Controlled observation

Execute selected scenarios safely and record files, processes, memory, APIs, system calls, and network activity."

Evidence integration

5. Correlation

Relate runtime observations to static structures, test hypotheses, and resolve contradictions."

Actionable result

6. Delivery

Produce documentation, a vulnerability report, compatibility specification, patch, migration plan, or reimplementation requirements."

Challenges and limitations

Loss of original abstractions

Compilation removes or transforms names, comments, types, module boundaries, and formatting. Optimization may inline functions, eliminate variables, reorder operations, or merge code paths.

Obfuscation and packing

Obfuscation deliberately increases analytical cost. Packed programs may expose only a small loader statically and reveal their main code after execution.

Incomplete path coverage

Dynamic analysis observes only the paths triggered by selected inputs and environmental conditions. A clean run does not prove that no dangerous or unexpected behavior exists.

Architecture and environment dependence

Behavior may differ across processor architectures, operating systems, library versions, locale settings, permissions, hardware, or network availability.

Scale

Large applications may contain millions of instructions and numerous third-party components. Analysts therefore prioritize functions, use program slicing, automate repetitive tasks, and maintain an evidence-based knowledge base.

Ambiguous conclusions

A reverse-engineering result is often probabilistic. Analysts should state confidence and distinguish observations from interpretations.

Ethical and legal practice

A practical reasoning rule

Treat every conclusion as a hypothesis supported by evidence. Confirm important claims using at least two independent signals—for example, disassembly plus runtime tracing, or a string reference plus data-flow analysis.

Software reverse-engineering essentials

1 / 7
Question · Term

What is software reverse engineering?

Click to reveal
Answer · Definition

The systematic analysis of an existing software artifact to recover its design, implementation, behavior, architecture, and interfaces.

Key takeaways

  1. Software reverse engineering works backward from an existing artifact to recover useful knowledge about its implementation and behavior.
  2. It is required for maintenance, documentation recovery, debugging, security analysis, malware investigation, interoperability, migration, and software assurance.
  3. The main activities include scoping, artifact preservation, triage, disassembly, decompilation, control-flow analysis, data-flow analysis, debugging, dynamic observation, memory and network analysis, architecture reconstruction, validation, and documentation.
  4. Static analysis provides broad structural insight; dynamic analysis provides evidence of actual runtime behavior. Their combination is usually stronger than either alone.
  5. Reverse engineering is an evidence-driven activity. Tool output must be interpreted, tested, documented, and assigned an appropriate confidence level.
  6. Authorization, isolation, intellectual-property awareness, privacy protection, and responsible disclosure are essential parts of professional practice.

Knowledge Check

Question 1 of 5
Q1Single choice

Which statement best defines software reverse engineering?

Explore Related Topics

1

How to Become a Software Architect

The course maps the journey from developer to software architect, highlighting the strategic mindset, essential hard and soft skills, career milestones, and actions needed to succeed.

  • Defines a clear timeline: foundation (0‑2 yrs), technical depth (2‑4 yrs), senior/dev‑lead (4‑8 yrs), then formal architect role (8+ yrs).
  • Lists core competencies: architectural patterns, cloud/infrastructure, data modeling, security, DevOps, plus strategic thinking, communication, decision‑making, influence, and mentoring.
  • Emphasizes trade‑off‑driven thinking, captured by Architectural Decision Quality=f(Business Value,Technical Fit,Cost & Risk,Time Horizon)\text{Architectural Decision Quality}=f(\text{Business Value},\text{Technical Fit},\text{Cost \& Risk},\text{Time Horizon}).
  • Shows strong job outlook (17 % growth 2023‑2033) and high salaries (~129kavg,upto129 k avg, up to 255 k in top markets).
  • Recommends practical steps: enterprise experience, study patterns, develop business acumen, earn relevant certifications, write ADRs, and build a portfolio of architectural work.
2

Software Engineering Applications

Software engineering adapts disciplined design, construction, testing, and evolution methods to the specific quality‑attribute priorities of each application domain.

  • Major domains (enterprise, cloud/web, embedded/real‑time, healthcare, scientific, cyber‑physical) differ in primary concerns such as security, reliability, timing, scalability, and safety.
  • Selecting and ranking quality attributes drives architecture, verification, and operational practices; missed deadlines in real‑time systems must satisfy R=Tsense+Tcompute+Tcommunicate+Tactuate≤DR = T_{sense}+T_{compute}+T_{communicate}+T_{actuate} \le D.
  • Secure development is integrated throughout the lifecycle, not added later, to protect interconnected, continuously‑updated software.
  • Analyzing a domain follows a systematic steps: identify stakeholders, define scope, prioritize attributes, choose architecture, add assurance mechanisms, and plan operation/evolution.
3

Requirement Analysis in Software Engineering: Primary Goal, Rationale, and Exam Interpretation

Requirement analysis’s primary goal is to understand and document stakeholder and user needs, creating a clear specification that drives design, coding, and testing.

  • Defined as “identifying, refining, and documenting what a system must do,” it yields an SRS, user stories, or use cases.
  • Core steps: elicit needs, analyze/refine, document, validate, and baseline for downstream work (Requirement Analysis→Clear Requirements→Better Design, Coding, and Testing\text{Requirement Analysis}\rightarrow\text{Clear Requirements}\rightarrow\text{Better Design, Coding, and Testing}).
  • It answers “What does the user need?” unlike design (“How will it be built?”) (Analysis asks "What is needed?"≠Design asks "How will it be built?"\text{Analysis asks } "What\ is\ needed?" \neq \text{Design asks } "How\ will\ it\ be\ built?").
  • Coding, architecture, and testing are downstream activities; the exam answer is option (ii) – understanding and documenting user needs.
Browse all research articles