Requirements Engineering Exercise

I’m currently teaching two 2-hour labs each week for an undergraduate software engineering course.  The first few weeks of the course have been about design methodology and requirements engineering.  In this post I’ll describe last week’s lab on requirements gathering which was met with rave reviews from the students!

The goal: Provide students with experience gathering requirements for a software project.

Context: Each lab section consisted of approximately 15 first year software engineering students.

Premise: Have the students solicit requirements from two different people in a software company: the CEO and a project manager.  This gives them an opportunity to practice facilitating meetings with different levels of management, and get a feel for the different types of requirements that come from different stakeholders.

Preparation: As the instructor, you need to create a list of requirements for all of the people that are to be interviewed (in this case, a set for the CEO, and a set for the project manager).  These requirements should be different to emphasize the differences in the types of requirements that various stakeholders will provide.  The more time you take to prepare these lists, the better understanding you’ll have of the software you want to create is, and the more the students will benefit from the exercise.  Make the requirements as realistic as possible, and go in with a definitive plan.

Process: The students were divided into two groups (7, and 8 people).  Both groups were given an overview of an imaginary high-tech company, Gadgetron, that sells gadgets in stores across North America.  The overview included the following information:

• company size (in number of employees and revenue)
• current company locations (cities with stores)
• demographics of current clientele (sex, age)
• overview of the number of products sold, best selling items, etc.
• the desire to expand to international markets was emphasized
• the desire to create a web presence to expand their reach

Following the overview, Group 1 went into the hall to come up with a team name, and prepare for an interview with the CEO of Gadgetron.  Group 2 stayed in the classroom and had 5 minutes to prepare for their interview with the CEO.  After preparation, I acted as the CEO of Gadgetron, expressing my vision and giving high-level requirements reflecting my desires from a management perspective.  These requirements were more focused on timelines, monetary resources, high-level technical requirements, marketing desires, etc.  The students needed to realize that what I wanted was not in line with the time/money resources I’d allocated, and make sure that they identified this, and keep the requirements within a reasonable scope (ie/ don’t make the iPhone/Blackberry apps up front, focus on creating a website).

After Group 2 interviewed the CEO, they went into the hall to prepare for their interview with the project manager and Group 1 came in and interviewed the CEO.  The project manager is the subject level expert, and had far more concrete details on what was to be developed: the scope of the website, what was to be shown on the interface and where, the differences between the registered users and guests, the desire to see reports (and what to show to different levels of management), the .  A lot of “nice-to-have’s” were introduced, and the students were required to determine what were the absolute requirements, and which requirements could be finished after the initial site was created.

Finally, Group 2 came back in and had their interview with the project manager while Group 1 went into the hall and discussed what they learned.  After all the interviews were finished, both groups came back in and gave feedback on what they learned.  They all were very excited to have completed this activity, and realized that requirements gathering is not as trivial as they had originally thought.  It also provided me with an opportunity to give them feedback on things that they did very well (such asking follow-up questions to things that I said, showing that they were actively listening and engaging their client), and suggestions on how to avoid some pitfalls that they encountered (i.e. asking the wrong questions to the wrong people).  All in all, this was a very successful exercise that promoted collaboration, individual thought, and integrated learning strategies.