Cyber Crime and Cyber Terrorism

45
 
User requirements and the need for a user-centered approach? 
Only by considering these issues and understanding the underlying requirements that 
different users and stakeholders might have, can a more integrated approach to cyber-
security be developed from a user-centered perspective. Indeed, for cyber-investiga-
tions, these issues pose important questions to consider in exploring the basis upon 
which cyber interactions might be based and where future efforts to develop solutions 
might be best placed.
USER REQUIREMENTS AND THE NEED FOR
A USER-CENTERED APPROACH?
When investigating user needs, a fundamental issue is the correct identification of 
user requirements that are then revisited in an iterative manner throughout the de-
sign process. In many cases, user-requirements are not captured at the outset of a 
design process and they are sometimes only regarded when user-trials are developed 
to evaluate final concepts (often when it is too late to change things). This in itself is 
a major issue for developing successful products and process that specifically meet 
user needs. A further consideration in relation to user requirements for cyber-security 
is in the forensic examination techniques more commonly employed in accident in-
vestigations to provide an insight into the capabilities and limitations of users at a 
particular point when an error occurred.
More usually when writing requirement specifications, different domains are 
identified and analyzed (
Figure 5.1
).
For example, if a smart closed circuit television (CCTV) system was being de-
signed it would be necessary to consider:
• Inner domain—product being developed and users (e.g., CCTV, operators) 
including different levels of system requirements to product level requirements.
• Outer domain—the client it is intended to serve (e.g., who the CCTV operator 
reports to).
• Actors—human or other system components that interact with the system (e.g., 
an operator using smart software, or camera sensors that need to interact with 
the software, etc.).
• Data requirements—data models and thresholds.
• Functional requirements—process descriptors (task flows and interactions), 
input/outputs, messages, etc.
This offers a useful way of conceptualizing requirements and understanding non-
functional requirements such as quality assessment, robustness, system integrity (se-
curity), and resilience. However, a more detailed approach is often needed to map 
user requirements. User requirements are often bounded by specific “contexts of 
use” for investigations as this provides design boundaries as well as frames of refer-
ence for communicating issues back to end-users and other stakeholders. In order 
to achieve this, it is often necessary to prioritize potential solutions to ensure that 
expectations are managed appropriately (
Lohse, 2011
).

---