design-science-methodology

Building a system is engineering; showing what is learned from building it is research. Design science research (DSR) is the frame that turns the first into the second: an artifact designed to solve a stated problem, evaluated with rigour, and a contribution to knowledge stated separately from the artifact itself.

The process (Peffers et al.)

1. Problem identification and motivation: the problem, who has it, why existing solutions fall short (from lit-review-synthesis), and why solving it matters. Concrete and, where possible, quantified.
2. Objectives of the solution: requirements the artifact must meet, derived from the problem and the literature. Functional (must do X) and quality (latency under Y, usable by Z without training). Each requirement is later a row in the evaluation table. Number them (R1..Rn).
3. Design and development: the artifact, with its design decisions recorded as they are made (adr-writing works for this) and the knowledge they draw on (which theories, patterns, prior systems). The thesis describes architecture and the decisions, not every line.
4. Demonstration: the artifact used to solve an instance of the problem (a worked example, a pilot). Shows feasibility.
5. Evaluation: how well the artifact meets the objectives, with a method chosen from the strategy below. This is the chapter examiners read hardest.
6. Communication: the thesis, and the artifact released with documentation (experiment-reproducibility).

Iterate: evaluation feeds back into design. Record each cycle; a thesis that shows two design iterations with evidence is stronger than one that presents a finished system.

Evaluation strategy

Choose along two axes (Venable, Pries-Heje, Baskerville): artificial or naturalistic setting, and formative (during design) or summative (final). Combine at least two of:

Map every requirement to at least one method. A requirement with no evaluation is a claim.

Separate two questions in the write-up: does it work (efficacy: technical evaluation) and does it help (effectiveness: users, context). A master's thesis usually shows the first rigorously and the second in a limited pilot; say which is which.

Contribution types (Gregor and Hevner)

State which the thesis makes:

• Level 1: instantiation: a working system for a specific problem (weakest as knowledge; strengthen with 2).
• Level 2: nascent design theory: constructs, principles, or a method that would apply to other instantiations ("design principles for X: DP1 ...").
• Level 3: design theory: a well-developed, tested theory (rare at master's level).

Write the design principles explicitly, each with the evidence from the evaluation that supports it. That list is the research contribution; the code is the artifact.

Rigour checklist (Hevner's guidelines)

1. The artifact is described precisely enough to be reconstructed.
2. The problem is relevant to a named stakeholder group.
3. The evaluation method fits the artifact and the objectives.
4. The contribution to knowledge is stated apart from the artifact.
5. The design draws on the knowledge base (cite the theories and prior systems it builds on) and the evaluation uses recognised methods.
6. The search for the design is described: alternatives considered, why this one.
7. The thesis communicates to both technical and managerial readers (architecture for the first, requirements and results for the second).

Output

A method chapter skeleton with the six process steps as sections, the requirements table (id, requirement, source, evaluation method), the evaluation design per method (using research-methodology for the user-facing ones and benchmark-reporting for technical ones), and a placeholder design-principles list to be filled from the evaluation. Update research/QUESTION.md with the chosen contribution level.