- How to Identify the Scope and Boundary of a Count
- How to Count ILFs and EIFs
- Some Typical Errors in Identifying ILFs and EIFs
- How to Count EIs
- How to Count Transactions
- Some Typical Errors in Identifying EIs
- How to Count EQs
- Some Typical Errors in Identifying EQs
- How to Count EOs
- Some Typical Errors in Identifying EOs
An external input (EI) consists of an elementary process that is the smallest unit of activity that is meaningful to the end user in the business. This elementary process must be self-contained and must leave the business of the application being counted in a consistent state. For example, an input form for mortgage coverage could consist of three screens; if the form were incomplete until all three screens were completed, the elementary process would require the completion of all three screens.
We would not question this decision if the form were to be completed manually; we would just hand it back to the individual and request that the entire form be completed. Completing some of the fields, even those on one screen, would neither be self-contained nor leave the business in a consistent state. If all information were completed, recognizing that some of the fields may not be mandatory and could be left blank, this transaction would be complete, and the business would be left in a consistent state. In a Windows environment, we can save data at any time, but we don't count each save as a separate EI; we count only the completed transaction that is saved.
How can the behavior of a system be altered by an EI? Can you provide an example?
When reading sensor data, we turn on the heater, change a light from green to red, or fire a missile. This is what we previously called a control EI. Within Windows, zoom and minimize are examples.