Part Two

Requirements and
Specification
This part of the Worktext is concerned with the introductory phases of
the software process in which the requirements for the software are
established and specified in detail for further development.

Contents
1. Requirements Engineering and Analysis
2. System Models
3. Requirements Definition and Specification
4. Software Prototyping

Part Two Requirements and Specifications

Objectives:

 To introduce requirements, the first phase of large-scale software system development.

  To explain why system requirements must be written at different levels of detail for
different types of reader.
 To explain why it is important to consider the analysis of a system from different
perspective or viewpoints.
 To explain the role of system models in the requirements analysis process.
 To describe different types of system model.
 To illustrate a form-based method of writing precise definitions of system requirements.
 Develop proper work attitude towards other.

2.1 Requirement Engineering and Analysis

A requirement is a feature of the system or a description of something the system is
capable of doing in order to fulfill the system’s purpose. This is also a process of establishing the
services the system should provide and the constraints under which it must operate.

Why is Requirement Important?

In 1994, the Standish Group surveyed over 350 companies about their over 8000 software
projects to find out how well they were faring. The result are sobering. Thirty-one percent of the
software projects were canceled before they were completed. Moreover, in large companies, only
9% of the projects were delivered on time and within budget; 16% met those criteria in small
companies (Standish 1994).

To understand why, Standish (1995) asked the survey respondents to explain the causes
of the failed projects. The top factors were reported to be:

1. Incomplete requirements (13.1%)

2. Lack of user involvement (12.4%
3. Lack of resources (10.6%)
4. Unrealistic expectations (9.9%)
5. Lack of executive support (9.3%)
6. Changing requirements and specification (8.7%)
7. Lack of planning (8.1%)
8. System no longer needed (7.5%)

Lack of care in understanding, documentation, and managing requirements can lead to a

myriad of problems: building a system that solves the wrong problem, that doesn’t function as
expected, or that is difficult for the users to understand and use.

Boehm and Papaccio (1988) report that if it cost $1 to find and fix a requirements-based
problem during the requirements definition process, it can cost $5 to repair it during design, $10
during unit testing, and as much as $200 after delivery of the system.

Two sets of Requirements

Software Engineering | For CICT Classroom Use Only

26
 1. Requirements Definition. Is a statement, in a natural language plus diagrams, of what
services the system is expected to provide and the constraints under which it must
operate. It is generated using customer supplied information.

Water quality information must be accessible immediately.

2. Requirement Specification. A structured document which sets out the system services in
details. This document, which sometimes called functional specification, should be
precise. It may serve as a contract between the system buyer and the software developer.

Water quality records must be retrieved within five seconds of request.

The requirement process should normally involve writing a requirement definition then
expanding this requirements specification. Figure 2.1.1 illustrates how a definition of a
requirement may be expected in more detailed level as a requirement specification.

Requirement Definition
1. The software must provide a means of representing and accessing external files
created by other tools.

Requirement Specification
1. The user should be provided with facilities to define the type of external files.
2. Each external file type may have an associated tool which may be applied to the
file.
3. Each external file type may be represented as a specific icon on the user’s
display.
4. Facilities should be provided for the icon representing an external file type to be
defined by the user.
5. When a user selects an icon representing an external file, the effect of that
selection is to apply the toll associated with the type of the external file to the
file represented by the selected icon.
\

Figure 2.1.1. Requirements Definition and Requirements Specification

Functional and Nonfunctional

Software Engineering | For CICT Classroom Use Only

27
 Requirements describe a system’s behavior. To help us describe requirements in this way,
Yeh (1982) and others divide requirements into two categories:

1. Functional requirements. It describes an interaction between the system and its

environment.
2. Nonfunctional Requirements. Describes a restriction on the system that limits our
choices for constructing a solution to the problem.

Types of requirements

The requirements definition describes everything about how the system is to interact with
its environment.

Physical Environment:
 Where is the equipment to function?
 Is there one location or several?
 Are there any environmental restrictions, such as temperature, humidity, or magnetic
interference?

Interfaces:
 Is the input coming from one or more other systems?
 Is the output going to one or more other systems?
 Is there a prescribe way in which the data be formatted?
 Is there a prescribed medium that the data must use.

Users and Human Factors:

 Who will use the system?
 Will there be several types of user?
 What is the skill level of each type of user?
 What kind of training will be required for each type of user?
 How easy will it be for a user to understand and use the system?
 How difficult will it be for a user to misuse the system?

Functionality:
 What will the system do?
 When will system do it?
 How and when can the system be change or enhanced?
 Are there constraints on execution speed, response time, or throughput?

Documentation:
 How much documentation is required?
 To what audience is the documentation addressed?

Data:
 For both input and output, what should the format of the data be?

Software Engineering | For CICT Classroom Use Only

28
  How often will it be received or sent?
 How accurate must it be?
 To what degree of precision must the calculations be made?
 How much data flows through the system?
 Must any data be retrained for any period of time?

Resources:
 What materials, personnel, or other resources are required to build, use, and maintain
the system?
 What skills must the developers have?
 How much physical space will be taken up by the system?
 What are the requirements for power, heating, or air conditioning?
 Is there a prescribed timetable for development?
 Is there a limit on the amount of money to be spent on development or on hardware
and software?

Security:
 Must access to the system or to information be controlled?
 How will one user’s data be isolated from others?
 How will user programs be isolated from other programs and from the operating
system?
 How often will the system be backed up?
 Should precautions be taken against fire or theft?

Quality Assurance:
 What are the requirements for reliability?
 How must the characteristics of the system be demonstrated to others?
 Must the system detect and isolate faults?
 What is the prescribed mean time between faults?
 Is there a maximum time allowed for restarting the system after a failure?
 How can the system incorporate changes to the design?
 Will maintenance merely correct errors, or will it also include improving the system?
 What efficiency measures will apply to resources usage and response time?
 How easy should it be to move the system from one location to another or from one
type of computer to another?

Figure 2.1.2 summarizes the aspects of a system to be considered as possible

requirements. The list of quality software characteristics also contains possible system
descriptors to be used as a basis for generating software requirements.

Software Engineering | For CICT Classroom Use Only

29
 Data
Documentati
Documentati Resources
Resources
on
on

Functionality
Functionality Security
Security

Users and
Quality
Human
Human Assurance
Assurance
Factors
Factors

Physical
Physical
Interface
Interface Requirements Environment
Environment

Figure 2.1.2. Types of Requirements

Requirement Engineering Process

The requirement engineering process is shown in Figure 2.1.3. This process is a set of
activities that lead to the production of the requirements definition and requirements
specification.

Feasibility Study Requirements

Analysis

Requirement
Definition
Feasibility Report
Requirements
Specification

System Models

Definition of
Requirements

Requirement Specification of
Document Requirements
Software Engineering | For CICT Classroom Use Only
30
 Figure 2.1.3. The Requirements Engineering Process

Four Principal Stages

1. Feasibility Study. The study will decide if the proposed system will be cosy-effective
from a business point of view and if it can be developed given existing budgetary
constraints.
2. Requirement analysis. This is the process of deriving the system requirements
through observation of existing systems, discussions with potential users and
procurers, task analysis and so on. This may involve the development of one or more
different system models.
3. Requirement Definition. It translates the information gathered during the analysis
activity into a document that defines a set of requirements. These should accurately
reflect what the customer wants.
4. Requirement Specification. A detailed and precise description of the systems
requirements is set out to act as a basis for a contract between client and software
developer. The creation of document is usually carried out in parallel with some high-
level design.

The Software Requirements Document

System requirements are expressed in a software requirements document. The software

requirement document is the official statement of what is required of the system developers.

Heninger (1980) suggest that there are six requirements which a software requirements
document should satisfy:

1. It should only specify external system behavior.

2. It should specify constraints on the implementation.
3. It should be easy to change.
4. It should serve as a reference tool for system maintainers.
5. It should record forethought about the life cycle of the system.
6. It should characterize acceptable responses to undesired events.

The requirement document is a combination of requirements definition and requirements

specification. The best organization is as a series of chapters with the detailed specification
perhaps presented as an appendix to the document. A possible generic structure for a
requirements document is shown in Table 2.1.1.

Table 2.1.1
The Structure of a Requirement Document

Software Engineering | For CICT Classroom Use Only

31
 Chapter Description
Introduction This should describe the need for the system. It should
briefly describe its functions and explain how it will work
with other systems.
Glossary This should define the technical terms used in the
document. No assumptions should be made about the
experience or expertise of the readers.
System Models This should set out one or more system models showing
the relationships between the system components and the
system and its environment.
Functional Requirements The services provided for the user should be described in
Definition this section.
Non-functional The constraints imposed on the software and restrictions on
Requirements Definition the freedom of the designer should be describes here and
related to the functional requirements.
System Evolution This should describe the fundamental assumptions on
which the system is based and anticipated changes due to
hardware evolution, changing user needs, and so on.
Requirements Specification This should describe the functional requirements in more
detail.

The requirement document may also include, either in separate chapter in the document
or as appendices, the following information:

 Hardware. If the system is to be implemented on special hardware, this hardware and its
interface should be described.
 Database Requirements. The logical organization of the data used by the system and its
interrelationships should be described.
 Index. More than one kind of index to the document may be provided. As well as a
normal alphabetic index, there may be an index per chapter, an index of functions and so
on.

Requirements Validation

Requirements validation is concerned with showing that the requirements actually define
the system that the customer wants. If this validation is inadequate, errors in the requirements
will be propagated to the system design and implementation.

There are several aspects of the requirements which must be checked:

1. Validity. A user may think that a system is needed to perform certain functions.
However, further thought and analysis may identify additional or different functions
that are required.
2. Consistency. Any one requirement should not conflict with any other.

Software Engineering | For CICT Classroom Use Only

32
 3. Completeness. The definition should include all functions and constraints intended by
the system user.
4. Realism. There is no point specifying requirements that are unrealized. It may be
acceptable to anticipate some hardware development but development in software
technology are much less predictable.
Validation should not be seen as a process to be carried out after the requirements
document has been completed. Regular requirements review involving both users and software
engineers are essential while the requirements definition is being formulated.

A requirements review is manual process which involves multiple readers from both
clients and contractor staff checking the requirements document for anomalies and omissions.
Requirements review can be formal or informal. Informal Review simply involves contractors
discussing requirements with clients. In a Formal Review, the development team should “walk”
the client through the system requirements explaining the implications of each requirement.

The review team should check each requirement for consistency and should check the
requirements as a whole for completeness. They might also check for:

 Verifiability. Are the requirements as stated realistically testable?

 Comprehensibility. Is the requirement properly understood by the procurers or end-
use of the system?
 Traceability. Is the origin of the requirements clearly stated?
 Adaptability. Is the requirement adaptable?

Requirements Evolution

Developing software requirements focuses attention on software capabilities, business

objectives and other business systems. The time required to analyze requirements and to develop
a large system may be several years.

Form an evolution perspective, requirements fall into two classes:

1. Enduring Requirements. These are a relatively stable requirement which derives

from the core activity of the organization and which relates directly to the domain of
the system.
2. Volatile Requirements. These are requirements which are likely to change during the
system development or after the system have been put into operation.

Harker et al. (1993) have suggested that volatile requirements fall into four classes:

1. Mutable Requirements. Requirements that change because of change to the

environment in which the organization is operating.
2. Emergent Requirements. Requirements that emerge as the costumer understands of
the system develop during the system development.
3. Consequential Requirements. Requirements that result from the introduction of the
computer system.

Software Engineering | For CICT Classroom Use Only

33
 4. Compatibility Requirements. Requirements that depend on the particular systems or
business processes within an organization.

Requirements Analysis

After the initial feasibility studies, the first major stage is the requirements analysis or
elicitation. This may involve a variety of different kinds of people in an organization. These
include system end-users who will ultimately interact with the system and their managers.

To carry out a requirements analysis, analyst must develop an understanding of the

problem domain. The actual process is often domain-dependent. The process model shown in
Figure 2.1.4 illustrates a number of important requirements analysis activities

Requirements
Requirements
Definition and
Definition and
Specification
Specification

Requirements
Requirements
Validation
Validation

Process Entry Domain Prioritization

Domain Prioritization
Understanding
Understanding

Requirements Conflict
Requirements Conflict
Collections Resolution
Collections Resolution

Classification
Classification

Figure 2.1.4. The Requirements Analysis Process

The activities shown in Figure 2.1.4 are highly interactive with continual feedback from
each activity to other activities. The process can be viewed as a cycle, starting with domain
understanding and ending with requirements validation. The process activities are:

1. Domain Understanding. Analysis must develop their understanding of the application

domain. Therefore, if a system for a supermarket is required, the analyst must find out as
much as possible about supermarkets.

Software Engineering | For CICT Classroom Use Only

34
 2. Requirements Collection. This is the process of interacting with stakeholders in the
system to discover their requirements.
3. Classification. This activity takes the unstructured collection of requirements and
organizes them into coherent clusters.
4. Conflict Resolution. This activity is concerned with finding and resolving these conflicts.
5. Prioritization. This stage involves interaction with stakeholders to discover the most
important requirements.
6. Requirements Validation. The identified requirements are checked to discover if they are
complete, consistent and in accordance with what stakeholders really want from the
system.

Davis (1990) suggests that the analysis process must always include three important
structuring activities:
1. Partitioning. Concerned with identifying the structural relationship between entities so
that one entity can be described in terms of its parts.
2. Abstraction. Concerned with identifying generalities among entities.
3. Projection. Concerned with identifying different ways of looking at a problem.

Viewpoint-oriented Analysis

The different viewpoint on a problem sees it in different ways. However, their

perspective is not completely independent but usually partially overlaps. A key strength of
viewpoint-oriented analysis is recognizing these overlaps.

A viewpoint may be considered as:

 Data source or sink. In this case, viewpoints are responsible for producing or
consuming data. The analysis involves identifying all such viewpoints. Identifying
what data is produced or consumed and what processing is carried out.
 Representation Framework. In this case, a viewpoint is considered to be a particular
type of system model.
 Reserve

Method-based Analysis

Method-based analysis is probably the most widely used approach to requirements

analysis. It depends on the application of some structured method to understand the system. The
results of the analysis are expressed as a set of system models defined by whatever method is
being used.

Structured methods usually include some or all of the following:

 A process model. This defines the activities in the method. Examples of activities are
data-flow analysis and control scenario identification.

Software Engineering | For CICT Classroom Use Only

35
  System modeling notations. These notations may be diagrammatic, form-based or
linguistic. Examples of diagram types are data-flow diagrams, entity-relationship
diagrams and object structured diagrams.
 Rules applied to the system model. Rules may hold within a single model or across
models.
 Design guidelines. These are not enforceable rules but are intended to avoid poor
design. An example of such a guideline might be that an object should normally have
no more than five sub-objects.
 Reports templates. These define how the information collected during the analysis
should be presented. Information in diagrams in normally supplemented by other
textual information.

Characteristics of Requirements

To ensure that the eventual product is successful, it is important that the requirements be
of high quality; what is not specified usually is not built. Below are the desirable characteristics
for which we should check.

1. Are the requirements correct? Both developer and the customer should review the
documented requirements, to ensure that they conforms to our understanding of the
requirements.
2. Are the requirements consistent? In general, two requirements are inconsistent if it is
impossible to satisfy both simultaneously.
3. Are the requirements unambiguous? The requirements are ambiguous if multiple
readers of the requirements can walk away with different but valid interpretations.
4. Are the requirements complete? The set of requirements is complete if it specifies
required behavior and output for all possible inputs in all possible states under all
possible constraints. The requirements are externally complete if all states, state changes,
inputs, products and constraints are described by some requirement. A requirements
description is internally complete if there are no undefined terms among the
requirements.
5. Are the requirements feasible? That is, does a solution to the customer’s needs even
exists?
6. Is every requirement relevant? Sometimes a requirements restricts the developers
unnecessarily, or includes functions that are not directly related to the customer’s needs.
7. Are the requirements testable? The requirements are testable if they suggest accepted
test that would clearly demonstrate whether the eventual product meets the requirements.
8. Are the requirements traceable? Are the requirements organized and uniquely labeled
for easy reference.

2.2 System Models

One of the outputs of the requirements analysis process is a set of system models that
presents abstract description of the system to be developed. A system model is an abstract of the
system being studied rather than an alternative representation of the system. Different types of

Software Engineering | For CICT Classroom Use Only

36
system models are based on different approaches to abstraction. Examples of the different types
of system models which might be produced as part of the analysis process and the notations used
to represent these models are:

 Data-processing Model. Data flow diagrams may be used to show data is processed at
different stages of the system.
 Composition Model. Entity-relationship diagrams may be used to show some entities in
the system are composed of other entities.
 Classification Model. Object class/inheritance diagrams may be used to show how
entities have common characteristics.
 Stimulus-Response Model. State transition diagram may be used to show how the
system reacts to internal and external events.
 Process Model. Process models may be used to show the principal activities and
deliverables involved in carrying out some process.

Data-flow Model

Data-flow models are intuitive way of showing how data is processed by a system. This
are used to show how fata flows through a sequence of processing steps. The data is transformed
at each step before moving to the next stage.

Figure 2.2.1 shows the notations used for data-flow diagrams.

Processing Step

Data Sources

Data Name

Figure 2.2.1. Data-flow Notations

Software Engineering | For CICT Classroom Use Only

37
Entity-Relationship Diagrams

It is convenient to build a conceptual model of problems that identifies what object or

entities are involved, what they look like, and how they relate to one another.

The entity-relationship diagram (ER diagram) (Chen 1976) is a popular graphical

notational paradigm for representing conceptual models. It forms the basis of most object-
oriented requirements and design notations, where it is used to model the relationships among
objects in a problem description or to model the structure of a software application.

ER diagram have three core constructs – entities, attributes, and relations – that are
combined to specify a problem’s elements and their interrelationships as shown in Figure 2.2.1.

Figure 2.2.2. Entity diagram of turnstile problem.

.

1. Entity. Depicted as a rectangle, represents a collection of real-world objects that have

common properties and behavior.
2. Relationship. Depicted as an edge between two entities, with a diamond on the middle of
the edge specifying the type of relationship.
3. Attribute. An annotation of an entity that describes data or properties associated with the
entity.

Object Models

An object-oriented approach to engineering was first proposed in 1967 which the

development of the Simula-67 language. However, it is only since the late 1980s that this method
of development has been widely adopted in industry.

Object Models developed during requirements analysis may be used to represent both
system data and its processing. An object class is an abstraction over a set of objects which
identifies common attributes and the services or operation which are provided by each object.
Figure 2.2.3 shows the notation used to represent object model.

Software Engineering | For CICT Classroom Use

< class Only
name >
38

< attributes >

 < services >

Figure 2.2.3. Notation to represent an object class

2.3 Requirements Definition and Specification

Requirements definitions are customer-oriented description of what the system should
do. They should be written in the customer’s language. Requirements specifications are more
precise descriptions of the systems functionality and the constraints on its operation. They are
intended to specify the systems for software designers so they are sometimes called functional
requirements.

Requirements Definition

A software requirements definition is an abstract description of the services which the

system should provide and the constraints under which the system must operate. It should only
specify the external behavior of the system.

Three types of major problem with requirements definition written in natural language:

1. Lack of clarity. It is very difficult to use language in a precise and unambiguous way
without making the document wordy and difficult to read.
2. Requirements confusion. Functional requirements, non-functional requirements,
system goals and design information may not be clearly distinguished.
3. Requirements amalgamation. Several different requirements may be expressed
together as a single requirement.

Requirements Specification

Requirements specifications add further information to the requirements definition. This

usually presented with the system models developed during requirements analysis.

Natural language is often used to write requirements specification. However, a natural

language specification is not a particular good basis for either a design or a contract between
customer and system developer. There are several reasons for this.

Software Engineering | For CICT Classroom Use Only

39
 1. Natural language understanding relies on the specification readers and writers using the
same words for the same concepts.
2. A natural language requirements specification is over flexible.
3. Requirements are not partitioned effectively by the language itself.

Alternatives to the use of natural language which add structure to the specification and
which should reduce ambiguity:

1. Structured natural language. This approach depends on defining standards forms or

templates to express the requirements specification.
2. Design description language. This approach relies on using a language which is like a
programming language but with more abstract to specify the requirements by defining an
operational model of the system.
3. Requirements specification language. Various special-purpose language have been
designed to expressed software requirements.
4. Graphical notations. Various graphical notations for requirements are SADT.
5. Mathematical specification. These are notations based on a formal mathematical
concepts such as finite-state machines or more basic concepts such as sets.

Non-functional Requirements

Non-functional requirements define system properties and constraints. This are

sometimes more critical than functional requirements. Some non-functional requirements may be
process rather than product requirements and they may also arise through user needs.

Table 2.3.1 shows different types of non-functional requirements. These can be classified
depending on how they had been derived.

Table 2.3.1. Types of non-functional requirements

Non-functional Requirements
Product Usability requirements
Requirements Efficiency requirements
Reliability requirements
Portability requirements
Performance requirements
Space requirements
Process Requirements Delivery requirements
Implementation requirements
Standard requirements
External Interoperability requirements
Requirements Ethical requirements
Legislative requirements
Safety requirements
Privacy requirements

Software Engineering | For CICT Classroom Use Only

40
  Product requirements. These are requirements which result from the need for the
delivery product to behave in a particular way.
 Organizational requirements. These are requirements which are a consequence of
organizational policies and procedure.
 External Requirements. These broad heading covers all requirements which arise from
factors external to the system and its development process.

2.4 Software Prototyping

A software prototype is not normally intended for design validation but to help develop
and check the real requirements of the system. The objectives of prototyping should be made
explicit from the start of the process.

The benefits of developing a prototype early in the software process are:

1. Misunderstanding between software developers and users may be identified as the

functions are demonstrated.
2. Missing user service may be detected.
3. Difficult to use or confusing user services may be identified and refined.
4. Software development staff may find incomplete and/or inconsistent requirements as
the prototype is developed.
5. A working, although limited, system is available quickly to demonstrate the
feasibility of quality system.

Although the principal purpose of prototyping is to validate software requirements,

software prototype also have other uses.

1. User training. A prototype system can be used for training users before the final
system has been delivered.
2. System testing. Prototypes can run “back-to-back” tests. This reduces the need for
tedious manual checking of test runs.

Types of Prototyping

1. Evolutionary Prototyping. This is based on the idea of developing an initial

implementation, exposing this to user comment and refining this through many stages
until an adequate system has been developed. The key to success in this approach is to
use techniques which allows for rapid system iterations.

There are three main problems it evolutionary prototyping which are particularly
important when large. Long-lifetime systems are to be developed:

Software Engineering | For CICT Classroom Use Only

41
  Existing software management structures are set up to deal with a software
process model that generates regular deliverables to assess progress.
 Continual change tends to corrupt the structure of the prototype system.
Maintenance is therefore likely to be difficult and costly.
 It is not clear how the range of skills which is normal in software engineering
team can be used effectively for this mode of development.

2. Throw-away Prototyping. This approach extends the requirements analysis process with
the intention of reducing overall life costs. The principal function of the prototype is to
clarify requirements and provide additional information for managers to access process
risks. Components from the prototype may be reuse in the production of quality systems.

Prototyping Techniques

Prototyping techniques allow the rapid development of a prototype system. As staff costs
are the principal software cost, rapid development means that prototype costs are minimized. It
also means that feedback from users can be obtained early in the overall software process.

There are a number of techniques which have been used for system prototyping. These
include:

 Executable specification languages

 Very high level languages
 Application generators and fourth-generation languages
 Composition of reusable components

Republic of the Philippines

EASTERN SAMAR STATE UNIVERITY
College of Information & Communication Technology
Salcedo Campus
Salcedo, Eastern Samar

EVALUATION NO. 02

Name: _______________________________________ Date: _______________

Software Engineering | For CICT Classroom Use Only

42
 1. Suggest who might be stakeholders in a university student records system. Explain why it
is unavoidable that the requirements of different stakeholders will conflict in some ways.

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

2. Explain why requirements analyst need to develop knowledge of the application domain
of the system which is being specified.

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

3. Suggest why data-flow diagrams are intuitive and easy to understand by non-technical
staff.

Software Engineering | For CICT Classroom Use Only

43
 ________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

4. Based on your experience using the ATM (Automated Teller Machine). Draw a data-flow
diagram, modeling the data processing involved when a customer withdraws cash from
the machine.

Software Engineering | For CICT Classroom Use Only

44
 5. Explain why, for large system development, it is recommended that prototypes should be
“throw-away” prototypes.

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

6. From your own point of view, what type of prototyping techniques would you
recommend and why?

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

Software Engineering | For CICT Classroom Use Only

45
Software Engineering | For CICT Classroom Use Only
46