Abstract Clarifying and defining client expectations is one of the most difficult and important parts of the requirements definition process. Finding out and then prioritizing functional and nonfunctional requirements remains ambiguous and error prone. This article presents an approach that is complementary to existing ones: relationship clarification and definition. A client purchasing a system is actually purchasing three things: 1. (1) the system, 2. (2) a specific business relationship with the provider, 3. (3) specific working relationships between the system and members of the organization. Many of the difficulties in requirements definition stem from the fact that many of the client's desires, needs, and expectations can only be expressed in terms of these relationships; developing a clear, precise specification of these relationships is a necessary step of the requirements definition process. In addition, we show how software relationships can help anticiapate future requests for changes and enhancements. We discuss the concepts of relationships, relationship change, and the connection between relationships and behavior (human and system), and present a step-by-step procedure for producing a clear relationship definition statement.
[1]
Gerald M. Weinberg,et al.
Exploring Requirements: Quality Before Design
,
1989
.
[2]
Edward Yourdon.
Decline and Fall of the American Programmer
,
1992
.
[3]
Tom Gilb,et al.
Principles of software engineering management
,
1988
.
[4]
Rick Napier.
Information engineering & application development using knowledgeware's CASE tool set
,
1991
.
[5]
Mary McDermott Shideler,et al.
Persons, Behavior, and the World: The Descriptive Psychology Approach
,
1988
.
[6]
Edward Yourdon,et al.
Structured walkthroughs
,
1978
.
[7]
H. Joel Jeffrey.
Human systems analysis in the software engineering curriculum
,
1991,
J. Syst. Softw..