UX and Systems Engineering Requirements Process

Lately I've the opportunity/stressful task of learning how to incorporate user experience methods into a bigger systems engineering process. Most of the things that I learned early on in my HCI studies focused on web design. Then as I my work life demanded and my research capabilities grew, I learned more about application design. Now the needs before me are taking me into yet another new direction. As I know that some of you all are working in defense orother complex system oriented industries, I thought I would share what I'm learning so far. For now I'm going to focus on the requirements part of system engineering because that's where the cycle begins and where we as UX/HCI folks want to start working on a project. (Not as the people who have to pretty something up at the end!)

Systems engineering typically follows a "V" process. If you are familiar with waterfall type software development process (versus an iterative or AGILE process) then you will notice that the systems engineering process is designed to go with that process. If you are not familiar with a waterfall process then the takeaway is that these processes want you define all of your requirements up front before you work on other tasks. In small projects this strategy makes sense. If you have lots of time this strategy can make sense. If you are a huge project with tight deadlines and large disparate groups, this strategy is not the way to go.

We've discussed so far that traditional systems engineering and old school software development processes don't work for large projects that need to be done in a reasonable amount of time. Now let's look at a better approach. If you'll remember we've touched on user scenarios/user stories in one of the earlier lectures in this class. In that example we looked at small stories to capture user behavior. One approach that has been suggested is to use these types of scenarios to driving the engineering requirements process. In this type of process you create natural language user stories at the beginning and use those as a basis to perform your other types of analysis. The benefits of having this collection of user stories are many but the main two things they help with are organizing and analysis. On the organizing front it's really helpful for all of your teams to "get" what it is you are building and how it will be used for real. You can also use your stories to organize your traceability. On the analysis front it's useful to test your features against the stories to see if you are having feature creep or if you are missing functionality that your operators will need.

Here are a few resources that I've found helpful as I'm learning more about this topic:

1) Government/DoD System of Systems oriented: Scenario Driven Systems Engineering

2) Role oriented scenario approach: A Scenario-driven Role Engineering Process for

Functional RBAC Roles3) Operational threads (high-level capability is organized into threads and then you create user scenarios for each thread): Operational Thread Development