CLSS must be developed such that boxes moving along a conveyor line are identical and sorted into one of the six bins at the end of the line. The boxes will pass by a sorting station where they will be identified. Based on an identification number printed on the side of the box ( an equivalent bar code will be provided), the boxes will be shunted into the appropriate bins. Boxes pass in random and are evenly spaced.
For this example, CLSS is extended and makes use of a personal computer at the sorting station site. The PC executes all CLSS software , interacts with the barcode reader to read parts numbers on each box , interacts with the conveyor line monitoring equipment to acquire conveyor line speed , stores all part numbers sorted , interacts with a sorting station operator to produce a variety of reports and diagnostics, send control signals to the shunting hardware to sort the boxes, and communicates with a central factory automation mainframe. It can be shown in Figure 1:
Each box shown in Figure 1 represents an external entity –that is, a producer or consumer or consumer of information. E.g., the barcode reader produces information that is input to the CLSS system. The external entity bar code reader produces input information that is labeled bar code. A system flow diagram shows major subsystems and important lines of information (data and control) flow. At this stage, each of the subsystems can contain one or more elements (e.g. hardware, software, people) as allocated by the system engineer. It is schematically illustrated in figure 2:
Figure 2
Subsystems and the information that flows between them can be specified (bounded )
l for subsequent engineering work. From Figure 2,the emergent properties can be clearly seen that is,properties of the system as a whole rather than properties that can be derived from the properties of components of a system.
Software requirements
Requirements are the descriptions of services n constraints of the systems.
Functional and Non functional requirements
Also called domain requirements
Functional req: statements of services the system should provide, how the system should react to a particular input ant to particular situations. For eg:
Our system the conveyor belt must clearly state what it does.
Normally it carries a series of products (such as canned foods) rapidly from one process to another.
Non functional req: these are constraints on the services or functions offered by the system.
Here for our conveyor belt the constraints may be robustness (such as percentage of events causing failure), speed, ease of use( the system must be easily used by workers), reliability and portability (number of target systems)
Failure to meet a non functional system requirement may make the whole system unusable. Say for eg, if the conveyor belt does not meet the reliability requirement, how will the cans move from one process to another? Also the can are placed in an automatic order with equal distance between each one so as there is an orderly n systematic way from one process to another.
The IEEE 830 standard defines the benefits of a good SRS:
Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. [NOTE: We use it as the basis of our contract with our clients all the time].
Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customer’s organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct.
Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. [NOTE: Again, we use the SRS as the basis for our fixed price estimates]
Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. [NOTE: We use the SRS to create the Test Plan].
Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers.
Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation. [NOTE: This is often a major pitfall – when the SRS is not continually updated with changes]
