Eight questions towards defining your
research problem.
1. Which area in Computer and Systems
Sciences (CSS) interests you most?
Example:
Requirements Engineering (RE).
2. How would you define/describe this
area?
Example:
RE is concerned with development
of methods, tools, frameworks, and principles for improving the alignment
between true business needs and the functionality and performance of supporting
information systems. RE is also concerned with the processes of requirements
acquisition, requirements formulation, requirements verification, and requirements
validation. Another part of RE is the politics and management of the RE
process within a company.
3. Which topic(s) in this area interest
you most?
Examples:
1. Acquisition of user requirements;
formal vs. informal ways of requirements specification.
2. The process of requirements
acquisition considering the quality of requirements specifications as well
as user involvement and participation.
4. Which questions would you like to
have answered concerning this topic?
Examples:
1. To what extent do formal models
of requirements specification hinder users to express their real requirements?
Are informal models better?
2. Why do users have problems with
formal approaches/models?
3. How can we best mix formal and
informal approaches in order to achieve a ²good² requirements
acquisition process?
4. In what way do users with skills
in formal modelling differ from users without such skills?
5. What is the reason for the fact
that many requirements specifications are of a low quality?
5. Which practical problems experienced
in the field do you recognise in this connection?
Example:
The general opinion is that ²procurer¹s
competence² is fairly low. Requirements specifications worked out
today are fuzzy, imprecise, incomplete, and do not offer much directives/needs
to system vendors or system designers. Many systems developed today do
not meet the true needs felt (but not expressed) by stakeholders. The cost
of system maintenance is high, to a large extent due to system changes
needed because of mis-interpreted or missing requirements. There is a need
for better capture and formulation of requirements and for a better communication
between stakeholders and system developers/vendors.
6. How would you formulate you research
problem?
Example:
1. First, I would like to find
out which types/kinds of requirements are not explicitly considered in
typical requirements acquisition processes using ²traditional methods².
Second, I would like to investigate the causes for not explicitly stating
requirements.
2. Next, I would like to suggest
an approach (method) how to make requirements specifications ²more
complete² and to capture these ²missing requirements².
3. Finally I would like to make
a number of ²real life² tests of ²My Method² in order
to prove/show that I have suggested an improved approach.
7. How would your research fit the
current research/context in this field?
Example:
Current reporting on detecting
missing requirements is almost non-existing. Knowledge of what kinds of
requirements typically are neglected is not an established academic field,
yet. The problem of missing requirements is, however, for all requirements
and software engineers, easy to grasp and to understand the implications
of. This research will, therefore, fit well within and contribute significantly
to the research community of requirements and software engineering.
8. Why should other researchers in
this field find your research interesting (significant)?
Example:
Instead of suggesting, without
proper background, yet another model, method, or tool for requirements
acquisition, this research investigates how existing methods (or the lack
of methods) fail in capturing a number of highly relevant needs and requirements.
Study and improved knowledge of this issue is a prerequisite to develop
new, improved approaches of RE which improve the capture of a more complete
set of requirements. Therefore, this research will bring forward results
which are highly relevant for improving RE methods, tools, as well as the
requirements acquisition process.
Back
to FM introduction.