Information Technology Reference
In-Depth Information
interdisciplinary methodology
consider non-functional requirements
pressure
valve
actuator
-
pressure
set point
rail pressure
controller
-
pressure drops via
injectors
pressure
sensor
pressure
valve
actuator
pressure
set point
rail pressure
controller
-
flexibility
-
pressure
sensor
continuously model-based
equal treatment of
hardware
software
formalization, analysis support
comprehensively optimal solutions
domain- & project-oriented reuse
traceability, configuration management
new
*
*
customer
product
bu ys
*
*
*
needs
consists
of
variant
variant
variant
variant
1
*
*
1
*
*
*
*
*
feature
1
realized
by
1
task
*
component
concerns
*
*
*
*
model-based
comparison
1
1
1
1
1
sub
sub
su b
su b
realizes
responsible
developer
process
*
co sts
version
*
*
1
successor
Fig. 5
Contributions of the domain model based requirements engineering approach
put special emphasis on considering the domain by applying a domain-specific
language, their approach focuses mostly on functional aspects and does not target
small- and medium sized enterprises but larger OEMs. The REMsES project [
32]
focusses on requirements and architecture artifact co-design but without a particular
tailoring to domain or SME specifics. In addition, they also address the embedding
of approaches to variability [
23]
. The latter contribution heavily builds on product
line approaches. The more general field of systems engineering explicitly addresses
interdisciplinarity, but the available tools are mainly text-based [
14]
. This critique
also applies to SysML [
30]
since the requirements element here is intended only as
a bridge to the text-based tools.
Requirements engineering at small and medium-sized enterprises has explicitly
been considered by Kamsties et al. [
20]
. While they highlight some of the character-
istics of software development at SMEs such as overwhelming day-to-day business,
large demand for know-how transfer, only one enterprise in their study performed
customer-oriented development - the key characteristic addressed by the domain
model based approach presented in this chapter. The ReqMan project also targets
SMEs [
9]
. But the emphasis is on how improvements of the development process
can be achieved gradually. Additionally, they explicitly want to remain domain inde-
pendent even though throughout the project they identified the need for considering
the domain context.
Jackson [
17]
discussed the need to investigate and deeply understand the applica-
tion domain as a major precondition for choosing “close-fitting [problem] frames”.
But his focus in regard to reuse was on abstract problem frames. Even earlier,
Sutcliffe and Maiden [
42]
argued for the use of generic domain knowledge since
in their view it is “doubtful whether tools with embedded domain knowledge could
Search WWH ::
Custom Search