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
1 comments
Class Schedule and Long-Distance Learning
It’s always hard to explain to my friends what Carnegie Mellon West is and what it is not. Whenever my friends and co-workers ask simple questions such as “How many classes are you taking this semester?” or “When are your classes?,” I always take a deep breath and mentally prepare myself to go through the same routine of providing answers that only bring forth further questions.
Well, how DO I answer those types of questions?
A) “I don’t have any classes”
B) “I only have one class per semester”
C) “My teammates, faculty and I make up our own class schedule”
D) “My class meets Sunday night at 11pm”
E) “Yes, I understand this is New York City, but I still have class later this afternoon”
“I don’t have any classes.”
It’s true. If you are thinking of classes as “regularly-scheduled sessions on campus that I need to attend every week only to powernap through them,” then no, I don’t have any classes. As mentioned before in my blog, the majority of my weekly schedule consists of working either individually or in a team to produce deliverables—whether it is a source code, documents or presentations. How do I learn then? Well, just like in real-life, I am expected to learn the materials through whatever media work best for me. Carnegie Mellon West provides a number of resources for the students - certainly the number one resource comes in the form of our professors, who will guide discussions, or lead teams toward finding their own answer. In many cases, the resource can be the assigned reading in books, or individual web research. The last resource is your classmates – the fact that you are teamed up with people with varying professional experiences means that you have a lot to learn from each other. The bottom line is that you should understand the material to deliver the products. How you learn that material is entirely up to you.
However, we do have optional “bootcamps” every month or so. These are 1-2 hour classroom-style sessions where either a faculty member or an outside industry expert is invited on campus to delve into particular topic in much further detail. Examples of past sessions are Hibernate, JUnit, UML, CMMI, and even technical writing.
“I only have one class per semester.”
It’s true. If you are thinking of the schedule of classes that appear on my grade report, I only have a single 12-unit class per semester. Last semester was “Foundations of Software Engineering;” this semester, it’s “Requirements Engineering.” While we split up the 16-week class into two 8-week classes, it really is only one class.
“My teammates, faculty and I make up our own class schedule.”
It’s true. We make up our own schedule. Since a team typically consists of 4-6 students who work full-time, and faculty members who meet independently with all their students, in addition to conducting their own research, scheduling meeting times is left entirely to us. At the beginning of each semester, the team negotiates a weekly meeting time between ourselves and the professors teaching the course (typically we will have to schedule with 2-3 different faculty members, who play the roles of team advisor, VP of Engineering, and optionally the VP of Marketing. Some teams meet once each weekend and do the rest through online collaboration, other teams meet four times a week in the evenings to leave the weekend open; the majority do a combination of both. It really depends on the team dynamics, preferences, and the current week’s work-load.
“My class meets Sunday night at 11P.M.”
It’s true. Given that the school provides us with a Microsoft LiveMeeting for each team, we often find ourselves using this tool to collaborate online at the oddest hours. Last semester, one of my team members was “on vacation” in India and called in during his wee early hours and our late evenings.
“Yes, I understand this is New York City, but I still have class later this afternoon.”
Since our cohort consists of 30% remote students, the classes are designed for long-distance learning. While I very much prefer to meet on campus to fully appreciate the advantages of in-person meetings, I appreciate the flexibility to be out of town and not missing meetings. Whether I find myself on business trips to Seattle, personal trips to New York, or family-visits to Orange County, I can still participate in meetings through the use of conference call bridges and LiveMeeting. All you really need is an internet connection and a fully-charged cell phone. One time, I was on a cell phone for four hours at a McDonald’s in Brooklyn. While it was certainly not a pleasurable experience, I valued the fact that, as Thomas Friedman would say, “the world is flat.”
As you can see, some simple questions require complicated answers. Hopefully, some of my co-workers and friends would have read this blog entry the next time they ask me questions about my classes, to save me from a long-winded explanation.
Next time: Requirements Engineering or "What do you mean, there's more to life than coding?"
posted by Carnegie Mellon Silicon Valley @ 4:52 PM
3 comments
