By Topic

Designers must do the modeling

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
Lawrence B ; Coyote Valley Software Consulting, USA

Put simply, those who construct the system, the designers, should own the requirements. To understand why, let's step back and examine what requirements really are. If we think of the requirements process as a black box, there are inputs to the process, things happening inside the black box, and outputs from the process. Inputs to the process include discussions with customers, past products, competitors' solutions, prototypes, and new ideas. Many authors have claimed that the primary output of a requirements process is a requirements specification. Not so. The primary output is our collective understanding of the customer's problem. The specification is only a representation, a model of that understanding. Although important, it is still a secondary product of the requirements process. One can think of requirements as “anything that drives design choices”. Based on that definition, a system's requirements are the collection of the reasons why we choose to design it as we do. Design choices are made not on paper, but inside the minds of designers. The choices are documented on paper. There are many other outputs of the requirements process, such as dataflow diagrams, object models, state models, event models, entity relationship models, natural language statements, and so on. The main benefit of producing all these artifacts is a better and agreed upon understanding of the problem, so that we can design more effective solutions for it

Published in:

Software, IEEE  (Volume:15 ,  Issue: 2 )