-
The PLANTCockpit project (260018) is co-funded by the European
Union under the Information and Communication Technologies (ICT)
theme of the 7th Framework Programme for R&D (FP7).
This document does not represent the opinion of the European
Community, and the European Community is not responsible for any
use that might be made of its content.
Programme Factories of the Future PPP
Strategic Objective ICT-2010-10 Smart Factories: ICT for agile
and environmentally friendly manufacturing
Project Title Production Logistics And Sustainability
Cockpit
Acronym PLANTCockpit
Project # 260018
D2.1 - METHOD TO COLLECT, DOCUMENT, AND ANALYSE USER
REQUIREMENTS
Work Package WP-2 Requirements Analysis
Lead Partner EPFL
Contributing Partner(s) EPFL, INTEL, SAP, TUD, FTK, POLIMI,
TUT
Security Classification PU
Date 10/12/10
Version 1.0
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx ii
The research leading to these results has received funding from
the European Communitys Seventh Framework Programme (FP7/2007-2013)
under grant agreement no260018.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx iii
Table of contents 1 EXECUTIVE SUMMARY
...........................................................................................
1 2 PREAMBLE INTRODUCTION
...............................................................................
2 3 METHOD TO COLLECT, DOCUMENT, AND ANALYSE USER REQUIREMENTS
..............................................................................................................
3
3.1 OVERALL DESCRIPTION OF THE REQUIREMENT ELICITATION
PROCESS.......................... 3 3.2 COGNITIVE WORK ANALYSIS
....................................................................................
4
3.2.1 Advantages of CWA
...........................................................................................
5 3.2.2 Limitations of CWA
............................................................................................
6
3.3 VISION STATEMENT ANALYSIS
...................................................................................
6 3.3.1 Description
........................................................................................................
6 3.3.2 Knowledge gathering techniques
......................................................................
10 3.3.3 Modelling tools
................................................................................................
10 3.3.4 Summary
..........................................................................................................
15
3.4 WORK DOMAIN ANALYSIS
.......................................................................................
15 3.4.1 Description
......................................................................................................
15 3.4.2 Knowledge gathering techniques
......................................................................
15 3.4.2.1 Document analysis
........................................................................................
15 3.4.2.2 Exploratory interview
...................................................................................
15 3.4.3 Modelling tools
................................................................................................
16 3.4.3.1 Abstraction hierarchy
...................................................................................
16 3.4.3.2 Abstraction decomposition space
..................................................................
18 3.4.3.3 Concept Mapping
.........................................................................................
19 3.4.4 Summary
..........................................................................................................
21
3.5 CONTROL TASK ANALYSIS
.......................................................................................
21 3.5.1 Description
......................................................................................................
21 3.5.2 Knowledge gathering
.......................................................................................
21 3.5.2.1 Expert Interview
...........................................................................................
21 3.5.3 Modelling tools
................................................................................................
22 3.5.3.1 The Decision
Ladder.....................................................................................
22 3.5.4 Summary
..........................................................................................................
25
3.6 STRATEGIES ANALYSIS
............................................................................................
25 3.6.1 Description
......................................................................................................
25 3.6.2 Knowledge Gathering
......................................................................................
26 3.6.2.1 Interviews
.....................................................................................................
26 3.6.2.2 Observations
................................................................................................
26 3.6.3 Modelling tools
................................................................................................
27 3.6.3.1 (Information) Process Mapping
....................................................................
27 3.6.3.2 Information Flow Maps
................................................................................
27 3.6.3.3 IDEF
............................................................................................................
29 3.6.4 Summary
..........................................................................................................
29
3.7 REQUIREMENT SPECIFICATION
.................................................................................
30 3.7.1 Functional specification
...................................................................................
30 3.7.1.1 Description
...................................................................................................
30
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx iv
3.7.1.2 Knowledge integration
..................................................................................
30 3.7.1.3 Modelling tools
.............................................................................................
30 3.7.1.4 Viewpoint Definition template
.......................................................................
31 3.7.1.5 Requirement table
.........................................................................................
32 3.7.1.6 Use case template
.........................................................................................
35 3.7.2 Technical specification
....................................................................................
36 3.7.2.1 Definition of the application
.........................................................................
37 3.7.2.2 Objective of the application
..........................................................................
37 3.7.2.3 Involved actors in the application
.................................................................
37 3.7.2.4 Physical components considered in the
application....................................... 38 3.7.2.5 The
application software/support-systems
..................................................... 38 3.7.2.6
Description of the functionality of the application
......................................... 39 3.7.2.7 Information
flow modelling template and guide (Swim lane)
......................... 40 3.7.2.7.1 Description of basic symbols
of event and information flow modelling templates
..................................................................................................................
40 3.7.2.7.2 Event process chain diagram for workflow modelling
................................ 41 3.7.2.7.3 Information flow
diagram for information flow modelling ......................... 43
3.7.3 Summary
..........................................................................................................
44
4 CONCLUDING REMARKS
......................................................................................
46 5 REFERENCES
...........................................................................................................
46
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx v
Table of Figures Figure 1. Activity modelling using IDEF
....................................................................
3 Figure 2. CWA Nested Constraints (Vicente, 1999)
.................................................... 5 Figure 3.
IDEF diagram of the requirement elicitation process
................................. 7 Figure 4. IDEF diagram of the
activity A5
................................................................. 8
Figure 5. Mindmap template
......................................................................................
10 Figure 6. Business and organisation part of the Mindmap
........................................ 10 Figure 7. Plant
structure part of the Mindmap
........................................................... 11
Figure 8. Performance impact part of the Mindmap
.................................................. 11 Figure 9.
Support systems part of the Mindmap
........................................................ 12 Figure
10. Processes part of the Mindmap
................................................................ 13
Figure 11. Events part of the Mindmap
.....................................................................
13 Figure 12. Engineering assets part of the Mindmap
.................................................. 14 Figure 13.
Product part of the Mindmap
....................................................................
14 Figure 14. Business and organisation part of the Mindmap
...................................... 15 Figure 15. Types of
Hierarchies
................................................................................
16 Figure 16. An abstraction hierarchy of a car (Burns &
Hajdukiewicz, 2004) .............. 17 Figure 17. Abstraction
hierarchy of manufacturing line
............................................. 18 Figure 18.
Relationships in an ADS (Vicente, 1999)
................................................. 19 Figure 19.
Annotated Abstraction Hierarchy (Upton & Doherty, 2010)
...................... 19 Figure 20. Concept Map (Crandall et al.,
2006) ........................................................ 20
Figure 21. The Decision Ladder
................................................................................
23 Figure 22. Decision Ladder for the Model Human Scheduler
(Sanderson, 1998) ..... 24 Figure 23. Decision Ladders showing
distributed cognitive workload........................ 25 Figure
24. Control Task Analysis & Strategies Analysis (Vicente, 1999)
................... 26 Figure 25. Information Process Flow
associated with bottleneck evaluation ............. 27 Figure 26.
Information Flow Map applied to air traffic control strategy
(Kilgore et al.,
2008)
..........................................................................................................
28 Figure 27. IDEF3 Process Description Diagram
........................................................ 29 Figure
28. IDEF3 Object State Transition Network Diagram
..................................... 29 Figure 29. Use Case
Diagram
...................................................................................
31 Figure 30. Swim lane template
..................................................................................
42 Figure 31. Information flow diagram
..........................................................................
43 Figure 32. Relationship between models across the CWA phases
........................... 45
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx vi
Table of tables Table 1: Description of the requirement
elicitation process ......................................... 9
Table 2: Viewpoint definition table
.............................................................................
32 Table 3: Requirement specification table
..................................................................
34 Table 4: Use case table
.............................................................................................
36 Table 5: Technical requirement table
........................................................................
37 Table 6: The concerned PLANTCockpit application
.................................................. 37 Table 7:
Objectives of the concerned PLANTCockpit application
............................. 37 Table 8: Involved lifecycle actors
of the concerned PLANTCockpit application ........ 38 Table 9:
Physical components of the concerned PLANTCockpit application
............ 38 Table 10: Support systems / other systems external
of the concerned PLANTCockpit
application
..................................................................................................
38 Table 11: Functionalities of the concerned Application
............................................. 39 Table 12: Basic
symbols for workflow and information modelling
............................. 40
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 1
1 Executive Summary This report provides the PLANTCockpit D2.1
deliverable: Method to collect, document, and analyse user
requirement. The report contains the description of the approach
and the related set of requirement specification templates,
therefore facilitating the requirement elicitation process. This
deliverable can be considered as an important input to specify
functional and technical requirements that PLANTCockpit will
address in the following Work Packages.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 2
2 Preamble Introduction The objective of the Work Package 2 is
to define and specify the functional and technical requirements for
PLANTCockpit. Due to the fact that PLANTCockpit addresses a
representative selection of main industries and production types,
the requirements analysis considers the generic issues as well as
industry specific and production type specific issues. The starting
point for the analysis is the definition of an adequate methodology
for the requirements analysis itself which provides the basis for
conducting the functional, the technical and the cognitive
requirements analysis. To achieve this objective, this report
addresses the Task 2.1: Specification of an analysis method that
will be considered as a support for the following tasks 2.2 and
2.3.
This report is organized in a way to facilitate the
implementation of requirements elicitation for each end-user.
Section 3 describes the proposed methodology to collect, document,
and analyse user requirements at a high and detailed levels. In
this main section, each step of the approach is described and
specific templates, techniques and diagrams are introduced.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 3
3 Method to collect, document, and analyse user requirements
This section describes the proposed approach for functional and
technical requirements elicitation. It also describes the set of
techniques and templates that are used to capture and specify
document business context (need and impact) and user
requirements.
3.1 Overall description of the requirement elicitation process
To carry out the Task 2.1, a requirement elicitation methodology
has been proposed. Figure 3 and Figure 4 introduce an IDEF diagram,
giving an overview of the approach, in which the several steps
including input and output information, the associated
techniques/tools/templates as control means, and the involved
actors are presented. The activity modelling of the methodology
proposed in this report essentially provides an input-output model
with a static snapshot view (Figure 1). This framework is
hierarchical in nature and thus allows a top-down decomposition of
each phase of the proposed requirement elicitation process. In such
a context, IDEF modelling standard is particularly suited to define
and model information flows. The description of basic elements in
IDEF is as follows:
- Activity: Any action that is necessary to convert the inputs
into outputs. Activities are presented by boxes. Activities can be
broken down into sub-activities as long as all the sub-activities
are member of the subset;
- Input & Output: Any set of data-information which is
transformed by an activity. Inputs enter from the left face of the
activity box and outputs exit from the right face of the activity
box;
- Constraint: When input and output from one activity box
becomes a control to another activity box, it constraints the
activity that can be controlled in that box. Thus, constraints
specify the limits, range, procedures, templates, working regions
permissible for the activity. Constraint is represented by an arrow
entering through the top face of the activity box;
- Mechanism: Entity that makes the activity happens. This is
represented by an arrow that enters through the bottom face of the
activity box.
Figure 1. Activity modelling using IDEF
In such a way, this IDEF diagram (Figure 3 and Figure 4) enables
the complete understanding by the reader to ensure flawless
execution of the procedure from a high abstraction level. This
diagram is followed by a table which summarises the requirements
elicitation process by incorporating the purpose of each step
(Table 1). Here, the proposed
ActivityInputs Outputs
Constraints
Mechanisms
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 4
procedure can be broken down into five steps, as listed below:
1. Vision statement analysis (A1) 2. Work domain analysis (A2) 3.
Control task analysis (A3) 4. Strategies analysis (A4) 5.
Requirement specification
5.1. Functional requirements identification and documentation
(A51) 5.2. Technical requirements identification and documentation
(A52)
The proposed method enables the incorporation of Cognitive Work
Analysis (CWA) in the specification of requirements for
PLANTCockpit. The DoW identifies CWA as one of the methodological
frameworks for analysing the three application partners work
domains. CWA comes with a pre-existing process and a number of
tools that focus on cognitive and perceptual aspects of systems
design. The purpose here is to highlight these techniques and
suggest similar modelling tools that may be more familiar to
analysts from a software engineering background. The process
overview also provides a useful structure for planning the
knowledge gathering techniques and reviewing current technologies
used by the target domain.
The aims of this toolkit are to:
1. Outline a structured process for requirements engineering 2.
Provide guidance on knowledge gathering techniques to analysis
partners 3. Provide standard tools and templates for modelling
outputs throughout the process
3.2 Cognitive Work Analysis
CWA can be considered as a formative, constraint-based framework
for analyzing complex work systems (Vicente, 1999).To
systematically explore work possibilities, CWA focuses on
identifying the constraints that shape workers purposeful
goal-directed behaviour rather than cataloguing specific worker
tasks and procedures. This approach is inspired by ecological
psychologys tenet that complex human behaviour in operational
settings can be usefully explained by analyzing the complexity of
their surroundings. The original CWA framework, such as shown in
Figure 2, suggested that work domain could be modelled across five
levels of nested constraints (Rasmussen et al., 1990):
- Work Domain: Physical or intentional constraints that
determine what can be done by a system;
- Control Tasks: Transformation of information into knowledge
states required to meet systems goals;
- Strategies: Different methods for achieving control tasks; -
Social: Organisation Distribution of strategic tasks across system
agents; - Worker Competency: The role of expertise and situational
knowledge in achieving
tasks.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 5
Figure 2. CWA Nested Constraints (Vicente, 1999)
3.2.1 Advantages of CWA Software requirements engineering
generally starts with use cases and looks to specify functional
requirements. This poses a number of challenges for large scale
projects such as PLANTCockpit. Firstly it works off an assumption
that business requirements have already been identified by a
business analyst and can be expressed to the software design team.
Secondly, software requirements rarely provide the contextual
information that is necessary to inform the design of end-user
interfaces. CWA can overcome both of these limitations as described
in the following paragraphs.
FirstOfKind (FOAK) systems:
First Of A Kind (FOAK) systems generally offer new functionality
to user roles that may not yet exist. This makes it difficult to
apply conventional user centred requirements gathering techniques.
By moving from the work domain level to worker level it is possible
to identify the system goals and context of work that will
determine end user needs.
Resilience Engineering:
CWA has been developed to support the development of control
systems that take account of both the perceptual/cognitive
limitations and the flexibility and intelligence of human
operators. It aims to support different levels of cognitive control
that can be exerted on a system, as defined by the Skills, Rules
and Knowledge Taxonomy (Rasmussen, 1983).This supports the
development of control interfaces that allow operators to cope with
unanticipated events as well supporting efficient standard
operating procedures.
Informing GUI Design:
Software requirements rarely provide the level of contextual
information necessary to inform the design of end user interfaces.
The rich descriptions gained through extensive knowledge gathering
and modelling can directly inform the design of user interfaces
that reduce cognitive workload and increase situation
awareness.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 6
Focussing the Problem:
Many software requirements engineering processes require that
business requirements have already been identified by a business
analyst and can be expressed to a software architect. This can pose
a challenge in large scale research projects where the initial
research goals can be highly abstract. The CWA approach allows a
researcher to progressively focus in on how goals can be achieved,
thus supporting iterative clarification of the problem statement.
At the same time the use of hierarchical functional models make is
easier to separate generic cross-domain functionality from context
dependent issues.
3.2.2 Limitations of CWA Toolkit Limitations:
Modelling techniques for the later phases of the framework are
not well described in the literature. To overcome this we have
suggested additional modelling techniques that are appropriate for
the different phases.
Familiarity:
While CWA has been applied to a wide range of critical systems
domains, these tools may not be familiar to the wider ICT sector.
Again we have suggested additional modelling techniques that may be
more familiar to developers to overcome this issue. Below we
provide an amended cognitive work analysis process.
3.3 Vision statement analysis 3.3.1 Description The vision
statement describes the functional purpose of the system by
explaining the business need for the technology, its estimated
impact and some means for evaluation. The vision statement
facilitates the process of identifying a solid business need by
calling out goals and what is needed to achieve these goals. It
also calls out the specific Impact that the implementation of the
project will have on business practices. State the scope of the
implementation i.e. will impact be seen in one specific area/tool
set. Each of the impact variables called out in the impact section
of the vision statement template can be subjected to quantitative
measurement and process improvement can be evaluated using standard
statistical methods. Additional qualitative evaluation for example
usability and end user satisfaction surveys can ensure that the
needs of expert end users have been successfully accommodated.
The vision statement also helps to describe the associated roles
and their primary goals. This should describe all potential end
users of the system in terms of their job specification and
responsibilities. Their current goals should be clearly described
as well as an indication of how the proposed system will improve
performance. A network diagram is often used to help map and
visualise these users, goals and interactions.
.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 7
Figure 3. IDEF diagram of the requirement elicitation
process
NODE: NO.: A0TITLE: Collect, document and analyse user
requirements
A1
Analyse vision
statement
A2
Analyse work
domain
A3
Analyse control
task
A4
Analyse strategies
Storyboard, DoW,Brainstorming session Vision statement,
Populated Mindmap (high level)
Concept Maps, Abstraction hierarchy, Interview transcripts
Decision Ladder Diagrams, Interview transcripts
Process Flow Diagrams for each View Point (VP), Information Flow
Diagrams, IDEF Models, SwimLanes
A5
Specify requirement
Vision statementtemplate
Mindmaptemplate
Mgt representative from industrial demonstrator &
requirements analyst
Mgt representative from industrial demonstrator &
requirements analyst
Exploratory interview, document analysis
Conceptmap
Hierarchytemplate
Domain expert representative from industrial demonstrator &
requirements analyst
Domain expert Interview
Interview template
End user interview, Observation of Work Practices
End-user representative from industrial demonstrator &
requirement analyst
Process Flowtemplate
Representative analyst & all representatives from industry
demonstrator partner
Use caseTemplate (UC)
Functional requirement template (FRQ)
Technical requirement template (TRQ)
Ucs, FRQs, TRQs
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 8
Figure 4. IDEF diagram of the activity A5
NODE: NO.: A5TITLE: Specify requirement
A51
Identify & document functional
requirement
A52
Identify & document technical
requirement
Partners involved in the activity including end-user
Partners involved in the activity including end-user
VPs & Mindmap FRQs, UCs
TRQs, SwimLanes models, IF models
FRQtemplate
UCtemplate
TRQtemplate
SwimLanetemplate
Information Flow (IF)template
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 9
Table 1: Description of the requirement elicitation process
Step No.
Description Purpose MECHANISMSActors (partners) involved
INPUTSSource(s) to be used(storyboard, ppt, meeting, interview,
visit, )
CONTROLSTemplate (model) to be used(MindMap, ConceptMap, VP
table, RQ table, UC model, SwimLane model, DataFlow model, )
OUTPUT (deadline)
Responsible
1 Vision statement To identify business needs for the
technology, its estimated impact and concerns of actors involved
and some means for evaluation
Management Representative from Industrial Demonstrator &
Requirements Analyst
Storyboard, Brainstorming Session
Vision Statement templateMindMap Template
Vision statement MindMap (High level)
Analysis Team(As per matrix) Ensure quality control of
Document
2 Work domain analysis
Work Domain Analysis involves developing a model of causal
relationships between an overall system, its subsystems and their
constituent components
Management Representative from Industrial Demonstrator &
Requirements Analyst
Vision Statement, Populated MindMap,Exploratory
Interview,Document Analysis
Concept Map/Abstraction Hierarchy Template
Concept Map/Abstraction HierarchyInterview Transcripts
Analysis Team(As per matrix) Ensure quality control of
Document
3 Control Task analysis Control Task Analysis models reasoning
associated with system tasks it achieves this by tracing
transitions between low-level data associated with skills-based
behaviour and high-level knowledge supporting knowledge-based
behaviour
Domain Expert Representative (e.g. Process engineer) from
Industrial Demonstrator & Requirements Analyst
Concept Map/Abstraction HierarchyDomain Expert Interview
Interview Template Decision Ladder Diagrams Interview
Transcripts
Analysis Team(As per matrix) Ensure quality control of
Document
4 Strategies analysis Strategies Analysis is used to describe
work activity. While control task analysis defines what needs to
occur at a high level, strategies analysis explains how an output
can be achieved in real world scenarios.
End User Representative(s) from Industrial Demonstrator (e.g
tool operator) & Requirements Analyst
Decision LadderEnd user InterviewObservation of Work
Practices
Process Flow Templatese.g. Information Flow Diagram e.g. IDEF
Model e.g.Swimlanes
Process Flow Diagrams for each View Point (VP)Information Flow
DiagramsIDEF ModelsSwimlanes
Analysis Team(As per matrix) Ensure quality control of
Document
5 Requirements Specification
Requirements Specification aims to integrate the output from all
previous stages in the Analysis process together and puts forward a
full description and understanding of what you want the system to
do.
Requirements Analyst & All representatives from Industrial
Demonstrator Partner
Concept Map/Abstraction HierarchyDecision LaddersProcess Flow
Diagrams
Use Case TemplateFunctional Requirements Template (FRQ)
Technical Requirements Template (TRQ)
Use Case DiagramsFRQsTRQs
Analysis Team(As per matrix) Ensure quality control of
Document
5.1 Identify & document functional requirements (FRQ)
To define what PLANTCockpit is supposed to accomplish for
End-User
Partners involved in the activity including end-user(COMAU,
POLIMI and EPFL)
VPS & MindMap FRQ table template, UC template, ConceptMap
(CM) template
FRQs, Ucs, CMs Task Leader (EPFL)
5.2 Identify & document technical requirements (TRQ)
To provide technical aspects that PLANTCockpit is supposed to
fulfill
Partners involved in the activity including end-user(COMAU,
POLIMI and EPFL)
FRQs, Ucs, CMs TRQ templates (PC, Obj, FU, SS) Swimlane
template, Information Flow (IF) template
TRQs, Swimlane models, IF models
Task Leader (EPFL)
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 10
3.3.2 Knowledge gathering techniques Brainstorming is often used
whilst populating the vision statement template. Several sessions
may be needed. A storyboard approach can also be taken to map out
all of the above. The Description of Work document should also be
referenced. Management representatives from each industrial use
application and the requirements analyst should be involved at this
stage.
3.3.3 Modelling tools The vision statement template as well as
the Mindmap template (Figure 5 to Figure 14) is used as a modelling
tool for this analysis stage. In each phase of the analysis an
example shows how the relevant template has been applied to the
manufacturing case study. In relation to the vision statement and
the Mindmap we can see that the business need is to provide better
support for production line management in semiconductor
manufacturing facility.
Figure 5. Mindmap template
Figure 6. Business and organisation part of the Mindmap
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 11
Figure 7. Plant structure part of the Mindmap
Figure 8. Performance impact part of the Mindmap
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 12
Figure 9. Support systems part of the Mindmap
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 13
Figure 10. Processes part of the Mindmap
Figure 11. Events part of the Mindmap
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 14
Figure 12. Engineering assets part of the Mindmap
Figure 13. Product part of the Mindmap
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 15
Figure 14. Business and organisation part of the Mindmap
3.3.4 Summary The vision statement describes the business need
for an application framework. This can be thought of as the highest
level functional purpose of a system. It sets the scope and calls
out estimated impact on business practices and means for
evaluation. The vision statement helps to identify associated users
and goals and how they will interact independently with each other
and with the application.
3.4 Work domain analysis 3.4.1 Description Work domain analysis
involves the development of causal models that clarify cause and
effect relationships between an overall system, its subsystems and
their constituent components. This model is a field description
based purely on the environment constraints imposed on a system
that dictates its functionality. These may be physical laws (e.g.
thermodynamics), legal regulations (e.g. gas emissions) or
management targets. A work domain model is event independent. It
defines the system purposes at multiple levels of abstraction but
does not describe events or user actions carried out during
work.
3.4.2 Knowledge gathering techniques The first stage to
developing a work domain model is gathering information about the
system. This is sometimes described as a bootstrapping exercise
(Hoffman, 2005). The vision statement should provide enough
information to start to investigate the relevant infrastructures,
control systems and organisations that support the work.
3.4.2.1 Document analysis Documentation gathering and analysis
is usually an early step in the process. Useful documents include
org charts, training material, operations reports, CAD drawings,
process diagrams, software manuals & technical papers. During
analysis keywords, themes and relationships should be identified
and recorded. Documentation analysis should suggest the reasoning
of domain practitioners, leverage points in terms of opportunities
and is useful in the attempt to construct knowledge models. This
activity also provides the basic knowledge and vocabulary needed to
be able to communicate with the target domains subject matter
experts and end users.
3.4.2.2 Exploratory interview Exploratory interviews with domain
experts can be used to identify important high level goals and
subsystems that support them. An unstructured interview approach is
generally required
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 16
during initial meetings, as concepts about system functionality
are being formed and normalised. These interviews may be
facilitated through mind mapping exercises (Buzan & Buzan,
1994). However, it is important to focus on the functionality of
the whole system rather than the tasks of individual actors at this
early stage of the analysis.
3.4.3 Modelling tools The vision statement describes the
business need for an application framework. This can be thought of
as the highest level functional purpose of a system. This
functional purpose is associated with the entire system but is
achieved through a number of abstract functions associated with
constituent subsystems. These in turn have lower level components
that have purposes at a lower level of abstraction. A number of
different modelling techniques can be used to extract these causal
relationships within a work domain.
3.4.3.1 Abstraction hierarchy Abstraction hierarchies are
particular types of hierarchy that describes means-ends conceptual
relationships (Figure 15). Representing a functional system in
these terms highlights the cause & effect relationships that
are necessary to conduct system diagnosis and decision support
(Rasmussen, 1985).
Figure 15. Types of Hierarchies
The number of levels of functional abstraction depends on the
complexity of the system, but five levels have generally been found
to be appropriate (Bisantz & Vicente, 1994). These levels have
been described as functional purpose, abstract function,
generalised function, physical function and physical form. Figure
16 shows a simple abstraction hierarchy applied to a car. This
example demonstrates that the abstraction hierarchy takes a
perspective on system functionality rather than attempting to model
a comprehensive description. For example another functional purpose
could be to transport people economically. The inclusion of this
goal may introduce new sub-goals and change the arrangement of the
model.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 17
Figure 16. An abstraction hierarchy of a car (Burns &
Hajdukiewicz, 2004)
Figure 17 shows an abstraction hierarchy associated with a
manufacturing line. This shows how the functional purpose of
Manufacturing Product can be decomposed into more generalised
functions associated with subsystems of the line until we arrive at
functions associated with physical components of the overall line
(e.g. regular tool maintenance). The model highlights both causal
links (vertical) and goals that need to be correlated or which may
be conflicting (horizontal). Often this goal balancing requires
flexible human decision making to resolve conflicts.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 18
MFG 4.1 MFG 4.5
Low WIPon Hold
Match Wip to Tools
Proportionally
Build Batches MFG 5.2
Regular Tool Maintenance
High Availability
High Tool Usage
MFG 3.4High
Production Rate
MFG 3.1
MFG 5.1
Low Inventory
Maintain Speed of WIP
Maintain Spread of WIP
SatisfyCustomers
Manufacture Product
MinimiseBottlenecks
MFG 4.2 MFG 4.6
Causal Relationship
Correlations or Conflicts
MFG = ManuFacturing Goal** Some elements of the model have been
hidden for IP reasons
Figure 17. Abstraction hierarchy of manufacturing line
Abstraction hierarchies can be easily developed using
diagramming software such as Microsoft Visio. Other Mind mapping
software that supports the spatial arrangement of directed graphs
can also be used.
3.4.3.2 Abstraction decomposition space An abstraction
decomposition space is an adaptation of the abstraction hierarchy
that can be used to support work domain analysis involving physical
systems. It combines a means-ends functional abstraction hierarchy
with a part-whole physical decomposition of a system (Figure 18).
These two hierarchies are placed orthogonally in a matrix,
essentially mapping function to form at different levels of
granularity. The configuration makes the causal relationships
between system, sub-systems and components more explicit. Some work
domains may not involve the control of a physical system (e.g.
finance, design, HR etc.) or the physical system may be complex to
decompose making it difficult to construct an ADS. In these cases
it may be necessary to annotate an abstraction hierarchy to
indicate structural or organisational aspects of the system (Figure
19.). Abstraction decomposition spaces have a matrix layout and can
be developed using Microsoft Excel. However as they become more
detailed it is often easier to switch to a diagramming application
like Microsoft Visio that gives more control over spatial
layout.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 19
Figure 18. Relationships in an ADS (Vicente, 1999)
Figure 19. Annotated Abstraction Hierarchy (Upton & Doherty,
2010)
3.4.3.3 Concept Mapping Concept maps are diagrams that are used
to represent and convey knowledge (Figure 20). Although concept
maps are not part of the original CWA framework, they provide a
useful tool for understanding constraints in less structured work
environments. They have been used to elicit and structure expert
knowledge in a range of domains including weather analysis,
emergency response teams and military command and control (Crandall
et al.,
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 20
2006). They consist of two structures: Concepts (usually boxed
nodes) and Relationships (labelled edges that link concepts).
Figure 20. Concept Map (Crandall et al., 2006)
Although the form of the diagram looks generic, Concept Maps
have a number of attributes that make them different from other
knowledge mapping techniques:
- Expressiveness: The labelling of links is a critical feature
of concept mapping. While other diagrams allow for unlabeled links
or impose strict predefined syntaxes, concept mapping requires the
analyst to explicitly describe the nature of relationships between
concepts using everyday terms;
- Shape: The most critical concept is always located at the top
of the diagram and is broken down into associated concepts from top
to bottom. This is different from other knowledge mapping
techniques, (e.g. semantic networks) where concepts can radiate out
from the centre. This vertical decomposition is useful as it
supports the later construction of abstraction hierarchies;
- Shape-Meaning Interaction: In complex domains components can
have a many to many relationship. Rather than a straightforward
decomposition of concepts, this approach permit cross-links to
highlight such interactions and dependencies;
- Dynamics: Concept mapping should be considered a process
rather than an artefact. Concept maps provide a medium for engaging
with subject matter experts and modelling their knowledge. As such,
a Concept Map is never truly complete but rather it reflects an
understanding at a point in time. The concept map or maps produced
after a session can be validated with other experts and can be used
to document the session.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 21
Concept Maps can also be developed using generic diagramming
software like Microsoft Visio. A custom concept mapping tool has
been developed by the Institute for Human and Machine Cognition
(IHMC) and can be downloaded here:
http://cmap.ihmc.us/Download/index.php. Again, other mind maps may
be used but it is essential that these can support the attributes
of expressiveness, shape and shape-meaning interaction described
above.
3.4.4 Summary - The outputs of work domain analysis should be a
model (or models) of a work domain
that maps functional relationships in terms of system
constraints; - Depending on whether the targeted domain involves
control of a physical system or
knowledge work/analytics it may be more suitable to use an
abstraction hierarchy or process map respectively;
- Work domain modelling should be seen as an iterative process
where early models are reviewed with subject matter experts and
repeatedly refined until they are considered to be valid
representations;
- Depending on the complexity of the system it may be necessary
to develop multiple work domain models that focus on different
perspectives or levels of abstraction.
3.5 Control task analysis 3.5.1 Description Control task
analysis identifies the information transformations that are
required to control a functional system. While work domain analysis
focuses on system constraints and causal relationships, control
task analysis focuses on system events and information processing.
It differs from other forms of task analysis in that it focuses on
what and why information processing occurs rather than by whom and
how. This approach is agent independent; in that it identifies the
information processing that must occur without referring to whether
this is conducted by a human or automated controller. A modelling
tool called the Decision Ladder is used to trace how this can
occur.
3.5.2 Knowledge gathering The document Analysis conducted in the
previous phase should have provided a rich understanding of the
functional purpose of the domain under study. In this phase we
focus of how this functional purpose is achieved. This is generally
achieved through interviews with subject matter experts.
3.5.2.1 Expert Interview Interviews with system users and owners
are the most efficient means of gaining knowledge about system
events and responses. A semi-structured interview process is
recommended where participants are posed open-ended questions. An
interview template is provided to guide the analyst through a
number of important topics including:
1. Goal 2. Contradictions 3. Tool use 4. Working with others 5.
Internalise 6. Externalise
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 22
7. Help 8. Life cycle 9. Change
Where possible interviews should be recorded and transcribed to
allow for detailed analysis of the subject matter. Where this is
not possible it is recommended interviewers work in pairs with one
leading the questions and the other responsible to note taking.
Sketching of process flows, decision ladders and interfaces by both
interviewers and interviewees is encouraged and these artefacts
should be documented.
3.5.3 Modelling tools 3.5.3.1 The Decision Ladder The Decision
Ladder can be used to model the decision-making process involved in
controlling a system (Figure 21). The left hand side of the ladder
represents the information processing activity (both human and
automated) associated with evaluating a systems state while the
right hand side shows the information processing activity involved
in executing a response. The decision ladder uses two structures to
model cognitive activity:
- Information Processing: - States of Knowledge:
Information processing transforms data into higher-level
information, which can be evaluated against the expected system
state at a particular level of abstraction. Common and routine
events require relatively little cognitive work as a user will
quickly develop the skills to match an alert about a state with a
suitable response. This is represented as a cognitive leap across
the ladder without having to evaluate the system state against
higher level goals. These situations often have sufficient
structure to be codified and handled by an automated
agent/controller. Less frequent events will require additional
information processing as a controller will need to search for an
existing rule that defines the appropriate response. Novel or
unanticipated events generally require further information
processing where the state of a subsystem needs to be evaluated
against the overall system goals. Often this will require deep
knowledge of the causal relationships identified in the work domain
model. In this way causal reasoning can be understood as a
progression up through the decision ladder as an agent moves from
skills to rules to knowledge based behaviour.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 23
Figure 21. The Decision Ladder
Figure 21 shows the basic structure of the decision ladder. In
practice, each information processing box must be annotated with
details of the specific processing activity and data sources.
Figure 22 presents an example of a decision ladder applied to a
manufacturing scheduling control task. In this example information
processing is described by the production rules or strategies
numbered 1-17 in the diagram. The details of each of these
strategies can be found in (Sanderson, 1991). The decision ladder
allows an analyst to identify where different strategies need to be
applied. How these strategies get applied is investigated in the
next phase of the analysis. While it may be possible to automate
some of these strategies, the decision ladder identifies where the
outputs of this information processing is required to understand
the system state. This allows the analyst to identify areas with
high cognitive workload and opportunities for developing artefacts
(e.g. visualisations) to reduce cognitive workload and increase
situation awareness.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 24
Figure 22. Decision Ladder for the Model Human Scheduler
(Sanderson, 1998)
Figure 23 demonstrates a control task analysis applied to our
worked example. In the work domain analysis phase bottleneck
identification was revealed as a key functional goal associated
with line management. The analysis shows how the control task
associated with bottleneck management is divided between
manufacturing supervisors and line managers. A decision ladder is
generated for each actor and the annotations describe how they each
transform the information to gain higher level knowledge about the
system state. As well as describing individual cognitive work the
use of two decision ladders allows us to identify where knowledge
about the system state is transferred between actors. This
contextual information is important as it allows us to identify the
information needs of different users associated with the system. As
decision ladders are used to model causal reasoning about events it
is necessary to develop separate decision ladders for each critical
event associated with the system. Decision Ladders can be developed
using standard diagramming applications such as Microsoft
Visio.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 25
Figure 23. Decision Ladders showing distributed cognitive
workload
3.5.4 Summary - The outputs of control task analysis is a series
of annotated decision ladders that map
the information processing associated with key events; -
Interviews are the primary means of understanding how events occur;
- As with work domain modelling, control task analysis should be
seen as an iterative
process where early models are reviewed and repeatedly refined
until they are considered to be valid representations.
3.6 Strategies analysis 3.6.1 Description While control task
analysis defines what information processing needs to occur at a
high level, strategies analysis describes how outputs are achieved
in reality. As complex systems can involve coupling and
dependencies between components there can often be multiple ways to
complete a task. Models of strategies are used to show specifically
how an output is achieved (Figure 24). The analysis should also
explain why certain strategies are preferred over others in
specific contexts. As well as documenting current activities,
strategies analysis can be used to identify situations where
automated information processing or visual encoding can reduce
cognitive workload for end users.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 26
Figure 24. Control Task Analysis & Strategies Analysis
(Vicente, 1999)
3.6.2 Knowledge Gathering Many organisations have already
documented their common strategies. Where strategies are highly
structured they have often been fully codified and automated. Where
strategies remain under human control they have often been
documented in the form of Standard Operating Procedures (SOPs),
Response Flow Checklists (RFCs), and Best Known Methods (BKMs).
While these can provide a useful starting point for analysis it is
important to note that SOPs and BKMs may not be rigidly adhered to
during real world operations. Workers frequently need to adopt new
strategies to cope with unexpected events in their work. This is
why observations and interview with end workers is so critical. It
is also generally advised not to show workers the predefined
strategies (SOPs, RFCs a, BKMs etc.) before or during interviews as
this can bias their reporting of how work actually happens.
3.6.2.1 Interviews Interviews can be conducted with end users to
identify the strategies they apply to problem solving in their
domains. An interview template has been provided in the
toolkit.
3.6.2.2 Observations Observation is another key knowledge
gathering technique. Observing how work happens provides contextual
information that may not be gathered or reported through
interviews. This contextual information includes details about the
work environment (e.g. lighting, noise, collaboration, mobility
etc) that are necessary to inform the design of end user
interfaces. Most modern work environments involve interaction with
software and this can provide a useful starting point for analysis.
An application walkthrough is an activity where a user demonstrates
how they achieve a key task using their existing IT systems. It
is
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 27
recommended that a think aloud protocol is followed whereby the
user talks through their thought process as they interact with the
system. This allows the analyst to identify where expert tacit
knowledge, which is not embedded in the user interface, is applied.
It is advised to record these sessions for detailed post hoc
analysis. Cam Studio is free open source software that allows you
to record screen interactions with audio and is an excellent tool
for supporting this work (camstudio, 2010).
3.6.3 Modelling tools 3.6.3.1 (Information) Process Mapping
Process mapping is a well established practice across many
engineering disciplines. At a very basic level process maps consist
of a series of boxes and arrows are used to describe processes and
flows respectively. These can be augmented with objects, decision
points and other artefacts. While many forms of process mapping
exist, differences generally relate to syntax which is often
customised to suit different application areas.
Figure 25. Information Process Flow associated with bottleneck
evaluation
Figure 25 shows an information flow map associated with our
worked example. This shows the activity associated with evaluating
the severity of an inventory bottleneck in the context of the
overall line.
3.6.3.2 Information Flow Maps Within the original cognitive work
analysis framework, information flow maps (Figure 26) are used to
conduct strategies analysis. Information Flow Maps (IFMs) are
graphical
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 28
representations of the information processing activities and
knowledge states of particular strategies. This modelling technique
is not as well developed at the decision ladder or abstraction
hierarchy but it still provides a useful method for formally
describing the selection of a given strategy. As IFMs visually map
each of the strategies identified for a given task, this allows
them to be compared with representations of other strategies. IFDs
are accompanied by a verbal description of each strategy being
deployed.
STRATEGIES ANALYSIS
REROUTING TASK
IF 2.7.1
Topo Map of Airspace
AC Perf Model
Prpsd AC Flight
Paths
Determine Hold Location
for 1 AC
Choose 1 AC
to Hold
PrioritiesModel
Hold Location(1 AC)
Strategy 3: Tweaking One AC
Strategy 2: Rerouting One AC
AC Perf Model
UpdatedPath
(1 AC)
Topo Map of Airspace
Choose 1 AC
to Tweak
Monitor Flight Status and Evaluate Path
for 1 AC
PrioritiesModel
Determine Flight Path Update
for 1 AC
Prpsd AC Flight
Paths
Strategy 1: Holding One AC
Choose 1 AC
to Reroute
Topo Map of Airspace
External ACFlt Paths
Prpsd AC Flight
Paths
PrioritiesModel
AC Perf Model
ReroutePath
(1 AC)
Determine Reroute Path
for 1 AC
Figure 26. Information Flow Map applied to air traffic control
strategy (Kilgore et al., 2008)
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 29
3.6.3.3 IDEF Another option is to deploy the IDEF modelling
approach to the generation of process maps. IDEF focuses primarily
on function modelling. It is generally applied to understanding
causal relationships in the same manner as work domain models.
IDEF3 provides a Process Description Capture Method that lends
itself well to describing sequences of activities and
transformations and can be applied to strategies analysis (Figure
27 and Figure 28). IDEF3 provides a number of modelling formats
including process description and state transition. The example
below shows these modelling formats applied to an industrial
painting process. More details on these techniques are available at
http://www.idef.com/IDEF0.htm
Figure 27. IDEF3 Process Description Diagram
Figure 28. IDEF3 Object State Transition Network Diagram
Process maps can be developed using standard diagramming
applications such as Microsoft Visio. A wide range of other
commercial tools are also available.
3.6.4 Summary - Strategies analysis describes information
processing in detail and identifies the actors
or automated agents who carry out this work;
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 30
- Process flow maps, information flow maps or IDEF3 diagrams are
all suitable modelling techniques for conducting this work.
3.7 Requirement specification 3.7.1 Functional specification
3.7.1.1 Description Requirements Specification aims to integrate
the output from all previous phases of the analysis into a format
that is interpretable to a software engineering audience.
Requirement specification is frequently described as the first
stage of software engineering. This is acceptable in domain
specific ICT projects, where the targeted end users can be easily
identified and the business requirements are well understood.
However when engaging with large complex systems that feature
multiple users and an evolving work environment, the previous
phases are vital to clearly identify the core functionality to be
supported. Modelling techniques to support this phase include
scenarios, UML diagrams (use case, class, sequence & activity),
and information specification templates.
3.7.1.2 Knowledge integration The models generated by the
previous phases provide detailed information about the systems
functionality that provides the raw material for populating
standard requirements analysis models. The work domain model
decomposes the system and supports the definition of objects within
UML diagrams. In addition, the functional abstraction hierarchy
supports the identification of attributes that can be associated
with these objects. The control task analysis focuses on critical
events. In this manner it can inform the development of high level
use case scenarios and activity diagrams. The strategies analysis
identifies how information processing occurs and by whom. As a
result these analyses can support the development of more detailed
use cases focussed on specific users. The detailed descriptions of
strategies can also inform the development of information
processing algorithms.
3.7.1.3 Modelling tools The Unified Modelling Language (UML) is
a standard language for specifying, visualising, constructing, and
documenting the artefacts of software systems, as well as for
business modelling and other non-software systems (Fowler, 2003),
(Jacobson et al., 1998). UML represents a collection of best
engineering practices that have proven successful in the modelling
of large and complex systems (Braun et al., 2001). UML diagrams
represent two different views of a system model:
- Static (or structural) view: emphasizes the static structure
of the system using objects, attributes, operations and
relationships. The structural view includes class diagrams and
composite structure diagrams;
- Dynamic (or behavioral) view: emphasizes the dynamic behavior
of the system by showing collaborations among objects and changes
to the internal states of objects. This view includes sequence
diagrams, activity diagrams and state machine diagrams.
UML 2.2 has 14 types of diagrams divided into two categories.
Seven diagram types represent structural information, and the other
seven represent general types of behavior, including four that
represent different aspects of interactions. E.g. Use case diagrams
represent the functionality of the system from a users point of
view (Figure 29). Class
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 31
diagrams represent the structure of the system. An activity
diagram shows the control flow within a system. Sequence diagrams
represent the behavior as interactions.
Figure 29. Use Case Diagram
Requirement Specification Templates are used to document the
outcomes of this phase. These are a series of forms that describe
requirements associated with different use cases.
3.7.1.4 Viewpoint Definition template The proposed Viewpoint
Definition template (Table 2) enables to map PLANTCockpit
viewpoints. This step will provide some useful inputs for
requirements analysis and later for views definition (MVC
technology) in PLANTCockpit. The meaning of the template fields is
described as below:
- Viewpoint ID: each viewpoint is uniquely identified in
conventional manner; - Viewpoint name: every viewpoint is defined
by a descriptive name in order to facilitate
identification; - Business domain & impact: domain related
to the product lifecycle where end-user is
involved and impact that the implementation of the project will
have on business practices;
- Purpose (needs & goals): business needs and goals to be
achieved; - Actors: persons and systems who will be involved; -
Role: describes the role of the actors; - Relationships between
roles: relationships between the different roles and their
individual contribution to the business needs as stated above;
include other relevant roles who may not be direct users of the
system. RIO (Role Interaction Organisation) diagrams may be used
for this activity (Monticolo et al., 2006);
- Related requirements: this field allows to link viewpoint with
requirements;
Viewpoint ID should contain enough information to properly
describe the contents of the document. However, keeping title short
will help users and developers to quickly identify and retrieve
accurate information. To facilitate sorting, a consistent separator
between naming elements is proposed (_). The following rule aims to
well-balance the use case ID through the type of PLANTCockpit
application (A1 for W8, A2 for W9 and A3 for W10), the end-user
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 32
name and a number:
VP___
Example: VP_A1_BMW_001 or VP_A1A2_BMW_001
Table 2: Viewpoint definition table
Viewpoint definition
Viewpoint ID
Viewpoint name Business domain & impact
Purpose (needs & goals)
Roles
Actors
Relationships between roles
Related requirements
3.7.1.5 Requirement table Here, we propose to consider three
templates for the first phase of requirements elicitation such as
Viewpoint Definition, Requirement Specification, and Use Case
Template. Given that requirements elicitation phase can be
considered as a collaborative work, it is also important to
consider the various stakeholders viewpoints related to
PLANTCockpit issues (as described in DoW). Thus, it will be easier
to analyze requirements through identified purposes and concerns of
all end-users. In the following sections, each proposed template is
described in order to provide a full understanding of the reader,
and to help requirements to be expressed and structured in a fixed
and reusable form.
The proposed Requirement Specification template (Table 3)
enables to elicit technical and functional requirements which
should be addressed in PLANTCockpit. The meaning of the template
fields is described as below:
- Requirement ID: each requirement is uniquely identified in
conventional manner. - Requirement name: each requirement is
identified by a descriptive name.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 33
- Version & Date: during requirement elicitation process
different versions of requirements must be managed. This field
contains the current version number and date of the
requirement.
- Author: this field contains the name of the author of the
current version of the requirement.
- Category: this field characterizes the area of requirements:
business model, software, etc.
- Source: this field contains the organization of the author,
i.e. user or customer. - Purpose: this field states why the
requirement is necessary to achieve business goals. - Description:
this field describes what the system shall do. - Specific data:
this field holds a list of specific data associated to the relevant
concept. - Time interval: this field indicates how long information
about the concept is relevant
for the system. It can take two values: Past and Present if
information is always relevant, and Present only if information has
a valid period of time.
- Comment: this field contains additional information about the
requirement that cannot be fitted in previous fields.
- Related requirements: this field enables the link of current
requirement with others. - Domain instance: this field allows
knowing if the requirement can be considered as a
generic requirement. - Classification: this field indicates how
important the requirement is for end-user in
terms of priority and difficulty. It can be assigned an
expression such as High, Medium or Low.
- Status: this field holds the status of the requirement in the
validation process. It can be assigned an expression such as Draft,
Reviewed, and Approved.
- Concerned VP: this field allows to link requirements with
viewpoints.
Note:
Requirement ID should contain enough information to properly
describe the contents of the document. However, keeping title short
will help users and developers to quickly identify and retrieve
accurate information. To facilitate sorting, a consistent separator
between naming elements is proposed (_). The following rule aims to
well-balance the requirement ID through the type of PLANTCockpit
application (A1 for W8, A2 for W9 and A3 for W10), the end-user
name and a number:
RQ___ Example: RQ_A1_BMW_001 or RQ_A1A3_BMW_001
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 34
Table 3: Requirement specification table
Requirement specification
Requirement ID
Requirement name Version & Date Click here to enter a date.
Author
Category Classification High Medium Low
Source Priority
Difficulty
Purpose
Description
Specific data
Time interval Past and Present Only present
Comment
Related requirements
Domain instance
Status Draft Reviewed Approved
Related Viewpoints
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 35
3.7.1.6 Use case template A use case diagram is a technique for
capturing the potential requirements of a new system like
PLANTCockpit. It describes how the system should interact with the
end-users or another system to achieve a specific business goal.
Table 4 presents the use case table. To aid end-users to make use
case tables and diagrams, some elements are described below:
- Use case ID: each use case is uniquely identified in
conventional manner. - Use case name: the use case name provides a
unique identifier for the use case. It
should be written in the verb/noun format and should be
sufficient for the end-user to understand what the use case is
about;
- Pre-condition: a pre-condition section is used to convey any
conditions that must be true when a user initiates a use case. They
are not however the triggers that initiate a use case;
- Actor: actors are parties outside the system that interact
with the system; an actor can be a class of users, roles that users
can play, or other systems;
- Triggers: the triggers section describes the starting
conditions which cause a use case to be initiated;
- Primary flow: at a minimum, each use case should convey a
primary scenario, or the typical course of events. The main basic
course of events is often conveyed as a set of usually numbered
steps;
- Post-condition: the post-condition section summarizes the
state of affairs after the scenario is complete.
Note:
Use case ID should contain enough information to properly
describe the contents of the document. However, keeping title short
will help users and developers to quickly identify and retrieve
accurate information. To facilitate sorting, a consistent separator
between naming elements is proposed (_). The following rule aims to
well-balance the use case ID through the type of PLANTCockpit
application (A1 for W8, A2 for W9 and A3 for W10), the end-user
name and a number:
UC___
Example: UC_A1_BMW_001
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 36
Table 4: Use case table
Use case
Use case ID
Use case name
Purpose
Actor
Pre-conditions
Triggers
Primary flow
Post-conditions
3.7.2 Technical specification The objective of this phase is to
provide guidelines to identify and document technical requirements
for PLANTCockpit in consistency with the specified functional
requirements in tables and use cases but also through the concept
maps. The goal of the technical requirements identification and
documentation aims at providing a state of the art of information
systems and interfaces used in the partners plants. The reason this
has to be performed is to allow the interconnection of PLANTCockpit
with all relevant systems at the partners sites. To ensure this, a
table (Table 5) has been devised that captures the following
information:
- Identifier of the technical system: Each system is uniquely
identified for all of the project by way of ID convention;
- Name of the technical system: The name with which the system
is usually addressed should be put here, to allow re-identification
in other plants and processes;
- Allocation in the automation pyramid: Here it needs to be
specified what role the system fulfils in the automation pyramid,
e.g. if it is ERP, MES or SCADA;
- Provided interfaces: In order to gather information stored in
the system, any interface for data exchange on a technical level
provided by the system needs to be mentioned and specified;
- Semantic information (function in the process): The semantic
information is the description of the information stored in the
described system. This description needs to be exhaustive and needs
the most care, because it sets the field for later integration;
- Associated requirements: The identifiers for every functional
requirement that can be covered by the system have to be captured
in order to interconnect it once information may have been
integrated into PLANTCockpit.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 37
Table 5: Technical requirement table
Technical requirements
Technical requirement ID
System name
Allocation in pyramid
Provided Interface Semantic information
Associated requirements
3.7.2.1 Definition of the application Define what the domain
application is, describe its functionality, and state why this
application is focused in PLANTCockpit (e.g. relate to business
importance, environmental importance, development of new business
areas) (Table 6).
Table 6: The concerned PLANTCockpit application
Application Describe functionality Describe why this Application
is focused in PLANTCockpit
3.7.2.2 Objective of the application As background for the
subsequent sections, list and describe all the objectives that are
to be achieved by the PLANTCockpit application using Table 7.
Describe the objective and why the objective is part of the
PLANTCockpit application (ONE objective per ID).
Table 7: Objectives of the concerned PLANTCockpit
application
ID Objective (one per ID) Describe why OB1 OB2 OB3
3.7.2.3 Involved actors in the application Define and describe
the involved actors who will be affected by the PLANTCockpit
application using Table 8. Include actors both externally (e.g.
transportation company, user, service organizations, recycler,
authorities), and internally (e.g. design department, production
planners, workers).
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 38
Table 8: Involved lifecycle actors of the concerned PLANTCockpit
application
ID Actor External / Internal
Describe how they will be involved, their role and impact of the
PLANTCockpit technology
Importance / Relevance High, Medium, Low
AC1 AC2 AC3
3.7.2.4 Physical components considered in the application Define
all of the PLANTCockpit applications physical components, their
functionality, and their relation to the Application objectives
using Table 9 (i.e. how does the inclusion of this component
contribute to fulfilling the objectives defined previously in this
document). Indicate also if the component is to be Included in the
PLANTCockpit application, if it is Optional (i.e. could be omitted,
but would be nice to have), or Not if it is not to be included.
Table 9: Physical components of the concerned PLANTCockpit
application
ID Physical component
Describe functionality
Relation to Application objectives
Focus in PLANTCockpit Included, Optional, Not
PC1 PC2
3.7.2.5 The application software/support-systems Describe the
software/support-systems of the application (e.g. ERP, MES,
decision support systems) that are part of the whole PLANTCockpit
Application by using Table 10. Describe functionality of the
systems and indicate if the system is to be: Included (must be
included in the work of PLANTCockpit); Optional (may be included,
but not necessary in order to fulfil the objectives defined
previously, Not (not to be included).
Table 10: Support systems / other systems external of the
concerned PLANTCockpit application
ID Software / support systems
Describe functionality
Relation to Application objectives
Focus in PLANTCockpit Included, Optional, Not
SS1 SS2
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 39
3.7.2.6 Description of the functionality of the application In
this section, all necessary functionalities of the application are
to be defined according to Table 11. This is an important summary
of the functionality of the Application. Be as specific as possible
in this table as this forms the basis for development of the
PLANTCockpit technology and support systems. The input in this
table forms the basis for making IDEF diagrams of the
functionalities. It is therefore required to add enough information
in order to fulfil the requirements of IDEF diagram. Every
functionality should at least have one control, one input, one
output, one technology/system/actor.
Table 11: Functionalities of the concerned Application
ID Functionality Requirement(s) Define the inputs needed to
achieve this functionality and relate the input to other FU IDs
(e.g. output data from FU3)
Define the outputs from this functionality
What are the controls
Technologies/Systems/Actors involved Describe the technologies
involved, or assumed technology/systems needed
Rationale Describe why this functionality is needed
Priority High, Medium, Low
Related to objective ID (
FU1 FU2
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 40
3.7.2.7 Information flow modelling template and guide (Swim
lane) In this section, with the proposed modelling templates,
PLANTCockpit end-users will be able to provide workflow and
information flow models with collaboration with other partners in
order to consolidate their models for PLANTCockpit
applications.
3.7.2.7.1 Description of basic symbols of event and information
flow modelling templates
The proposed description of event and information flow consists
of basic modelling components such as process, Boolean operators
and information symbols.
Table 12: Basic symbols for workflow and information
modelling
Modelling components
Symbol Description
Process
text: Arial 10pt
It indicates a business processing unit that has an explicit
role. It will be initiated by input events and produce output
events. In the data aspect, it requires inputs for its execution
and makes outputs as the result of the execution.
Event
text: Arial 10pt
It indicates the change of state that takes place as a result of
a process.
Information
text: Arial 10pt
It is a set of data objects which have similarity in their
semantics.
Operators V
OR operator
V
AND operator
XOR
XOR operator
Link Workflow
Information flow
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 41
3.7.2.7.2 Event process chain diagram for workflow modelling The
proposed modelling approach is based on discrete process modelling
method. Event-driven process chains are an intuitive graphical
business process description language. The language is targeted to
describe processes on the level of their business logic, not
necessarily on the formal specification level, and to be easy to
understand and use by PLANTCockpit partners. Modelling template
(Swim lane): This template enables (Figure 30) the end-user to
define event process chain, using previously described symbols
through the main elements of the system architecture (columns). A
process consists of sequences of events triggering business
functions, which are themselves the results of other functions
apart from initial events triggering the whole process. By
introducing Boolean operators, the event-driven control structure
can be expanded to a complex control flow illustrating business
relevant decisions.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 42
Figure 30. Swim lane template
Device controller PDKM system
Design knowledge
experts...DSSPEID
E2
E5
V
E8
P2
P3
E6
E1
P4
E3
V
XOR
E7
E4
P1
Condition 1
Condition 2
Condition 3
Condition 4
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 43
Guideline:
- Please think of columns of the swim lanes in your application.
They must correspond to the main elements of the system
architecture;
- Please consider the flow of information in your application,
i.e. from data gathering to analysing to decision and feedback.
Based on them, describe necessary events and processes.
Remarks:
- If possible, please use the Microsoft Visio modelling
template. If it is not possible to use Microsoft Visio, please use
Microsoft PowerPoint. In that case, please keep in mind to follow
the same font and size and symbols of modelling components;
- Consider not only system aspects but also human interactions
in considering the column of swim lane;
- As much as you can, please describe the workflow modelling in
detail. It will be helpful to not only you but also other
partners;
- Do not duplicate information or processes in the diagram.
3.7.2.7.3 Information flow diagram for information flow
modelling Information flow modelling is a technique that allows a
formal description of a domain of interest to be defined. The
resulting information model may be used for many purposes,
including helping to improve the understanding of the domain, or
providing a basis for implementation. Here, an information flow
diagram (Figure 31) is proposed including previously described
symbols.
Modelling template:
Figure 31. Information flow diagram
Guideline:
- Please reuse processes that are defined in the workflow
modelling; - Please describe necessary information for each
process: input and output;
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO
PLANTCockpit_D2_1_Public.docx 44
- Please think of links of this information with processes. If
necessary, you can define necessary processes more in your diagram
(in this case, you should modify the workflow modelling
diagram).
Remarks:
- Do not duplicate same information or processes in the diagram;
- As much as you can, please describe the information flow
modelling in detail. It will be
helpful to not only you but also other partners; - Please
represent the link between processes with a dotted arrow.
3.7.3 Summary - Requirements specification aims to integrate the
output from all previous stages in the
analysis process together and puts forward a full description
and understanding of what you want the system to do. The goal
hierarchy model features a set of observations which are evaluated
by the end user (Line Manager) in order to rank and rate certain
constraints within the system in order of priority. Factors
influencing the order of priority on constraints are represented in
more detail in the subsequent control flow diagram. These are then
mapped into a partial set of basic user/system interactions and use
cases as defined in the final UML use case diagram which represents
the system, its actors (users, external data sources as well as any
other entities whose behaviour the system cannot control or
change);
- UML is often the modelling tool of choice for Requirement
specification, there are various commercial and open source
offerings available.
The relationship between models across the CWA phases is
represented in Figure 32 below; it shows each phase of the analysis
process and how the relevant templates have been applied to the
manufacturing case study as described in previous section of the
document. It shows the mapping between each phase of the CWA
process. Progression through the CWA process is iterative in
nature, as more knowledge is discovered, the number of artefacts
and models will increase in line with this, which results in a full
understanding of the functional requirements of the system.
-
Project - No 260018
Date 10.12.10
Method to collect, document, and analyse user requirements
Classification CO