Objective

The concept and planning phase is conducted early in the project timeline. The aim of this phase is to understand stakeholder and user needs, explore and decide upon options, define a concept of operations and define system requirements. This phase also ensures that there is a structured approach to project delivery including task planning, resource identification, scheduling, and project risk management.

Needs assessment

Description

A needs assessment involves engaging key stakeholders to gather, understand, and prioritise high-level needs that the project should address. This includes safety improvements, user experience, maintenance requirements, operational constraints, and regulatory compliance. The process is iterative and revisited throughout the project lifecycle to ensure alignment with stakeholder priorities and evolving conditions.

Key activities

1. Identify relevant stakeholders. Include rail transports operators (including infrastructure managers and rollingstock operators), road authorities (state and local governments), and others with an interest such as regulators, industry bodies, unions, professional associations and road user advocacy bodies. Ensure that relevant representatives are engaged including those who would be involved in the integration, operation and maintenance of the technology.
2. Elicit needs. Collect information regarding user and stakeholder needs via activities such as interviews and workshops, review of incident and traffic data, and review of key documents including legislative frameworks such as the Rail Safety National Law, as well as workplace health and safety, privacy and cybersecurity laws. Tools like ALCAM or LXM may also be consulted to provide quantitative insights into crossing risk profiles, exposure metrics, site-specific hazards and previous incident history.
3. Document needs. Compile the elicited needs into a structured document, highlighting priorities and constraints.
4. Validate needs. Present documented needs to stakeholders to seek feedback and gain agreement. Workshops can be used to ensure comprehensive and shared understanding.
5. Prioritise needs. Use a structured approach such as multi-criteria analysis or consensus workshops to rank needs by considerations such as safety impact, feasibility, cost, and level of stakeholder support (using broad categories such as low/medium/high). Gain stakeholder endorsement of key needs.

Human Factors contributions to needs assessment

Human Factors ensures that user needs, behaviours, and limitations are understood early. This includes identifying key user groups, analysing how the system will be used in context, and highlighting relevant Human Factors-related considerations. Human Factors input helps prioritise safety and usability requirements from the outset of the project. When commencing a needs assessment phase, it may be beneficial to reach out to industry networks to ask if any colleagues have conducted Human Factors analyses which may be able to be shared or have conducted trials of similar systems from which lessons learned can be learned. 

1. Establish context of use. Human Factors specialists can provide input regarding the context of use. This encompasses the uses of the proposed technology, user goals and tasks, and the physical and social environment in which the technology will be used. One method that can be useful is user journey mapping to understand complete user experiences from approach to crossing completion, describing how road users would interact with new technologies. Additionally, consideration of how the proposed system would integrate within the wider sociotechnical system may be beneficial at this early stage. Systems Human Factors methods such as Cognitive Work Analysis may be beneficial.
2. Early Human Factors Analysis (EHFA). EHFA can be employed to understand potential human-system interactions and risks. It identifies primary user groups (eg road users) and secondary user groups (eg train drivers, maintainers, train controllers, emergency responders) and assesses impacts on users of different proposed changes (eg new warnings or signage). One method that can be useful is task analysis to uncover the potential benefits and risks of introducing new technologies through consideration of how existing tasks will change (see Generic Level Crossing Task Analyses). Human error identification techniques (e.g. SHERPA, HAZOP) and the Human Factors Risk Assessment Prompts can be utilised to consider potential risks. Accessibility considerations for users with diverse capabilities including age-related variations and cultural factors should be considered. Technology readiness assessments can also be utilised to evaluate user acceptance and trust factors across different populations. EHFA can also be informed by review of published research findings (see Literature Overview), incident data, findings from past level crossing safety investigations and relevant standards. Consider how the outputs of EHFA may be integrated into wider project risk assessment models such as bowtie or fault tree analyses, if relevant.
3. Human Factors needs elicitation and prioritisation. Human Factors specialists should be engaged within the needs elicitation and prioritisation processes (ie participate in interviews, workshops, and focus groups).  Input should be provided regarding Human Factors-related challenges and concerns, informed by the outcomes of the EHFA. 

Concept exploration and benefits analysis

Description

This activity helps define “what” the system should do, but not yet “how” it will do it. It precedes detailed system requirements and design activities and helps reduce risk by making early trade-offs and aligning stakeholders. The outcome is a well-defined system concept that is justifiable, feasible, and acceptable to key stakeholders. The activity involves engagement with key stakeholders to identify and evaluate alternate system concepts against project goals and constraints (eg budget, installation time, maintainability, and standards compliance). The result is a documented rationale for selecting a preferred high-level concept to move forward.

Key activities

The following activities may be utilised, with each including review by stakeholders:

1. Define the vision. Develop a short, plain-language description of what the technology will do (for example, "Provide early warning of approaching trains to road users at passive level crossings").
2. Set goals and objectives. Determine the overall goals of the implementation of the technology (for example, reduce collisions, reduce near misses, improve road user compliance).
3. Identify constraints. Constraints may relate to elements such as installation and use at remote locations with limited power sources and internet connectivity, requirements to operate in normal, degraded and emergency states, land ownership and access restrictions, regulatory approval pathways, and budget restrictions.
4. Define evaluation criteria. Identify relevant measures such as impact on road user detection of approaching train, impact on road user decision time, relevance to all road user types, installation and maintenance cost, user acceptance, regulatory compliance.
5. Identify candidate solutions. Identify a range of solutions that could support the vision. Individual components of solutions could focus on underlying technologies (eg low-cost power sources, train detection systems or communications systems) as well as options for the human-machine interface (that is, in what form the alert will be presented to the road user such as via an in-vehicle display, smartphone app, active signage, or in-road / tactile alerts).
6. Define alternative concepts. Combine candidate solutions into system-level concept options that consider both underlying technologies and the human-machine interface. Examples of options to be assessed could include:
   • Do nothing (baseline)
   • In-vehicle focused concept: Telematics-based alerts provided to road users on an in-vehicle display
   • Infrastructure-focused concept: Solar powered warning device provided at the crossing.
   • Hybrid concept: Combining infrastructure cues with in-vehicle display.
7. Evaluate alternatives. Use qualitative and quantitative methods to compare alternatives against the evaluation criteria.
8. Document results. Present a clear rationale for the preferred concept. Where required, include this in a formal Feasibility Study or Business Case.

Human Factors contributions to concept exploration and benefits analysis

Human Factors ensures that system concepts are evaluated through a human-centred lens. Human Factors specialists can assist in shaping evaluation criteria, assess how candidate solutions support user behaviour, and represent end-user perspectives in trade-off decisions, helping select concepts that are not only technically feasible but also effective in influencing behaviour and acceptable to users.

1. Input into vision and goals. Human Factors specialists can help to ensure the vision reflects human-centred goals such as supporting decision making, minimising distraction, optimising workload, and considering the user experience.
2. Identify Human Factors-related constraints. Human Factors specialists can contribute constraints related to users, such as the role of expectations, driver distraction and inattention, and the role of trust in warning systems (see Literature Overview).
3. Contribute to definition of evaluation criteria. Ensure Human Factors-related measures are included in the analysis (eg likely influence in shaping desired behaviour, user acceptance, ease of learning/use, error likelihood – see Human Factors Guide for Evaluating Innovative Level Crossing Technologies).
4. Assessment of candidate concepts. Provide expert input on the likely extent to which each concept supports human performance and decision-making in real-world contexts (eg under various weather conditions, time pressure, different road environments). Support early comparison of alternative concepts using desktop analysis approaches, which could draw upon task analyses (see Generic Level Crossing Task Analyses), human error analyses and previous research testing and evaluating similar concepts at level crossings or in other road environments (such as road intersections). Consider how Human Factors issues and constraints such as driver expectations, potential for distraction, trust in warning systems and willingness to wait may influence behaviour.
5. Document Human Factors considerations in concept selection. Articulate why certain concepts may be preferred from a Human Factors perspective. Human Factors analysis can support the development of a business case through an evidence-based rationale for concept selection.

Operational concept development

Description

Operational concept development aligns stakeholder expectations for the intended use and integration of the proposed technology. It establishes the operational foundation for design, requirements definition, testing, and validation, and supports ongoing stakeholder communication and informed decision-making, including around roles, responsibilities, and system use cases.

Key activities

1. Define vision, goals, objectives. Refine previously documented vision, goals and objectives, focusing on the selected concept, eg “provide active warnings to road users at passive crossings via low-cost, scalable solutions.”
2. Explore project concepts. Consider options such as train detection system and power sources.
3. Develop operational scenarios. Document a range of scenarios that cover normal operations, degraded conditions, and emergency situations.
4. Document the concept of operations. Present the system from each stakeholder's viewpoint in accessible, non-technical language. Include: stakeholder roles and responsibilities, operational scenarios, key assumptions and constraints (eg power availability, internet coverage), interfaces between technologies (eg vehicle systems, road/rail infrastructure), human-system interactions, and maintenance considerations.

Human Factors contributions to concept of operations

Human Factors helps ensure that the Concept of Operations reflects realistic and safe interactions between users and the system in both normal and degraded situations. Human Factors input shapes human-centred operational scenarios, identifies likely user errors and cognitive demands, and ensures that the system is accessible and understandable for diverse user groups. HF specialists engage stakeholders to validate assumptions about how people will interact with the system and contribute to ensuring operational use cases are practical, inclusive, and grounded in real-world behaviour.

1. Define operational context of use. Collaborate on the Concept of Operations document to describe how road users, train drivers, and other stakeholders interact with the system. Include typical and abnormal scenarios, error recovery, and degraded mode behaviour from a Human Factors perspective. This includes developing detailed error recovery scenarios, degraded performance conditions (eg user fatigue, distraction, impairment), and system failure scenarios (eg warning failures).
2. Scenario-based Human Factors analysis. Develop human-centred scenarios (eg driver sees alert but ignores it; system fails to warn due to loss of train detection). Identify workload, attention, error likelihood, and decision-making implications. Include human error identification and identification of performance shaping factors. Create comprehensive scenario sets covering normal operations, degraded conditions, and emergency situations, including how users may recover from errors. Include consideration of how failures may cascade.
3. Stakeholder engagement. Conduct interviews or workshops with end users to validate system use cases and identify latent usability or operational concerns. Ensure accessibility for all demographics (eg elderly drivers, hearing-impaired users). Include change management considerations by assessing organisational and behavioural change requirements, identifying potential resistance factors and mitigation strategies, and planning further stakeholder engagement approaches to support implementation. Consider implementation requirements (eg awareness campaigns, culture change requirements) and timeline implications.
4. Integration with standards and regulations. Ensure operational concepts broadly align with relevant Human Factors standards, including mapping to applicable standards (ISO 9241, AS standards), verifying accessibility compliance requirements (WCAG, DDA), and considering safety management system integration and certification pathways. Support risk assessments and SFAIRP evaluations.

System requirements definition  

Description

Requirements define the functions, performance, and operating environment of the proposed technology. They determine what the system must do (eg detect obstructions, provide warnings/alerts, interface with train control systems) and serve as the basis for verifying whether the system meets its intended purpose. The requirements identification process identifies the activities necessary to produce a complete, traceable, and verifiable set of requirements at both the system and sub-system levels. There are different ways to categorise requirements, some classifications discuss Functional Requirements (eg the system must detect the presence of an approaching train and issue warnings to drivers) and Performance Requirements (eg the warning must be delivered within X seconds of train detection, with Y% accuracy); and Environmental/Non-Functional Requirements (eg the system must function reliably under temperature extremes, dust, vibration, and variable visibility conditions).
Additional enabling requirements (eg maintenance protocols, deployment logistics, training needs) may be included in requirements documents or referenced in the project plan.

Key activities

1. Develop requirements. Translate the concept of operations into functional and performance requirements. Ensure that requirements address regulatory, safety, and operational constraints.
2. Write and document requirements. Ensure that requirements are composed in a way that are clear and concise, testable, and are independent from implementation (avoid specifying “how to” achieve the requirement; unless necessary). For example, “The system shall provide a visual alert to the driver within 3 seconds of train detection.”
3. Check completeness of requirements. Confirm coverage across all stakeholder needs and consider relevant crossing types (active, passive), user groups (road users, rail operators), and operating environments.
4. Analyse, refine, and decompose. If required, decompose system-level requirements into component-level requirements (eg requirements relating to various sub-systems such as trackside sensors, human-machine interfaces).
5. Validate requirements. Confirm with stakeholders that each requirement maps to a legitimate operational need.
6. Manage requirements. Ensure systems are in place to manage requirements, that requirements are placed under change control once approved and the project is monitored for scope creep, especially in safety-critical or cost-sensitive areas.

Human Factors contributions to system requirements definition

Human Factors specialists ensure that system requirements comprehensively address user needs, capabilities, and limitations across all operational scenarios. By translating insights from earlier analysis phases into specific, measurable requirements, Human Factors contributes to creating systems that are not only technically sound but also safe, usable, and accessible to all intended users.

1. Human Factors requirements development. Translate findings from EHFA and Concept of Operations into specific, testable system requirements focused on human-system interaction. Define usability requirements (eg "Warning signals shall be perceivable by drivers under all lighting conditions including direct sunlight glare") and establish accessibility requirements to ensure system usability across diverse user populations (eg elderly drivers, hearing-impaired users). Requirements relating to human error prevention and recovery should also be considered.
2. Human Factors requirements refinement. Work within interdisciplinary teams (including technical/engineering specialists) and with other stakeholders to ensure each requirement is:
   • Clearly worded
   • Measurable and testable through defined validation methods
   • Independent of implementation (focused on "what" rather than "how")
   • Decomposed, as required, into component-level Human Factors requirements
3. Ensure compliance. Check that Human Factors requirements align with regulatory requirements, any mandatory standards for safety and human-system interaction and address how safety will be maintained under system degradation or failure conditions (eg when warnings/alerts fail).
4. Stakeholder engagement and validation. Facilitate stakeholder validation sessions to confirm requirements accurately reflect real-world user needs and review documented requirements to ensure they address the full spectrum of user groups and operational environments identified in earlier project phases.

Project planning

Description

This stage brings together general project planning and technical management to provide a clear, unified foundation for the project. It translates high-level goals such as improving safety through low-cost innovation into defined tasks and processes. It also outlines how technical activities will be managed and documented. This stage helps to align stakeholder expectations, identify constraints (such as site access or regulatory approvals), and ensure that both operational and technical aspects of the project are properly considered from the outset so that appropriate resources are allocated.

A key output is a Project Plan outlining tasks, schedules, resources, responsibilities, risks, and governance. Other outputs may include a simplified Technical Management Plan or embedded technical planning section, which may include system diagrams, trial protocols, or safety assurance steps, and supporting documents tailored to the size and complexity of the project (eg Risk Management Plan, Evaluation Plan, or Safety Case elements, if required).

Key activities

1. Define and budget project tasks. Break down the overall project into manageable and budgeted work packages. These may include site selection and stakeholder approvals (eg road managers, operators, councils), design tailoring or system adaptation for the specific level crossing environment, logistics for hardware installation and field testing, Human Factors evaluation, safety, security, or compliance checks and project wrap-up and dissemination of findings.
2. Identify and allocate resources. Determine what is required to carry out the project, including: personnel (e.g., project lead, Human Factors support, technical support), materials and equipment (eg warning devices, power systems, signage, communications hardware), and facilities (eg test sites, simulation environments, data storage or analysis platforms).
3. Plan procurement and technical responsibilities. Determine which components (eg warning devices, signage, software) are sourced externally, and consider whether technical or evaluation work is done in-house or via partners.
4. Develop project schedule. Develop a timeline based on funding and resource availability, access to level crossings, weather, operational or maintenance windows, and coordination with other projects or broader rail operations.
5. Define technical activities and risks. Plan and document key technical steps to ensure the system performs as intended and meets relevant expectations. These steps might include: tailoring hardware or software to suit specific crossing configurations, integrating the system with existing infrastructure (eg signage, solar panels, communications), developing and validating interfaces (eg between vehicle systems and infrastructure), planning data collection and performance evaluation methods, and identifying technical risks such as poor visibility, unreliable power, or false triggers—and developing risk mitigation plans.
6. Prepare project plan. Document how each task will be delivered, who is responsible, what outputs are expected, and what contingency measures are in place for delays, technical failures, or regulatory issues. Keep the plan proportional to the project's size and complexity.
7. Develop supporting plans (if required). These may include a simplified Risk Management Plan, Safety Assurance or Security Plan (if technology introduces risk), and Integration and evaluation plans.

Human Factors contributions to project planning

Human Factors activities and resourcing needs to be considered to ensure appropriate integration. Activities here involve planning for HFI activities, allocating Human Factors resources, and documenting Human Factors activities in project and technical plans.

1. Update EHFA. Update and refine the EHFA to align with the specific project scope and technical approach.
2. Create Human Factors Integration Plan (HFIP) The HFIP is a systematic plan for Human Factors activities to support HFI. It usually encompasses: the project background, context of operations, scope of Human Factors effort as determined in the EHFA, constraints and dependencies of Human Factors work, activities to be undertaken throughout the project lifecycle (eg input to requirements specification, workshops, analyses, trials), roles and responsibilities, deliverables, reporting requirements and review processes (see RISSB Guideline – Integration of Human Factors in Engineering Design, for further detail). An important aspect will be consideration of how the technology will be evaluated, to ensure appropriate time and resources can be allocated (see Human Factors Guidance for Evaluating Innovative Level Crossing Technologies).
3. Create Human Factors Issues Register (HFIR). The HFIR provides a log to track the identified Human Factors issues across the project. It is a living document that provides traceability and the ability to determine the current status of a given issue. Issues are typically identified during EHFA, during Human Factors analysis activities, design reviews, risk assessments, and user testing / evaluation activities (see RISSB Guideline – Integration of Human Factors in Engineering Design, for further detail).
4. Human Factors input to Project Plan. Ensure that Human Factors activities and personnel requirements across the project lifecycle are documented in the overall Project Plan and accounted for in scheduling. Identify need for Human Factors involvement across the key project phases and estimate time and effort required to undertake HFI activities. Ensure Human Factors resources (in-house or external) are agreed and will be available.
5. Support technical risk assessment. Provide Human Factors input to risk assessments and contribute to risk mitigation strategies that address both technical and human performance elements. Integrate the outcomes of Human Factors analysis into relevant risk assessment models being used in the wider project (eg bowtie, fault-tree analyses). 

Next, Phase 1: Design