WorkPackage2: Requirement specification and analysis ( PF, SAP, US)
Development environments designed for end users have
to bridge the gap between the technical layer of services and the layer
of appropriate user interfaces. On the technical level, services are
described by speficications of their interfaces and functionality which
imposes constraints for possible topologies for assemblies. On the UI
level, these technical aspects have to be represented in a waxy
appropriate for end users, i.e., taking into account domain specific
mental models. This work package will derive empirically grounded
requirements for domain-oriented development environments (DODEs) from
both layers. Implications for the design of DODE will be analysed.
- avoid impression that project is too vague, don't just say "formulate requirements" but "identify detailed requirements and working practices of industrial partners in relation to the proposal objectives". This would include work on identifying metaphors and representations used by end users.
T2.1: Technology driven requirements ( SAP, VA, PF)
Description of work:
- Identify requirements for ALDs and DODEs in a bottom-up approach analysing various service systems.
- Analyse and categorize the diversity of service types (such as granularity or functional characteristics).
SAP has based its recent Enterprise
Resource Planning (ERP) solutions on platforms with service oriented
architecture. These platforms include the SAP NetWeaver
business process platform as well as the Application Platform. In a
first step, services of various granilarities and chracteristics in
these platforms will be analysed and categorized since these services
have standardized interfaces and data types which eliminate for example
the complication of data conversions in assemblies.
Likewise, other service families to be analysed could include
In addition to these analysis of such well-defined service families interoperability issues will be addresses in a second step.
as source for a variety of services.
- D2.1.1 Service typology - first version (M6)
- D2.1.2 Service specification and categorization - refined version (M12)
T2.2: Scenario-driven requirements ( US, UM, PF, VA, PM, SAP)
Description of work:
- Derive requirements for ALDs and DODEs in top-down approach analysing domain-oriented scenarios
- Identify domain-dependent metaphors for service adaptation and assembly
- Analyse practice and potential of collaborative development
This task complements the requirements
analysis of the WP with a top-down approach, to identify the
requirements from two different angles. Therefore we will develop two
domain-oriented scenarios within this task, together with our
industrial partners. The development of two scenarios for different
domains helps us to determine the commonality and differences between
the domains and enables us to separate common and domain specific
requirements for the DoDE
The development of the scenarios is based on a broad empirical study in
which we identify detailed requirements for the construction of the DoDE
as well as the working practices of our industrial partners in relation
to the proposal objectives, which will be used for the definition of
community and appropriation support mechanisms. This includes the identification of
metaphors, used by the end users and the identification of the
collaboration processes within the companies. Besides these
human-centric aspects we will also focus on the service-oriented
architectures that are used and maintained in the companies. One aspect
of this analysis is the usage of services within the IT-Infrastructure
of the companies and another aspect is the creation and adaptation of
the service assemblies.
The empirical study will be done with different qualitative
empirical methods that are appropriate to focus on the different
aspects of the analysis. First, we will conduct several semi-structured
interviews with different employees from the industrial partners, to
get a deep knowledge of the requirements for the DoDE
in the different application domains. Complementally to the interviews
we will do work place studies within the companies to learn about the
current usage of the service oriented architectures and how service
assemblies are achieved today. Analysis on domain and technical aspects
define the specification for a group of objects with service functional
and non-functional characteristics. Non functional aspects (e.g.,
security) refer to both technical aspects of service provisioning and
its suitability in the considered domain. In the end of the empirical
study we will arrange a participatory design workshop with users from
all industrial partners, to gain valuable information about suitable
metaphors for end users of different domains, making it possible to
develop an appropriate prototype in WPx.
Will this include also development of mock-ups, paper
prototypes or the like? - (NM) Yes, to demonstrate the capacity of
technology to change current practices.
D2.2: Scenarios and requirements for the design of a prototype in later WPs; including the following:
- visual representations and metaphors used in problem solving to seed the construction kit;
- reusable design patterns to seed the catalogue with;
- approaches to collaborative design and problem-solving to seed the collaborative design process repository and model;
- 19 Apr 2007