Browse Prior Art Database

SPECIAL FEATURE: Requirements Analysis in Clinical Research Information Processing A Case Study

IP.com Disclosure Number: IPCOM000131450D
Original Publication Date: 1979-Sep-01
Included in the Prior Art Database: 2005-Nov-11
Document File: 14 page(s) / 54K

Publishing Venue

Software Patent Institute

Related People

Gabriel F. Groner: AUTHOR [+6]

Abstract

This article describes a requirements analysis effort during which we first characterized information processing activities and needs common to many medical researchers, and then developed, tested, and evaluated prototype systems. Prototypes were re"; quired in the requirements analysis phase because without concrete, working examples our potential users could not be sure that computer systems are needed, what functions they should perform, or how they would use them. We have not developed a general framework in which to determine and satisfy the diverse information processing needs of a community that is largely skeptical about the utility of computers, nor have we tested our approach in other application areas. However, because we believe that some aspects of our approach are applicable to other areas and that case studies have tutorial value, we present this case study with the hope that others can benefit from our experience.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 7% of the total text.

Page 1 of 14

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

This record contains textual material that is copyright ©; 1979 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Contact the IEEE Computer Society http://www.computer.org/ (714-821-8380) for copies of the complete work that was the source of this textual material and for all use beyond that as a record from the SPI Database.

SPECIAL FEATURE: Requirements Analysis in Clinical Research Information Processing A Case Study

Gabriel F. Groner ,* Marsha D. Hopwood , Norman A. Palley ,** and William L. Sibley The Rand Corporation

(Image Omitted: System designers often neglect to do a thorough requirements analysis before beginning development. This effort shows how such an analysis can improve the usefulness of a new system.)

Computer systems development often suffers from inadequate requirements analysis. Design and implementation generally begin before the designers and their customers reach a sufficient understanding of needs and functional requirements. Our professional literature suffers from a paucity of papers describing requirements analysis methodologies and case studies. Ross and Schoman' assert that the results are overrun schedules and budgets, disgruntled users, and expensive, long-term maintenance. They propose a process and an analytic method for arriving at a formal requirements definition which provides boundary conditions for the subsequent design and implementation stages. The resultant requirements definition states why a system is needed, what functions the system must accomplish, and how the system is to be constructed. Similarly, Boehm2 points out that many software projects fail because they rush into design and coding without a thorough understanding of the system's requirements. His data and experience show that each unit of effort in analysis and design saves 1.5 to 3 units of effort in coding, testing, and integration. Boehm has successfully used requirements/properties matrices and design specifications lists to stimulate and formalize requirements analyses. To determine requirements he suggests asking the potential users what they would do under various circumstances instead of asking them what they need or whether they would use particular functions.

1

2

This article describes a requirements analysis effort during which we first characterized information processing activities and needs common to many medical researchers, and then developed, tested, and evaluated prototype systems. Prototypes were re" quired in the requirements analysis phase because without concrete, working examples our potential users could not be sure that computer systems are needed, what functions they should perform, or how they would use them. We have not developed a general framework in which to determine and satisfy the diverse information processing needs of a community that is largely skeptical about the utility of computers, nor ha...