Analysis

Abstract

The primary mission of an analyst or systems designer is to extract the user’s physical requirements and convert them to software. All software can trace its roots to a physical act or a physical requirement. A physical act can be defined as something that occurs in the interaction of people; that is, people create the root requirements of most systems, especially those in business. For example, when Mary tells us that she receives invoices from vendors and pays them 30 days later, she is explaining her physical activities during the process of receiving and paying invoices. When the analyst creates a technical specification that represents Mary’s physical requirements, the specification is designed to allow for the translation of her physical needs into an automated environment. We know that software must operate within the confines of a computer, and such systems must function on the basis of logic. The logical solution does not always treat the process using the same procedures employed in the physical world. In other words, the software system implemented to provide the functions that Mary does physically will probably work differently and more efficiently than Mary herself. Software, therefore, can be thought of as a logical equivalent of the physical world. This abstraction, which I call the concept of the logical equivalent (LE), is a process that analysts must use to create effective requirements of a system’s needs. The LE can be compared to a schematic of a plan or a diagram of how a technical device works.