Research questions

Academic research projects often define their intended knowledge output by setting out one or more research questions (RQs). The RQs further refine the aim of the project by breaking it down into different aspects. The big benefit of RQs is that the rest of the project methodology can be exclusively geared towards answering those questions. Any activity that does not progress towards the answers in unnecessary and should be excluded. Some projects do not lend themselves to definition using RQs, but it is worth considering whether this is actually the case.

It is important to understand what an RQ is, however, and what it is not. Many students who are unfamiliar with the term interpret it in a very informal way. They might, for example, propose an RQ such as "What is the best choice of statistical test to compare two sets of experimental results?". This is not a research question because the answer is already known. It is covered in every textbook on statistical tests. What the student means in this case is that they don't know which test to use and will therefore have to do some reading to find out. That is not research; at best, it could be called background research. An academic project contributes something new to society's knowledge, not just that of the student.

One way to visualise the relationship between research questions and other aspects of the project definition is shown in Fig. 1.

The aim quantifies the title and the research questions refine the aim. The objectives set out the practical stages the researcher must go through to arrive at the answers to the research questions, and the final conclusion is drawn on the basis of the results. The conclusion has a direct relationship to the aim.

Types

The majority of good quality research questions fall into one of three categories. The first is descriptive, where the purpose of the research is to understand a situation better. For example:

What security concerns are most often reported in academic journals with respect to the Internet of Things?

In descriptive questions, there is often a group or context (here it is in academic journals), and a variable that is being quantified (here it is IoT security concerns).

The second category comprises comparative questions which examine the difference between two or more cases on a specific variable. For example:

Which of the three most popular web servers offer the best performance in terms of requests per second?

In the example, the cases are the three most popular web servers, and the variable is requests per second.

The third category is causal questions which examine the effect of one variable on another. For example:

What is the effect of the number of hidden layers on the training time of an artificial neural network?

The causal, or independent variable is the number of hidden layers, and the affected, or dependent variable is the training time.

For a more detailed discussion of different types of RQ with illustrative examples, please see Easterbrook et al (2008).

Good research questions

Another mistake that students often make when developing RQs is to aim for something that is simply not feasible within the constraints of the project. The same is also true of the aim of the project. For example, it is common to see RQs and aims which seek to find 'the best' solution for a problem, or which use other absolute terms. Aiming to find a 'best' solution implies an exhaustive search through all possible solutions which is rarely feasible. Good RQs have some common characteristics that are listed below.

RQs have complex answers

A question to which the answer is yes or no does not make a good RQ because it is too simple. It is either not a very interesting question, or it is not specific enough:

Bad: "Do people over 65 struggle with new technology?"

Good: "What aspects of new technology cause the most difficulty for people over 65?"

RQs have a clear focus

A good RQ has a single, clear focus rather than combining multiple concepts.

Bad: "What are the most common errors that novice programmers make, and what are their preferred programming languages?"

Good: "What are the most common java errors that novice programmers make?"

RQs are tractable

If the question is impossible to answer at all, or just impossible to answer within the time available, it is not a good RQ:

Bad: "Can a genetic algorithm solve Fermat's last theorem?"

Good: "How can genetic algorithms be used to solve mathematical equations?"

RQs are objective

It should be possible to answer an RQ on the basis of gathered data. If the question instead depends on a subjective judgement, it is not a good RQ:

Bad: "Which is the best programming language?"

Good: "What programming language features are most valued by experienced developers"

RQs are specific

If the wording or the question is vague, then the scope is too wide and it will be impossible to answer:

Bad: "How does migrating to a cloud platform affect software development?"

Good: "What process efficiencies are observed when a mature C# development team migrates from a Windows Server platform to Azure native?"

RQs are not open-ended

A question that can be investigated indefinitely is not a good one. Questions that ask why? often fall into this category:

Bad: "Why do some software development projects fail?"

Good: "What are the most common causes of software project failure according to project managers?"

RQs are non-trivial

If a question can be answered without research, then by definition it is not a good research question. Remember that research involves the collection and analysis of data.

Bad: "Can Flutter be used to build a mobile photo-editing app?"

Good: "What features of Flutter do mobile developers most value for image manipulation apps?"