Interfaces For Human-Robot Interaction - Project Guidelines: 1. Formulating The Problem

Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

Interfaces for Human-Robot Interaction - Project Guidelines

Document version: 2018-11-26

Contents
1. Formulating the problem................................................................................................................................1
2. Structuring requirements............................................................................................................................... 2
3. Exploring variants........................................................................................................................................... 5
4. Planning technical performance.....................................................................................................................7
5. Planning functions and hardware components.............................................................................................12
6. Supervisory and control functions.................................................................................................................15
7. Usecases....................................................................................................................................................... 17
8. Wireframing................................................................................................................................................. 20

1. Formulating the problem


To put it simple, the problem statement is “design an assembly system for a given product”. For instance,
to assemble an electric extender. Solving the problem should be straightforward: we analyse the product,
its parts, the assembly system, and sketch the robotised process accordingly. We then model the robotised
line, we develop the control algorithm, and this should be it. Problem (apparently) solved.
Real life adds obviously more to it: for instance, what about costs? Return on investment? Productivity?
Should we assembly 10 extenders per minute? Should there be 100 units produced per minute? Should the
process be flexible, e.g. assembling extenders of different colours or with different “options” like USB plugs
or on/off knobs? Should the robotised line be compact? How many square meters should it fit in? Should it
be assembled in one day, as our clients may be overseas? Should maintenance be done remotely, to
reduce future operating costs? Should we guarantee a precise reliability level? For instance no more than
30 minutes as a downtime per year?
How do we reconsider the problem, given all the questions above? First, we should understand all the
needs and requirements of all the stakeholders: the robotized line user (the operator), the maintenance
engineers, the safety engineers, and the management team. We should analyse these requirements and
understand which are the most important, so that we can design our solution to specifically meet these
requirements.
Second, we should explore general technical solutions for solving the problem. Simple sketches of
robotized lines having various layouts, using two or more robots, various part supplying methods, etc.
Usually three such sketches, reflecting different concepts, should be developed. We should then see which
of them best responds to the requirements identified in the above step – this concept (sketch) should be
further developed.
Before detailing the sketch, we should decide how to measure its technical performance. This should be
done by developing a list of metrics – quality (or performance) characteristics – to measure the robotised
line performance. Examples of such metrics could be the cycle time, the energy consumption, the
footprint, etc. We should then plan these performance characteristics with respect to the requirements –
i.e. set a target value for each characteristic so that the future line will be competitive (have success on the
market). For instance, 12 seconds for assembly cycle time (the time to assemble an extender), or 20 square
meters for the line footprint.
Next, we should determine what functions should our line perform in order to assemble the electric
extender in such a way that target values for performance characteristics are met. For instance, targeting 12
seconds for productivity may require two assembly spots (i.e. 2 robots), while a value of 30 seconds (if this
would have been acceptable) might have required just one assembly spot (with one robot). We should
therefore consider a function (or more) to get the assembled products from both the assembly spots and
move them to the packaging spot. Some functions may have a software implementation, for instance a
function warning the operator that some parts are running out.
Once it’s clear what functions should be implemented, we can actually design our robotized line. We
should consider not only the actual hardware (robots, conveyors, etc.), but also the control algorithm and
the software interface (for operating the line or performing maintenance). When finished, we should check
(and justify) that the target values for performance characteristics are likely to be met.

2. Structuring requirements
Before starting the robotised line design process, the analysis team has to make several judgements and to
take specific decisions regarding the key requirements related to the given application. Who’s interested in
the system we’re developing (i.e. which are our stakeholders)? Note that it’s not just the users of the future
system (operators or maintenance engineers), but all those at the business or enterprise operations level:
users, integrators, customers, and any other (type of) persons or organizations that relate to the problem.
Each of these stakeholders may have his or her own requirements, which should be captured by the
analysis team.
Some requirements or needs may be directly expressed, but some not. A stakeholder may not formalise
(or even understand) his complete needs – for instance, the customer may not consider quick installation as
a requirement, but – at some time – he might move to a new facility and want to quickly reinstall all his
systems. The analysis team should, however, “guess” this requirement and document it accordingly.
To extract requirements (and – later – define performance characteristics), the analysis team can also
check against specific design guidelines to be found under the label Design for X (Design for Excellence) [1]
[2]. Each design guideline addresses a given issue that is caused by, or affects the traits of, a product. These
design guidelines cover all the product life cycle phases (development phase, production phase, use phase,
and disposal phase). Examples of such design guidelines: design for short time to market, design for
reliability, design for test, design for safety, design for quality, design against damage, design for minimum
risk, design to cost, design to standards, design for assembly, design for manufacturability, design for
logistics, design for low-quantity production, design for user-friendliness, design for aesthetics, design for
serviceability, design for maintainability, design for recycling.

Example list of requirements (students can use these as a starting point for their own requirement list):
• reliable
• small footprint
• easy access to hardware components
• reduced energy consumption
• low cost per produced unit
• friendly user interface
• easy to be transported and installed
• increased productivity
• increased safety level
• low scrap rate
• easy supply process (with extender parts)
• high percent of reusable hardware components
• reduced maintenance time
• reduced maintenance costs
• easy to be monitored

Once requirements are identified, the next important step is to rank them, to determine their importance
level so that the design process can be oriented towards producing a robotised cell to fulfil these
requirements. A systematic method like AHP – Analytic Hierarchy Process – should be used for
requirement ranking.
Within this document, the AHP is exemplified by using the Qualica QFD software tool. The screenshots are
made with Qualica2005. The instructions are adapted to the same software tool. One can use any other
software tool, as the steps to follow should be similar.
After starting Qualica, create a new project and choose the template “Tree Diagram with AHP” (see Figure
1).

Figure 1. Qualica QFD: Template selection.


At “Select location” choose “Create new database” and then specify where to save your work (folder and
file name), under “Target directory”. In the next step choose a relevant name for your new workbook (for
instance requirements analysis). In the left corner of the Qualica window you will find a tree representation
of the project structure (including all its workbooks), see Figure 2.

Figure 2. Qualica QFD: The project tree.


Double-click on “ITEMS” and enter here the list with the requirements for the robotized cell. Use the

buttons to add new requirements or to reorder the already introduced ones. Then
click “Toplevel comparison matrix”. If the displayed matrix is “empty”, right-click in the “Input ...” area,
choose “Replace tree” (see Figure 3), and select ITEMS.

Figure 3. Qualica QFD: How to set up the AHP analysis matrix.


Complete the matrix by comparing each two requirements and determining a relative importance of that
one on the row against that one on the column. To specify the relative importance, click in the
corresponding cell and select a value above 1 if the requirement on the row is more important than the one
on the column. Select a value below 1 otherwise (or exactly 1 if the requirements are equally important) –
see Figure 4.

Figure 4. Qualica QFD: How to complete the AHP analysis matrix.


When finished, click on the Recalculate now button (see Figure 5).
Figure 5. Qualica QFD: The toolbar containing the Recalculate Now button.
The (relative) importance of each requirement is the numerical value (percent) in the column in the right
part of the analysis matrix (Importance in group). You can visualise the sorted requirements by choosing
Sorted Results from the project tree (the top left part of the Qualica window) - see Figure 6.

Figure 6. Qualica QFD: The sorted results view.


You can also compute a consistency index for your analysis. Details can be found in the technical literature.

3. Exploring variants
Usually, at the beginning of the design process, several possible solutions may seem appealing. One can
explore various layouts for the cell, do assembly with one or two robots, do a pre-sorting of parts before
assembly or sort them afterwards, implement quality inspection in several ways, etc. A good practice is to
sketch three possible technical solutions (variants) for the problem we’re considering (i.e. designing a
robotised cell to assembly, pack and palletize a product) so that the requirements above are fulfilled as
good as possible. Variants should not be too detailed in this step, but rather serve as a base to be further
developed. Advantages and disadvantages should be provided for each variant.
The variants will then be checked against the requirements. The one that best fulfils them will be further
considered in the design process, i.e. the solution will be built upon the variant that best fulfils the
requirements.
A way to assess (rank) the variants is the Pugh method, also implemented in the Qualica QFD software.
Select some item in the workbook tree (the upper left part of the Qualica window) and choose New – Pugh
New Concept Selection. For New Concepts choose Leave Unchanged, while for Criteria choose Link to
existing tree and select ITEMS (i.e. the requirements you have just ranked with the AHP method) – Figure 7,
a. Specify a name for the new workbook, for instance “variant selection”. The new workbook will be
displayed in the workbook tree – Figure 7, b.
Figure 7. Qualica QFD: (a) Linking the ITEMS tree; (b) the updated project tree.
To enter the three variants, choose New Concepts in the workbook tree. Type the solutions in the
corresponding table. Select then New Concept Selection and complete each matrix cell by identifying the
relation between the selected variant and the selected requirement (i.e. how much does the selected
variant fulfil the selected requirement) – see Figure 8.

Figure 8. Qualica QFD: completing the Pugh method matrix.


When finished, click the Recalculate Now button. You will get, in the bottom lines of the matrix, the scores
for each variant. The scores reflect how well each variant responds to the requirement set (Figure 9).

Figure 9. Qualica QFD: the results of the Pugh analysis.


If two variants get similar scores (i.e. a difference up to 5%), you are advised to define more criteria to
differentiate them.

4. Planning technical performance


The needs or requirements discussed above represent the so-called Voice of the Customer. They’re
expressed using plain language and are quite vague for an engineer. They should be translated into
something that engineers can understand and further transform in an effective design. One of the
established methods to do this is the Quality Function Deployment – QFD. It transforms the needs
(requirements) into technical characteristics – the so-called Voice of the Engineer. In other words, it helps
create operational definitions of the requirements, which may be vague when first expressed. The QFD
method prioritizes each product or service characteristic while simultaneously setting development
targets for the product or service. It translates often subjective quality criteria into objective ones that can
be quantified and measured and which can then be used to design and manufacture the product. For
example, a requirement for a pen would be ease of writing. This is unclear for an engineer – pen ink viscosity
or pressure on ball-point would be much more interesting to him, as these characteristics can be measured.
Typically the QFD consists of four phases – see Figure 10. These phases are: product planning, product
design, process planning, and process control.

Figure 10. The four QFD phases.


This material will focus on the first QFD phase, or product planning – the so-called House of Quality (see
Figure 11). Many organizations only get through this phase of a QFD process, although effective quality
planning requires all the four phases.
Figure 11. The House of Quality.
This material discusses how to build the House of Quality (i.e. the first phase of QFD). The next three
phases are similar in terms of graphical support, excepting the House of Quality Roof and – of course – the
data on rows and on columns.
Completing the House of Quality typically implies twelve steps:
• Step 1: Customer Requirements - "Voice of the Customer"
• Step 2: Regulatory Requirements
• Step 3: Customer Importance Ratings
• Step 4: Customer Rating of the Competition
• Step 5: Technical Descriptors - "Voice of the Engineer"
• Step 6: Direction of Improvement
• Step 7: Relationship Matrix
• Step 8: Organizational Difficulty
• Step 9: Technical Analysis of Competitor Products
• Step 10: Target Values for Technical Descriptors
• Step 11: Correlation Matrix
• Step 12: Absolute Importance
Steps 1-3 are typically done by applying the AHP method described above. If information regarding
competitors is available, we can also rate how well the competition responds to the requirements we have
identified (Step 4). The results should be similar to the example in Figure 12.
Figure 12. Qualica QFD: Customer requirements data.
Step 5 consists of identifying the technical descriptors, i.e. the Voice of the Engineer. The technical
descriptors / performance characteristics are attributes about the product or service that can be measured
and benchmarked against the competition. Your organization may already use specific metrics to
determine product specification, however new ones can be added to ensure that your product is (or will be)
meeting the customer needs.

Metric (performance characteristics) set example for a robotized system to assemble, check, pack and
palletize electric extenders (students can use these as a starting point for their own performance
characteristics list):
[reliability] unintended downtime (due to undetected errors) within 1 month hours ↓
[reliability] no. of process parameters for which historic data is stored - ↑
[testability] no. of built-in self-tests (for remote diagnosing) - ↑
[reliability] mean time between failures days ↑
[reliability] time to signal a self-detected error min ↓
[reliability] percent of correct resumes after a failure % ↑
[safety] unauthorized access incidents within 1 month (how many times unauthorized - ↓
personnel entered the production line area)
[safety] security incidents within 1 month in the production line area - ↓
[safety] security incidents within 1 month in the proximity of the production line area - ↓
(1m along the fences)
[quality] goods count / hour - ↑
[quality] percentage of defective goods count out of the actual production count % ↓
(rejection ratio)
[quality] overall equipment effectiveness (multiplies availability by performance and - ↑
quality to determine resource utilization) - shows the overall performance of the
factory
[quality] capacity utilization % ↑
[flexibility] time to make changeovers min ↓
[flexibility] number of products that can be produced on the line - ↑
[low cost] total manufacturing cost per unit excluding materials EUR ↓
[low cost] energy consumption per unit kWh ↓
[low cost] footprint m2 ↓
[assembly] line installation time (at a customer's facilities) hour ↓
[assembly] number of hardware components - ↓
[assembly] number of electrical and pneumatic connections to be made - ↓
[usability] training hours for a newbie operator hours ↓
[maintainability] planned maintenance foreseen time within 1 month hours ↓
...

Step 6 implies identification of the improvement direction for each metric – what means improving it’s
value?
Step 7 requires the completion of the relationship matrix. The analysts team determines the relationship
between customer needs and the company's ability to meet those needs (via the metrics or technical
descriptors). Each matrix cell should reflect the answer to this question: What is the strength of the
relationship between the technical descriptors and the customers needs? Relationships can either be none,
weak, moderate, or strong and carry, for example, a numeric value of 1, 3 or 9. Different scales may be
used as well. Not all requirements are related to a metric and not all metrics are related to a requirement
(several “none” values will exist in the relationship matrix). In other words, the relationship matrix will not
be “fully completed”. An example is shown in Figure 13.

Figure 13. Qualica QFD: The relationship matrix.


Step 8 requires technical descriptors ranking from an organizational (not technical) difficulty perspective.
Step 9 consists of a technical analysis of competitor products (if adequate information is available), to
better understand the competition. The process involves reverse engineering competitor products to
determine specific values for each technical descriptor identified in step 5 above.
Step 10 implies setting target values for the technical descriptors. The target values represent "how much"
for the technical descriptors, and – from this stage on – the product (service, process) design should be
done to obtain these target values.
Use the same table from above (Step 5) for listing the performance characteristics of the robotized line you
have to design. Add a column to the right, name it "target value" and add adequate values for each
performance characteristic (metric). Example (excerpt from the above table):
Performance Characteristic M.U. Opt. Weight Target
from Value
QFD
...
mean time between failures days ↑ 6,03% 15 days
time to signal a self-detected error s ↓ 8,20% 2s
percent of correct resumes after a failure % ↑ 3,40% 98%
unauthorized access incidents within 1 month (how many times - ↓ 2,59% 0
unauthorized personnel entered the production line area)
security incidents within 1 month in the production line area - ↓ 4,37% 0
security incidents within 1 month in the proximity of the production line - ↓ 4,25% 0
area (1m along the fences)
Performance Characteristic M.U. Opt. Weight Target
from Value
QFD
goods count / hour - ↑ 11,20% 420
percentage of defective goods count out of the actual production count % ↓ 7,22% 0,01%
(rejection ratio)
...
Step 11 requires the completion of the correlation matrix (the roof of the House of Quality). The analysis
team members must examine how each of the technical descriptors impact each other. The team should
document strong negative relationships between technical descriptors and should work to eliminate
physical contradictions. Innovative problem solving tools like the TRIZ Contradiction Matrix can be used in
this step.
Step 12 implies the determination of the absolute importance of the technical descriptors (automatically
done by software tools that implement the House of Quality). The most important descriptors matter the
most to your customer.
Figure 14. Qualica QFD: An (almost) completed House of Quality.
As a final note, before declaring the House of Quality complete, have a short check if, in the relationship
matrix, there is at least one strong relation on each row and each column. If there is no strong relation on a
column, the technical characteristic on that column may not be relevant (it’s not related to any
requirement), so either remove it or check if the requirement list is complete. If there is no strong relation
on a row, you probably should extend the technical characteristic set, as the requirement on that row will
probably not be fulfilled through the current quality level. You can see in Figure 14 an example of a
complete House of Quality.

5. Planning functions and hardware components


Up to now, we know what is needed / requested from the assembly system we’re designing. We also know
what quality level our assembly system should have. But before starting to actually design it, it is a good
practice to identify all the required functions of the assembly system: what should it actually do? We
already have a concept: the variant from section 2.3 that best responded to the requirements. We should
now decide upon all the functions that should be built in our assembly system. We should consider both
core and auxiliary functions. Some may be implemented purely hardware, but some will also have a
software component (or be even completely software implemented).
To exemplify, some functions of the palletizing zone of the assembly system could be:
• to allow supplying the process with pallets (to be done at any time needed – pallets should be
placed over the existing pallet stack, e.g. with a forklift)
• to extract one pallet from the pallet stack on the conveyor towards the loading point
• to move (and precisely position) the extracted pallet to the loading point
• to move the (loaded) pallet from the loading point onto the conveyor which takes it to the wrapper
• to wrap the loaded pallet
• to move the wrapped pallet outside the robotized line
Examples of functions to be implemented software:
• allow operator login and logout
• display robotized line status screen (number of extenders assembled, number of loaded boxes, of
loaded pallets, number of parts, etc.)
• display warnings (when the process should be supplied with specific parts)
• display process status (running, idle, stopped)
• display issues and errors (if any)
• adjust settings (e.g. pressing force)
• display maintenance information (e.g. warnings, reminders)
Note the way of formulating function names (denoting an action). Never use a hardware component
as a function name (e.g. robot or sensor).
To (correctly and completely) identify the functions you can develop the flowchart diagram for the process
you need to automate (i.e. the assembly, quality checking, packing and palletizing sub-processes). An
effective tool to support the process modelling is the IDEF0. IDEF0, a compound acronym ("Icam
DEFinition for Function Modeling", where ICAM is an acronym for "Integrated Computer Aided
Manufacturing"), is a function modelling methodology for describing manufacturing functions, which
offers a functional modelling language for the analysis, development, re-engineering, and integration of
information systems; business processes; or software engineering analysis. Read the article about IDEF0
on Wikipedia for a deeper understanding of this methodology. You can see a simple flowchart example
(using IDEF0) in Figure 15.
Figure 13. The "Maintain Reparable Spares" process modelled with IDEF0 blocks (source: Wikipedia).
Figure 14 shows an (incomplete) flowchart diagram draft for the robotized line. Figure 15 shows a detail of
it (the assembly sub-process). Use these figures as starting points to develop your own version of flowchart
diagram for the process you need to automate. Mind that the solution depicted in Figures 14 and 15 may
not be optimal or may have inconsistencies. Use it just as an example to get familiarized to the IDEF0
methodology.

Figure 13. The (draft) flowchart diagram for the entire process.
Figure 14. A detail of the flowchart diagram - the assembly sub-process.
In Figure 14, [w] is a shortcut to a connecting point to the supervision and monitoring functions. It's used
for outputs of type data which are inputs for software functions which handle process parameters. The [d]
shortcut means decisions (usually 0 or 1) automatically taken by the system (e.g. call a specific function).
Hardware components (and software modules and interfaces) should then be selected and integrated in
the robotized line. We should then check that all functions can be adequately performed with the
hardware components we selected. We can use the graphical support of the QFD method for this – by
placing functions on the lines (the inputs) and hardware modules on the columns (the outputs). When
building the relationship matrix, we should have at least one strong relation on each row and each column.
The flowchart diagram (modeled with IDEF0 blocks) can be extremely helpful - each IDEF0 block has to
document also the mechanism for implementing the function (e.g. for the "assembly the electric extender"
function the mechanism may consist of a robot + gripper and an indexing table). By centralizing all the
mechanisms of the IDEF0 blocks we should get a fair hardware list (and software blocks) for our robotized
line.

6. Supervisory and control functions


As discussed in the previous sections, there are several user categories that need to interact with the
robotized line, like users in charge with the line "normal" operation (operators), users doing the (manual)
quality check of the assembled extenders (each 1 out of 20 assembled extenders), users doing preventive
maintenance, or users supervising the functioning of the line. Each user type (role) requires specific
information from the system and also needs to provide specific data. Moreover, each such role may have
different requirements regarding the hardware terminal displaying the information he or she needs. Users
supervising the functioning of the line (along with other lines in the production facility) may want to see
data on a computer in their office, the operator may want a mobile device for warnings (he's probably in
charge of more lines) and an operator panel for advanced operations, while the user doing maintenance
may require a tablet for getting the data he needs.

For our automated line we'll consider the following HMI hardware: mobile phone (for the operators and
maintainers), operator panel (also for the operators), standard computer (for the supervisors), and ANDON
system (for the general line status visibility).
Use the following function list as a starting point and identify all the functions that should be developed
in your case. Consider also the target values for the performance characteristics that you established
in section 4 (check the notes below).
On mobile devices (e.g. smartphones):
• authentication [login/out],
• line start / stop [stop / stop after finishing current pallet / restart / emergency stop]
• display statistics [functioning state display, logged user, start time + uptime, number of extenders
assembled, number or percent of scrap, productivity figures like extenders / hour, boxes / hour,
pallets / shift, number of incidents, part stock (for each part), energy consumed, etc.]
• warnings [if an error occurred, if the cardboard stack is near to empty, if parts run out soon, if a
pallet is loaded, if pallets should be supplied etc.]
On the operator panel:
• authentication [login/out],
• line start / stop [stop / stop after finishing current pallet / restart / emergency stop]
• display statistics [functioning state display, logged user, start time + uptime, number of extenders
assembled, number or percent of scrap, productivity figures like extenders / hour, boxes / hour,
pallets / shift, number of incidents, part stock (for each part), energy consumed, etc.]
• settings [type-of-product if you opted for a flexible solution]
• self-tests [using a "maintenance mode"]
• logs [assembly, quality check, packing, palletizing]
On the ANDON system:
• stats [functioning state display - these will be actually the three lamps: green, yellow, and red]
On the supervisory center computer:
• planned maintenance operations (and due date)
• provide help on maintenance operations
• warnings on due maintenance operations
• maintenance log (what was done / by whom)
On the manual quality area interface:
• show reference extender specifications and images
• take picture of non-compliant product(s)
• enter compliant/non-compliant flag and additional text
• line start / stop [stop / stop after finishing current pallet / emergency stop]

Notes on how to establish functions considering the performance target values:


• if percent of correct resumes after a failure target value is high, you should also consider a stop after
finishing current pallet function, i.e. the user hits stop but the system continues working until the
current pallet is completed (but no other extender is assembled)
• if percent of correct resumes after a failure target value is high, you should also pay attention to the
palletizing sequence: in case of an unexpected stop, the robot should be told, when resuming,
what box to continue with (e.g. the 15th box); the palletizing sequence (and index) should
therefore be always saved to the database
• if the rejection ratio target value is low (meaning as few errors as possible), you should carefully
consider the manual check functionality: to be able to track assembly problems, one needs to
know as much information as possible about errors, so the operator doing quality check is required
to provide this type of data. The operator should enter, via the interface, a description of the
problem he detects, along with pictures of the product - therefore his workbench should include,
apart from the HMI, a camera
• if security is a critical issue, e.g. unauthorized access incidents within 1 month has a target value of
0, you should consider not only locking the access gate, but also incorporating a camera and a
proximity sensor, and implementing a function to automatically take pictures of the line area and
store them along with the information regarding the unauthorized access (storage to be done in
some security-related log). If security is not critical, e.g. unauthorized access incidents within 1
month has a target value of 3 for instance, a simple fence and gate setup would suffice
• if productivity is important, i.e. goods count / hour has a high value (e.g. you want to assemble 1000
extenders per hour), you should consider including 2 assembly points (as one will probably not be
enough). This means you should supply parts to both these points and then "combine" their output
into one flow. If the target value for goods count / hour is lower, you need only one assembly point.
Tip: estimate the needed time to assembly one extender (usually a few seconds) to determine the
capacity of one assembly point
• if time to signal a self-detected error has a low value (e.g. a few seconds), i.e. an error has to be
quickly noticed (the employee in charge of monitoring the line should see the error message, not
only receive it), you should probably consider building a software module (of the monitoring and
control application) to run on a mobile device (e.g. smartphone); when designing the interface for
this software module, any error state should be visible (like receiving a new important message in
a messaging app)

7. Usecases
As discussed in the course on interfaces, from the user perspective, a product is it's interface. The interface
is the space where interactions between the user and system occurs, therefore each function in the
process flow diagram that implies user interaction will need an interface. The application we're now
designing will aggregate the interface from all these functions.
A usecase is a list of actions or event steps typically defining the interactions between a role and a system
to achieve a goal (i.e. perform a function). The actor playing the role can be a human or other external
system. A usecase captures some user visible function. Functions may be a large or small; it depends on
the level of detail in your modeling effort. A usecase achieves a discrete goal for the user, like format a
document or request an elevator. Actors are external entities that interact with the system. It can be a
person (a person category), another system or an organization. The actor list, in our case, consists of
operator, maintainer, technical supervisor, and quality inspector, as already discussed in Section 6 above.
A person using the system (a user) may have one or more roles. For instance, user Cristiano can be both
operator and quality inspector. User Sergio could be both maintainer and technical supervisor, while user
Roberto may be only maintainer.
Build the usecase diagram corresponding to our project. Follow the example in Figure X below.
Figure 15. An example usecase diagram.
For each usecase a description table should be produced. Choose 5 usecases (any you like) and develop
their corresponding description table. See the course on usecases for details. An example of how you
should structure the description table can be found below. See also an example in Figure 16.
Usecase name show robotized line status (and production indicators)
Scenario stay informed on how the line operates
What triggers this usecase user authentication
Brief description list here the production indicators to be displayed, any of them that should
be highlighted etc.
Actor (who is performing operator, maintainer, supervisor
this?)
Related usecases login, logout, view logs, view warnings, etc.
Stakeholders customer, business owners, technical department
Pre-conditions user should be authenticated
Post-conditions -
Flow of activities Actor System

Exception conditions • if on mobile device and network not available, warn that displayed
information may be outdated
• (identify also other possible exceptions)

Figure 16. A usecase description example.


See the usecase tips & tricks in the course slides in order to produce effective usecases.
8. Wireframing
A wireframe (page schematic, screen blueprint) is a visual guide that represents the skeletal framework of
an application screen or a website.
At the wireframing phase of the design process, our ideas are young and unpolished. Wireframes, whether
created on scraps of paper, a whiteboard, or in a software program, serve to establish relationships
between elements in a project such as: navigation, imagery, and calls to action
[https://www.dtelepathy.com/blog/design/learning-to-wireframe-10-best-practices].
See Figure 17 for two wireframe examples.

Figure 17. Wireframe examples.


Develop wireframes for all usecases you identified in the usecase diagram. Mind that one usecase may
require several wireframes, depending on the user-system interactions it contains.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy