Example:
Requirements Engineering (RE).
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.
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.
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?
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.
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.
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.
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.