Computer Science Research Questions

It names the artifact you're studying, what you'll measure, and what you'll measure it against. "How does Timed Base Choice tests compare to Base Choice tests in terms of decision coverage?" is a whole evaluation in one sentence, and anybody in the field could run it and check your answer. The population-and-setting advice you'll read elsewhere doesn't quite fit, because the object of study is usually a system rather than a group of people. Say where the evidence comes from too: reading GitHub pull request discussions is a different thesis from asking developers what they think about energy, and that one choice settles the whole method.

No. The build is your method; the research question is what the build lets you find out. A good set usually closes with an ablation question: once the system and its measure have names, you ask what each component contributes. That question, not the repository, is what gets examined. Write it down before you start building, because it decides what you have to instrument while you go.

In this field, often, as long as a criterion is attached. "Is it possible to detect the misuse of graphics libraries at compile-time?" is answerable because detection either happens or it doesn't, and compile-time says when it would count. The version that fails is the open-ended cousin: how can this be improved means nothing until improved means coverage, latency, memory footprint or defects caught. Put the criterion in the sentence and your evaluation chapter has its shape before you write a line of it.

No, and it's usually the more honest promise. Asking what the trade-offs are in using Web services for interoperability on resource-constrained embedded systems commits the thesis to reporting costs beside benefits. That's a lower bar than proving superiority and a much better fit for work on constrained hardware. Examiners are generally comfortable with a thesis that says here's what this costs and here's what it buys; they're far less patient with one that reports only the runs that went well.

Order is the point. Open by describing what already exists, narrow to a design or build question, then close by asking what each part of the finished system contributes. That last one, the ablation question, only means anything once the system and its measure have names, which is why it comes last. Written in that order your questions and your chapters are the same list, and your aims and objectives line up with them instead of reading as a separate study.

Yes, and mining public repositories is an established method. Pull request discussions read for energy trade-offs, dependency changes made by AI coding agents set against human-authored ones, repositories tied to one set of universities: all of it is collectable. Be precise about how you sampled, since sampling is where this kind of study gets attacked. Check the licensing too. A public repository grants other GitHub users the right to view and fork it on the platform and nothing further unless the owner added a license, so redistributing what you mined is a separate question from reading it.

It depends on the claim. A performance claim needs a benchmark and a baseline, not people. A usability, workload or learning claim needs participants, and that brings your institution's ethics review with it, which takes longer than most students plan for. Plenty of computer science theses do both: coverage and latency measured on one side, students put in front of the system on the other. What the review covers and how long it takes varies by institution, so ask yours before you fix the design around a deadline.

Often yes, and evaluating the system or the computing provision at your own employer is a recognized shape for this work. Two things have to be settled first: written permission, and whether you can publish enough detail for someone else to judge the evaluation. If an NDA stops you describing it, the thesis cannot make its case, so find that out before you write the question. Your university may have its own rules about work done on company time, which is worth asking about in the same week.

It doesn't. A comparison, a feasibility result with a stated criterion, a documented trade-off, or a careful account of what practitioners actually do are all contributions this field accepts. Novelty in the thing you build is one route to a contribution; a question nobody has answered carefully is another, and the second is usually more achievable in the time you have.