Dominique Adam M.

Iglesia | CpE09A
2.1
1. 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 wellknown. 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.2
Business 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.5
1.
2.
3.
4.

Architectural design
Interface design
Component design
Database design

Dominique Adam M. Iglesia | CpE09A

2.6
Systems 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 outof-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.
o The user interface may be minimal and not intuitive.
o There may be no error detecting or handling code.
o Such error messages as there are will likely be vague.
o Generally, prototypes are not viewed as high quality products, but just
tools to aid the development process