Dominique Adam M. Iglesia

Dominique Adam M. Iglesia | CpE09A

2.11. Anti-lock braking system. The waterfall model is the most appropriate approach to use. It must be plan carefully before implemented because it is a safety-critical system. 2. Virtual reality system. This is a system where the requirement will change and there will be an extensive user interface components. Incremental development is the most appropriate model.3. University accounting system. The requirement of this system is fairly well-known. Thus a reuse-based approach is likely to be appropriate for this.4. Interactive travel planning system. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.

2.2Business software systems usually complex, software intensive, and frequently being changes when business goals or processes are changed.So incremental development is better.Real-time systems usually involve many hardware components which are not easy to change and cannot be incremental. Also real-time systems usually safety critical which needed be built based on well planned process

2.51. Architectural design2. Interface design3. Component design 4. Database design

2.6Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful.

Examples of process activities that support change are:1. Recording of requirements rationale so that the reason why a requirement is included is known. This helps with future change.2. Requirements traceability that shows dependencies between requirements and between the requirements and the design/code of the system.

2.7 Here one should note that prototypes are often used as complete systems, due to the pressures of development. However, they have several faults. The user interface may be minimal and not intuitive. There may be no error detecting or handling code. Such error messages as there are will likely be vague. Generally, prototypes are not viewed as high quality products, but just tools to aid the development process