My name is Eric, and I am a Requirements Analyst. Before November, the acronym “RA” held only connotations of dorm hall meetings and stale pizza, as I have only recently shed my student skin and joined employed society. I graduated from the University of Texas with a Bachelors in Communication Studies and a minor in Business. I entered this industry a tabula rasa, hired with an acceptance of the absence of any technical training on my resume and the expectation that I would learn and adapt quickly enough in an industry with no room for intellectual light-weights. This post is the first in what will be a running series on my nascent professional development.

My interest in requirements was first piqued due to searching for a professional fusion of business and technology. I began my job search with all the bravado and naiveté one would expect from a recent graduate. I was unable to get excited about entry level business jobs that didn’t allow for pursuit of technical knowledge, yet shied away from techie training programs that left my business skill set underdeveloped. I saw working as an RA to be the right balance of business and technology to satisfy my competing interests. In addition to this, a primary tool in the RA toolbox is the ability to learn – to learn rapidly, thoroughly, and constantly. In other words, the same drive to acquire knowledge necessary for academic success is also a main ingredient for success as a Requirements Analyst.

I found this exciting, as I had done well as a student and escaped academia with my curiosity still intact. Replace paying tuition with receiving a paycheck, and the deal became almost suspiciously sweet. Certainly my learning on company dime would be focused on bodies of knowledge that advanced my projects or sharpened other industry-relevant skills, but this reveals another appealing difference between the world of a full-time student and the world of an RA. The metrics for success are no longer the clunky, abstract, and sometimes arbitrary letter grading system, but the more tangible barometers of project success (or failure) and customer (dis)satisfaction.

Upon arriving on my first day, I received a small mountain of literature, its components chosen to beef up my familiarity with four broad areas of knowledge. If they were freshmen level courses, they would have titles along the lines of:

1) Requirements 101
2) Essentials of Software Development
3) A seminar entitled “So You Want to be a Consultant”
4) A more project-specific elective, in my case “Computer Science for the Ambitious Amateur.”

The elective may seem generic and obvious, but given a different project or an RA with a different background, it could have easily been “Basics of Finance” or “UML for Dummies.” Required reading for the semester would include Software Requirements 2nd Edition by Karl Wiegers and Rapid Development by Steve McConnell.

I’ve now been on the job about two months, and consider myself to be in an enviable position. I enjoy what I do, and I’m steadily chipping away at my “New Guy” mentality and coming to see myself as an integrated part of the team. I hold no illusions about my rookie-hood, and “I have a lot to learn” is quite the understatement. However, we all have to start somewhere, and I am happy to be starting where I am. Tune in next time for Part 2!