Capturing Requirements for Real-Time and Embedded Systems

Many developers regard requirements capture with a distain normally reserved for Windows crashes and Richard Simmons exercise videos. They see it as a waste of time that diverts them from what they ought to be doing ... cranking out code. However, in a requirements-driven process, the developers always know that what they're doing actually relates to the goals and purposes of the system. To properly understand what features ought to be designed and implemented, as well as how they ought to work, a deep understanding of the purposes of the system, the workflow of the user (if applicable) with respect to the system, the set of features the system provides, the devices with which it must interact and how those interactions take place, what should happen when something expected or "bad" occurs, and exactly how the features must be visible to the user and the external devices. These are all part of the requirements or specification of the system. If you do a good job at understanding the requirements, then your development work will be most productive, there will be less rework, and your customers will be the happiest.

View Entire Paper | Previous Page | White Papers Search

If you found this page useful, bookmark and share it on: