D2.1 Requirements and Specification - CORBYS

D2.1 Requirements and Specification
following requirements have to be fullfiled.
1. Integration (wrapping) of modules
of existing control architecture (e.g
robot arm control module) of the
second demonstrator into CORBYS
control architecture.
2. Analysis of usability of existing
sensors for CORBYS demonstration
REQUIREMENTS FOR THE SECOND DEMONSTRATOR
MANDATORY
High level CORBYS cognitive control modules to be evaluated on existing
robotic system for examining hasardous environments. A detailed strategy
will be defined later. It depends on the requirements of CORBYS control
(software) architecture.
Existing sensors (e.g. vision sensors) are to be analysed in the CORBYS
context. It is to be tested whether existing sensors can provide necessary
information for cognitive modules. Should additional sensors be integrated?
Should the functionalities of the vision module be extended?
3. Situation Awareness Situation Awareness input to semi-autonomous (autonomous) robot control
4. Identification and anticipation of
human co-worker purposeful
behaviour
Cognitive input to semi-autonomous (autonomous) robot control for
overtaking initiative when needed
4.5 Requirements Engineering Methodology (UI­REF) Salient Features
Requirements Elicitation and Prioritisation
UI-REF (Badii 2008) incorporates an integrated set of models, techniques and tools to allow the system
designers to negotiate articulate and prioritise the set of use-contexts and their related requirements and
evaluation context criteria and priorities in a way that overcomes the problems of needs articulation and
memory bias on the part of the users. To arrive at a prioritised set of requirements, it will be necessary at least
to:
i) agree and set out the list of domain prototypical entities or actors as stakeholders;
ii) define the characteristics of the prototypical entities involved in the typical usage arena envisaged for
the target system (e.g. actors, devices, system of systems);
iii) establish the generalisation ontology of usage-contexts each related to their distinct features as needed
by the relevant user (sub)groups in their target prototypical scenarios;
iv) define the key differentiators of usage contexts (context switches) and the prototypical actors’ needs
hierarchies in each of the identified prototypical target context-scenarios;
v) define the prototypical workflows and state diagrams, thus establishing the domain user/practitioner’s
(sub)-goal and (sub)-task hierarchies;
vi) deduce the user’s needs priorities in terms of ICT-enabled features to facilitate user’s task fulfilment in
each situated context-scenario of the application domain as identified and demarcated (situated-usageclass)
under respectively iii) and iv) above.
User-intimate approaches often yield a vast amount of raw data and need appropriate abstraction and context
layering, to reflect the natural partitions within the domain. This is so as to arrive at actionable insight as to
the most deeply-valued needs for most users belonging to each of the target usage-context types within the
17