System - a collection of nearly independent components which interact for a common purpose.

Designers strive for the "nearly independent" part in the above definition as it helps in the diagnosis and repair of errors as well as understanding and design of a component (major subsystem).

These requirements should be functional in nature, i. e., they should describe what is required without implying how the system will meet the requirements. This provides maximum flexibility for the system designers.

When an analyst performs a functional decomposition of a system, the analyst

1. identifies the high-level components,

2. describes the function of each,

3. draws a high-level block diagram of the functional area,

4. describes the inputs to the system and outputs from the system (user displays, report

   formats, file formats),

5. describes the behavior of the interactions of the components (events and data

   exchanges),

6. and analyzes the possible states (system states and component states).

Usually, after identifying the high-level components and their functions, we draw a block diagram of the system (or subsystem, i. e., the functional area we are studying). This diagram defines the system boundaries. Any interaction with the system outside the boundaries is described in terms of inputs and outputs. Further, we describe any interactions between the components. Also, we describe the possible states and attempt to answer the below state-oriented questions. What is a state?

State - a situation which the analyst wishes to distinguish.

The level of detail in the situations depends on the purpose. For example, I might say that my desk lamp has two states: ON and OFF. In a functional decomposition, we usually want to include abnormal states. Therefore, with this purpose in mine, the states of my desk lamp could be either ON, OFF or BROKEN. Also, we would want more detail. Usually in a functional decomposition, we describe the possible states for each high-level component as well. Here is a list of key questions pertaining to states.

• Q1. What are the states? What are the modes of operations?

• Q2. Where are the states maintained?

• Q3. Who or what component can mess with the state?

• Q4. What are the events that caused a state change? What are the conditions on how to get into a particular state? Especially, an error state?

• Q5. What actions can be caused by a state change?

• Q6. What happens when something goes wrong? What error reporting and error handling is needed?

For illustration, I will write a functional requirement of a fluorescent desk lamp. Someone from on high has dictated that it must have a fluorescent tube. This is called a constraint.

The primary function of a fluorescent desk lamp is to provide light while working at a desk.

The high-level components for the lamp and their functions are the following:

1. Fluorescent bulb should provide enough light for a person to read and write up to three feet away.

2. The shade should shield the person's eyes from the bulb while person is in normal sitting position.

3. The support should raise the lamp high enough to allow adequate light on the surface of the desk. The support should be adjustable to allow different heights of the shade of eight inches to fourteen inches above the base.

4. The base should support the weight of the rest of the lamp so that the lamp is not easily knocked over.

5. The electrical subsystem should be inaccessible to probing fingers for safety reasons. Electrical subsystem should meet Underwriter Laboratories standards.

6. The ON and OFF buttons should turn on and off the light bulb.

7. The power cord and plug match USA home outlets of 120 volts 60 HZ.

Inputs:

1. Finger applying and releasing pressure on ON and OFF buttons

2. Hand adjusting of support.

3. Hand pushing power plug into outlet and pulling it out.

Outputs:

1. Light from lamp

2. So an individual knows when he or she pushed a button, the system should provide feedback.

States:

1. Plug is either plugged into electrical outlet or not. The user changes the state.

2. The ON button and the OFF button can be in depressed or normal state. The user changes the state by pressing and releasing with his or her finger.

3. The fluorescent tube has several states. The tube is in an inactive state when no electricity is applied and, therefore, no light is produced. The tube is in an ionizing state when the two end elements have current through each end. If the gas inside the tube is ionized, a sustaining voltage applied across the ends of the tube will place the tube in the operational or third state. In the third state, the gas glows and gives off light. Pressing the ON button must effect the state transitions from the inactive state to ionized state to sustaining state. Pressing the OFF button must place the tube in the inactive state. Pressing the ON while the tube is in the sustaining state should cause no harm to the lamp or the individual. The electronics component changes the state of the tube under the control of the states of the ON and OFF buttons.

4. The state of the support is a variable range of heights. The user changes the state by adjusting the support.

5. The state of the base should allow the lamp to be stable for the entire range of the adjustment of the support. That is, the lamp should not be unstable and easily knocked over.

Failure Modes:

1. Bad bulb

2. Bad electronics

3. No 120 volts

Comments:

Analyst find writing functional requirements hard. The first difficulty is in making them functional in nature, i. e., the requirements should describe what is required without implying how the system will meet the requirements and, therefore, provide maximum flexibility for the system designers. The second difficulty is identifying the important states and their behavior.

Designer should worry about over engineering a product. For example, having a red light on the base for indication of 120 volts is probably over engineering.