New Orleans, Louisiana
June 26, 2016
June 26, 2016
August 28, 2016
Software Engineering Constituent Committee
The undergraduate software engineering curriculum at <<university name elided>> used to have a course in Software Requirements Engineering, and a separate course in Software Architecture. As part of a curriculum re-design, we merged the requirements and architecture courses. This was a challenging process since some material from the two courses needed to be deleted. It was a valuable process in that it brought the two strongly-related courses together. Practitioners in industry do not treat requirements and architecture as isolated practices. Merging the two courses help students learn ways of separating, yet bridging, the gap between problem-space thinking (requirements) and solution-space thinking (design). This paper discusses the practical motivations to merge these two courses, the valuable and challenging decisions in merging them, and lessons learned after teaching the new course for three years.
One of the big opportunities in merging the requirements and architecture courses was to provide team projects and individual activities that spanned the requirements specification and architecture design activities of software development. For the project, student teams find an external "sponsor" of their project (so they experience software elicitation with external stakeholders). They perform three quick iterations focusing on requirements. Instructor feedback is provided between each iteration. The first iteration results in a Vision and Scope document, the second iteration results in a draft requirements specification, and the third iteration results in a validated software requirements specification. Use case modeling and associated object-oriented analysis modeling techniques are used to support requirement specification and validation.
Throughout the requirements elicitation and analysis, we emphasize the need for well-defined quality requirements. Although at this point in the course, the students are not yet in a position to design an architecture they are beginning to perform design thinking in the context of requirements.
As the student projects move into the architecture-focused iterations, the students are given reading and lecture material that introduce architecture patterns and tactics as ways to satisfy quality requirements. They develop two drafts of an architecture design, with instructor feedback between drafts. Students identify deficiencies in their requirements specifications and learn how to evaluate an architecture design. They are able to more easily distinguish and move between problem-space requirements thinking and solution-space design thinking.
Reading and lecture materials are given as-needed for the projects. Since we compressed two courses into one, some valuable course material was lost. We focused course content on what students need to execute the projects. We lost time for detailed study of requirements analysis and specification, for a thorough coverage of architecture patterns and styles (we focus on architecture tactics), and for covering advanced topics of architecture such as reverse engineering or product line architecture design. Overall, we believe we made the correct decision to integrate the two courses and to focus on integrated requirements and architecture projects. We are still looking for ways to gently work lost content back into the combined course.
ASEE holds the copyright on this document. It may be read by the public free of charge. Authors may archive their work on personal websites or in institutional repositories with the following citation: © 2016 American Society for Engineering Education. Other scholars may excerpt or quote from these materials with the same citation. When excerpting or quoting from Conference Proceedings, authors should, in addition to noting the ASEE copyright, list all the original authors and their institutions and name the host city of the conference. - Last updated April 1, 2015