EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 145 of 197

The requirements subphase identifies requirements, preferring to capture them as use cases, scenarios, statecharts, and constraints. FIGURE 3 Semi-spiral lifecycle ' Requirements Analysis the ongoing process improvement and proj ect redirection. An initial set of prototypes is ide ntified, although their details aren't fully defined until some requirements analysis has taken place. As a rough rule of thumb, the prototypes should be scheduled no less than every three weeks and no more tl1an eve ry six weeks apart. The initial planning also must construct software development plans, configu- ration manageme nt plans, reuse Electronic Systems Design Mechanical Systems Design . Software Systems Design -...! .... -~ plans, and so on so th at the team knows the procedures by which they will accomplish their work. The requireme nts subphase ide n- FIGURE 4 Standard ROPES spiral tifi es requireme nts, pre fe rrin g to cap ture th em as use cases, sce nari os, sta techa rts, and co nstraints. In th e full spiral li fecycle, it is commo n during th e first itera ti o n to get "the lay o f th e la nd" of th e require- ments-that is, ide ntify a ll or most of the use cases. But in each spiral, o nly a few (one to three is ve ry com- mon ) use cases are expl ored in any great d epth . In th e semi-s pira l model, th e requireme nts and system engineerin g subphases are removed from th e spiral, but object analys is does occur durin g each spira l. The re may a lso be some risk reduc- ti on activities and goals th a t a re inco rpora ted as part of th e pro to- types as we ll , such as th e expl orati on of performance of a specifi c compil- er or middlewa re compone nt. The systems engineering subphase then identifi es subsystems and/ o r components or the ove rall system (not necessary fo r simple sys tems) and breaks down the system use cases into sub-use cases using « includes» and « extends» use case relations. Each of th ese subsys te m-l evel use cases maps onto a single subsystem. The sys- tem use case is wen realized by the set of subsystems collaborating together. Each subsystem is specified in tenns of its own subsys tem level use cases (derived from we system level use cases) and its in terface specification. The adequacy of the subsys tem decomposition is asce rtained by the 144 DECEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13