Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Apply requirements planning in embedded system design (Part 1)

Posted: 13 Dec 2010     Print Version  Bookmark and Share

Keywords:embedded systems  requirements document  electronic alarm clock 

Once all of the storyboards are complete, take each storyboard and note down how many key presses are required to set each function, worst case. For the clock time set example, the worst-case number of key presses is 83, 1 for the initial press and hold of the TIME_SET button, 23 presses of the FAST_SET to set hours, and 59 presses of the SLOW_SET to set minutes.

Next, calculate the time required to perform that number of button presses. Assume that a key can be pressed repeatedly at a rate of 2–3 presses per second. For the clock this means that the worst-case time required to set the time is 42 seconds if each key press is made individually, and as much as 83 seconds if the autorepeat feature is used.

image name

Table 5: List of commands used in an alarm clock.

Now, for the complete command structure, list the commands based on the frequency that each command is likely to be used, with most often used at the top of the list, and least often used at the bottom. Next to each command sequence name, list the worst-case number of key presses required to perform the command and the estimated time required. In table 5, is the list for the commands used in the alarm clock: The times and number of key presses should be the inverse of the frequency of use. Specifically, the most common commands should have the least number of key presses and the fastest time to perform, and the least-often used commands should have the largest number of key presses and the longest time to set.

If any command is out of sequence, then the flow of that command should be reconsidered, so that it falls in line with the other commands. From the example, Set Time and Set Alarm time are the longest to set and the least frequently used. The Snooze command is the most frequently used and the fastest to activate.

Another criterion for menubased command structures is the depth of the menu that holds a command. Commonly used commands should be at the top level, or at the most, one level deep in the command structure. Commands deeper in the menu structure should have progressively less frequent use (figure 3).

image name

Figure 3: Example menu structure.

In this example, the most-often used command is Delete and it is at the top of the menu. Edit commands and File commands come next, with the New file commands buried the deepest in the menu. Typically, a user can remember one or two levels of a menu structure, provided that each level has only three or four functions.

Any deeper, and they will typically have to consult a manual (unlikely), or dig through the menus to find the function they want. While designers might wish that users used the manuals more often, making this a requirement by burying commonly used commands at the bottom of a complex menu structure will only drive customers to your competitors.

Another obvious, but nonetheless often overlooked, requirement is that related commands should be in a common subdirectory, and the relationship of the commands should be viewed from the user�s point of view, not the designers.

Just because Paste and Replace have similar functions does not mean that the user will look for them in the same submenu. The correct choice is to group the commands as shown, by their use by the user, rather than their inner workings.

One hallmark of a good user interface is reusing buttons for similar functions in different commands. For instance, in the clock example, there was a FAST_SET and SLOW_ SET button. They are used to set the current time, so it makes sense that the same buttons would also be used to set the Alarm time.

Keeping common functions with the same buttons allows the user to stereotype the button�s function in their minds and aids in their understanding of the command structure. With this in mind, it would be a major failing in a user interface to change the function of the control, unless and only unless, the second function is an extension of the control�s original function.

For instance, changing from 12 hour to 24 hour by pressing FAST_SET and SLOW_SET buttons together is acceptable because it is an extension of the buttons� original functions. Using the SNOOZE button in combination with the ALARM_SET button is just confusing for the user.

 First Page Previous Page 1 • 2 • 3 • 4 • 5 Next Page Last Page

Comment on "Apply requirements planning in embed..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top