Paper Authors

Abstract

NOTE: The first page of text has been automatically extracted and included below in lieu of an abstract

Gathering Project Requirements: A Collaborative and Interdisciplinary Experience.

Deepti Suri, John Gassert Department of Electrical Engineering and Computer Science Milwaukee School of Engineering 1025 North Broadway Milwaukee, WI 53202-3109 {suri, gassert}@msoe.edu

Abstract Milwaukee School of Engineering has one of the first ABET-accredited undergraduate software engineering (SE) programs in the United States. As part of the curriculum, SE students are exposed to Requirements Engineering (RE) in their junior year. These concepts are reinforced through a quarter-long project in which the SE student teams work with clients who have product domain knowledge but often no formal experience in RE. Working in unfamiliar domains, being cognizant of ethical issues, and having to deal with ambiguous and conflicting customer requirements are some of the challenges that students face in a course like this.

The authors have been working on a collaborative experiment where the clients for the junior SE student teams are biomedical engineering (BE) student design teams. This allows interdisciplinary collaboration, exposes the SE students to eliciting requirements in an unfamiliar domain, and exposes the BE students to a formal requirements process. The authors discuss how this collaboration has evolved and what they learned from it. The challenges encountered while using this approach are also discussed.

1. Introduction The two major (and unfortunately fairly common) roadblocks that projects both in the industry and academia alike face are (i) A significant amount of time and effort is spent on rework because the delivered product does not meet the user’s needs and (ii) The project takes longer (and is over budget) because the functionality that needs to be delivered is not properly understood and estimated.

The chances of a product being developed on time and within budget are dependant on thorough and precise analysis of the client's current situation and needs. Informally, the client’s needs are also called “requirements”. A “requirement” is a specification of what should be implemented by a product. The IEEE standard defines a requirement as “a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component” [2] [3]. Requirements are primarily of two types: functional and non-functional. Functional requirements relate to the actions that the product must carry out in order to satisfy the fundamental reasons of its existence. Non-functional requirements are the desirable properties/qualities that the product must have [4] [7]. These are the characteristics that make the product fast, usable, portable, reliable, attractive, etc.

Proceedings of the 2005 American Society for Engineering Education Annual Conference & Exposition Copyright © 2005, American Society for Engineering Education

• Citation

• Format
  • APA
  • APA - LaTeX bibitem
  • MLA
  • MLA - LaTeX bibitem
  • Bibtex
  • EndNote - RIS

Gassert, J., & Suri, D. (2005, June), Gathering Project Requirements: A Collaborative And Interdisciplinary Experience Paper presented at 2005 Annual Conference, Portland, Oregon. 10.18260/1-2--15570