Student Blogs
MS in Software Engineering, Technical Track Blog
 | Rahul is a full-time MS Software Engineering, Technical Track student. He loves traveling, trekking, swimming and is a complete movie buff. |
 | Anthony is a 2nd year part time student in the MS Software Engineering, Technical track program and works at OSIsoft as a Software Engineer. He loves spending time with his family, hiking, biking, gardening, cooking, and sometimes photography. |
 |
Suma is an alumna of the MS Software Engineering, Technical Track program. A Mechanical Engineering undergrad, she loves writing and is passionate about music, shopping and dogs. |
 |
Minh is a Software Design Engineer at Microsoft and alumnus of the MS Software Engineering program. He is also a Vietnamese community activist, a cat-lover and passionate fan of film music. |
 | Nick is a Software Engineer at Google and a first-year grad student at Carnegie Mellon Silicon Valley. He loves hiking, gaming, and both really extremely good and extremely bad movies. |
Friday, April 27, 2007
Requirements Engineering or “What do you mean, there’s more to life than coding?”
From reading my past blog entries, it should be clear to anyone that I was extremely excited to start my graduate studies at Carnegie Mellon West and how ecstatic I was going through my first semester with the Foundations of Software Engineering class.
Well, this blog entry focuses on how I got a hard dose of reality during my second semester with the Requirements Engineering class and why it was a bit more painful for me.
In Requirements Engineering, we dive very deep into the process of gathering, analyzing, validating, documenting and managing requirements for a new software product. Sounds easy, right? Sure it does. Was it simple? Not at all.
The specific project we were given was to drive the idea of a movie recommendation website based on social-networking from research and conception to complete specification. Our team was not tasked with actually implementing the website, but rather, producing a final, detailed software requirements specification document instead, that could then be handed over to other teams for implementation.
While this task itself does not sound very complicated, it turned out to be a very process-oriented activity that lasted—no surprise here—an entire semester. During the course of 16 weeks, here are some of the tasks our team performed.
- Wrote a team charter
- Analyzed our (fictitious) company's vision as well as high-level requirements document
- Interviewed our friends, relatives, and even strangers down at the local Blockbuster video store about their movie-selection process.
- Performed competitive analysis of sites like yelp.com and Netflix
- Conducted brainstorming sessions
- Analyzed and documented these requirements into lengthy Excel files and use-case documents
- Created user interface mockups via Photoshop or PowerPoint
- Implemented a web prototype after getting the sign-off from our VPs (professors)
- Conducted several rounds of usability tests
- Compiled and captured these vast findings into the software requirements specifications document
If you also add to this mix other deliverables such as the glossary, user scenarios, navigational sitemaps, project schedule plans, implementation estimations, risk assessments, and final presentation, you’ll quickly get the idea of why requirements engineering of a simple product took 16 weeks.
With the exception of coding a mock website for conducting usability tests, this entire class could be completed without writing a single line of code, and herein lies my dilemma. You see, I am a coder. I am a technical person that enjoys architecting, designing and actually coding a software product, and the lack of these kinds of activities is what led to why I was less excited about this class than my previous class. To be pulled out of my comfort zone and tasked with learning the process, I grew tremendously, even though at times I was getting itchy wanting to just code. With that said, I know that not everyone shares my passion for coding, and for those who aspire to be program managers, this class is absolutely necessary.
Was the class useful? Yes. Was it enjoyable? Not all the time. Was it necessary? Absolutely. Did I benefit from the class? Definitely. I now have a great understanding of how requirements work, how to craft them well, and how to be successful in delivering them. It’s no surprise that in the industry, the majority of software projects fail because the requirements are wrong. This class was instrumental in teaching me the correct way to gather requirements – something I never had to think about before, since I’m used to just getting the requirements handed to me.
Next: The Gathering
posted by Carnegie Mellon Silicon Valley @ 3:50 PM
I'm learning to Pick the brains of the most successful work from home affiliate marketers blogs and follow their proven formulas for success and I just bookmarked yours. "Listen How John Doe made $3,554 in 24 hours promoting one product" EDC Gold Profits