Asee peer logo

Gathering Project Requirements: A Collaborative And Interdisciplinary Experience

Download Paper |

Conference

2005 Annual Conference

Location

Portland, Oregon

Publication Date

June 12, 2005

Start Date

June 12, 2005

End Date

June 15, 2005

ISSN

2153-5965

Conference Session

Education Ideas in Software Engineering

Page Count

6

Page Numbers

10.657.1 - 10.657.6

Permanent URL

https://peer.asee.org/15570

Download Count

26

Request a correction

Paper Authors

author page

John Gassert

author page

Deepti Suri

Download Paper |

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

Gassert, J., & Suri, D. (2005, June), Gathering Project Requirements: A Collaborative And Interdisciplinary Experience Paper presented at 2005 Annual Conference, Portland, Oregon. https://peer.asee.org/15570

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: © 2005 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