Opus Website

UCLA's HR System

Business System Analysis

Opus is UCLA's new web-based HR system for faculty. The system replaces the previous paper process for performance reviews of academic employees. It also contains fielded faculty resume information and enables campus-wide reporting.

Opus is a technical system that automates complex business processes in a large-scale organization. The development issues that arise as a result of this complexity are analysed in a publication that I co-authored,
entitled "Who owns faculty data? Fairness and transparency in UCLA's new academic HR system."

The lean development team uses a blended agile and waterfall development approach. As a Senior Business Systems Analyst, I wear many hats with tasks including requirements elicitation, wireframing, creating functional and technical documentation, reporting design, coding a resume parser for a structured resume template, data model recommendations, and extensive data mapping.

Click below to see work samples.


+ Wireframes

Wireframes

To ensure a positive user experience, I engaged in open houses and user experience testing meetings with our user-base. Before a full-time User Experience Designer was hired, I developed Opus' wireframes using Balsamiq, with a mindset of the user's functional goals and usability best practices.

This wireframe below is for administrators who are assembling review committees and need to find reviewers based on area, expertise and rank, excluding those who are on leave and those with recent review committee service. This page appears when the user clicks advanced search options (next to the Search box) from the main committee assembly page.

Sample Wireframe

Display Action Response Tables

A Display Action Response (DAR) Table is documentation used by developers to understand which parts of a webpage should behave in specific ways. More digestible than a long list of requirements, this visual version of requirements gives the authoring Business Analysts a systematic way to ensure requirements are captured.

I am certified in Seilevel "Visual Models", "Requirements Core Concepts" and "Elicitation Facilitation."

When users click here or there, what should happen? Examine the DAR table below to find out. This DAR Table explains the "Search For Review Committee (RC) Members by the Council on Academic Personnel (CAP) Case Specialist" page. The Advanced Search page wireframed above is the Advanced Search version of this simple search page.

Sample Wireframe

+ Technical Diagrams

State Transition Diagram

By and large, the Academic History page requires the user to explicitly press Save to save any edits they have made to data. Exceptions are the cases of Delete and Verify, which if successful also cause a Save. Unsuccessful Saves, Deletes, and Verifications, as well as such triggers as session timeouts -- leave data in an unsaved state. These and a few other scenarios in which data would or would not be saved are detailed in the visual below.

Data State Transition Diagram

Data Flow Diagram

Opus pulls in data from many campus systems to avoid duplicate data entry. So, when faculty need to make data corrections, the error resolution requests are routed to the original source system, improving data quality for the campus, not just for Opus. This visual model represents the "Book of Record" Data Flow.

Data Flow Diagram
PDF of Data Flow Diagram

User Flows

This flow shows the actions available to the user, and at some level, what functionality needs to happen behind the scenes to facilitate the wanted system/UI behavior from the perspective of the user. This variant of a traditional user flow adds some technical detail in order to begin our team discussions about technical requirements. This snapshot in time of the flow shows some items in red - these items are questions to be asked or confirmed with the team.

Data Flow Diagram

Data Flow Diagram

+ Traceability Matrix

Traceability Matrix

The following traceability matrix began as a business requirements document started by a teammate. I then added the "behavior" columns in order to clarify which workstream is responsible for executing each business requirement. The behavior columns act both as technical requirements and, also, they (in combination with the business requirements themselves) turned into test cases. This detailed format for technical requirements facilitates creation of development tasks for the upcoming development cycle, yielding more accurate time estimations.

Data Flow Diagram

PDF of Traceability Matrix (sample page)

+ Data Architecture

ETL Specification Template

I created an ETL (Extract, Transform and Load) Specification template in conjunction with the database architect and ETL developers.

Opus ETL Specification Preview











ETL Specification Template Excel file


Database Design

I assist the principal database modeler in designing the logical and physical database models for our project. This includes discussing design option tradeoffs and general validation based on knowledge of the business and data integration needs.

The model was created in Erwin, which I use at a novice-level. I also assisted with deployment and troubleshooting of the physical database in our four environments.

PDF of Logical Model for Release 1.1 Database



Data Integration

For Opus first beta release, I manually executed the ETL from source systems into Opus. For later releases, I provided ETL Specification documents to the then-hired ETL developer for dozens of source systems.

The ETL Specification information was compiled by conducting meetings with business and technical system owners, analysing technical documentation (data models, data dictionaries, data samples), directly accessing data in the source systems, and in some cases, synthesizing reports from consultants or team mates who met with owners and technicians of source systems.

Though the graphics below were created by other team members, they provide a sense of the scale of data integration work undertaken by the Opus project. The first two images, of Internal and External data sources, represent the number of integrations planned as of 2013. The third image represents the set of system integrations planned as of mid-2014. As of early 2015, 40+ integrations are planned.

Early Draft of Internal Data Sources

Early Draft of External Data Sources















Phase 1 (Later) Draft of Data Sources