Structured System Analysis and Structured Design

Structured System Analysis and Structured Design

Exploratory. In this role a prototype is used to help with clarification of user requirements and possibly with identifying how introducing the system might lead to the need to modify the wider work practices of an organization. One purpose might be to help with developing an analysis of users‘ needs by providing a set of Profile of an incremental design process. Incremental design possible models for them to use and assess. Essentially this form of prototype is also likely to be a ‗throw-away‘ item, and it can be considered as enhancing the information provided from the requirements analysis and the functional specification activities. For the purposes of this chapter, we can see that the two roles of prototyping that are most likely to be extensively employed in incremental development forms are the evolutionary and the exploratory.

The evolutionary role fits with the notion of the emergent organization that was briefly described in the preceding section. Indeed, in such a context there is really no notion of there being an ‗end product‘, only the notion of the 'current state‘ of a system. Each new state of the system is then achieved by modifying a previous state (not necessarily the 'current state‘), or even by creating a completely new implementation. So in a context where the incremental design process is continuous and on-going, the development of software may closely approximate to a continuous process of evolutionary prototyping. One of the characteristics of incremental design is that it usually involves some degree of interaction with the 'customer‘ (or with 'end-users‘, who may or may not be the customer.) Here we can see a role for the exploratory prototype, which may address anything from very specific aspects of some element of a system through to the functionality or behaviour of the complete system. Of course a prototype need not actually be an item of software, especially where such aspects as possible scenarios for the use of a system are being considered

An example – DSDM

Person‘s implementation language is another person‘s prototyping tool, and so the list is really an endless one. So having examined some of the reasons why an incremental design approach may be the appropriate one to adopt, and then briefly considered some of the mechanisms for organizing the feedback needed for incremental design, we now need to conside how the process might be structured. In the next section we examine an example of one approach to RAD, in the shape of the DSDM method. An example – DSDM