College Curriculum for Requirements Analysts

ArgonDigital - enterprise automation experts

Share This Post

On Day 3 of RE’06, I attended a practice talk called “Requirements Engineering: An Industrial Perspective”. Brian Berenbach spoke to the success of engineering projects in the early 1900’s as compared to now. He spent much of the talk focused on the reason the projects are not as successful anymore, suggesting it is related to the resources we are hiring to do requirements.

The overall argument from Brian was that people graduating from school today are not well trained in engineering. His contention was that the first programmers were engineers and scientists by training. As children, those engineers played with model trains, boats, and electromechanical systems. Today’s children are not playing with such things to influence their mindset, driving them to study complex engineering.

Then he tore apart a current day Computer Science curriculum. He argued that Computer Scientists are not trained to build complex systems because the curriculum is obsolete. The course outline he used as demonstration reflected that CS grads do not take compiler and database classes now.

Finally, he referenced some thoughts by Phil Greenspun, to say that when students come out of these programs, they are not good at turning vague goals into concrete specs, lack experience with UI and testing, and are not dedicated to completing something of value. I just finished reading through the work Phil put together.

And in reading Phil’s points, some of his issues are that graduates of CS programs have not done much open-ended project work, haven’t done much group work and don’t have experience to make sense of large commercial tools and libraries.

I have to admit, I disagreed with many of Brian and Phil’s points. Now it is possible that this talk caused a reaction in me because I have a Computer Scientist background, and I just got defensive. But in truth, I do feel like my education was very valuable to what I do today in requirements.

Phil actually starts his argument with the point that US employers are shipping jobs overseas because they are dissatisfied with the US educated IT workforce. I immediately was skeptical given this premise. In my experience, the primary reason employers are moving to offshore resources is simply to save money, and it is barely (if at all) related to having better resources offshore.

Looking at the CS course curriculum, I was truly surprised by their points. The curriculum Brian showed during the talk was from a school I was not familiar with. I studied Computer Science at Purdue, where the curriculum did include compilers and databases, as well as a project to build an end-to-end compiler. I’m also skeptical that schools really aren’t teaching this way now! We did projects in teams throughout my time there, and my understanding is that such group work is becoming an even greater part of college courses. In addition, we were assigned open ended projects, such as one to work in a team, to design and build a cryptography-related application and to be able to explain the value of the application. Now, possibly these are only present in elective courses that not all students have to take, but then it’s on the employers’ backs to look for graduates that did.

Sure, there are things that the students will not learn in school – perhaps around interviewing users, or using industry tools, etc. But frankly, we can teach these things very quickly to employees if they have the right talents. Can everyone facilitate requirements meetings coming out of school? I will argue there is no way anyone out of school could do this without first being trained by the company they work for.

I fundamentally believe in the value of hiring smart people with a capability to do analysis work. If they can do this, then we can teach them the skills to do the actual job by pairing them up with experienced employees. We have had great success with hiring a strong group of product managers from a diversity of backgrounds including biochemistry, economics, English and psychology education, mathematics and engineering. Obviously most of these people as students did not have experience in interviewing users, yet they are fully capable now because they had the strong problem-solving foundation on which to build the requirements skill set.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage