NAMA : MUHAMMAD IQBAL SYAMWARDANA

NIM : 1811102441111

6.14 Describe four traditional techniques for collecting information during analysis. When might
one be better than another?

Answer :

1. Interviewing and listening involves talking with users individually or as a group to discover
their views about the current and target systems; it also involves carefully preparing an
interview outline and guide before conducting the interview. Interviews are best done when
only a few people are involved, when you need open–ended questions or the questions vary
from individual to individual, or when a more personal method is needed.
2. Administering questionnaires involves designing a questionnaire and determining who
should respond to it; this method is typically used when there are too many key users to
interview individually. Questionnaires are best when many people are involved, each
person is to answer roughly the same questions, and people are remote or do not need
personal care.
3. Directly observing users involves watching how people work in order to uncover
information users may not be consciously aware of. Direct observation is best when
detailed or complicated procedures must be documented, when you do not want people to
know they are giving you information you need, when only a few people are involved, and
observational data are representative of all situations.
4. Analyzing procedures and other documents involves identifying and collecting written
procedures, forms, reports, and other relevant documents in order to better identify data
and processes that would be part of the current and target systems. Analyzing documents
is the best technique when documents are complete and unbiased, when other forms of
requirements determination are too obtrusive, and when history must be studied and people
do not have first–hand data about history.

6.15 What is JAD? How is it better than traditional informationgathering techniques? What are its
weaknesses?

Answer :
Joint Application Design or JAD is a structured process in which users, managers, and analysts
work together for several days in a series of intensive meetings to specify or review system
requirements. It’s better than traditional techniques because you have all key personnel in one
place at one time, saving everyone time and resulting in high levels of system ownership as more
people have more of a role in the development process. Weaknesses include the level of
commitment necessary to make the JAD work, the high degree of required planning, and the
typical lack of computer support.

6.18 How can CASE tools be used to support requirements determination? Which type of CASE
tool is appropriate for use during requirements determination?
Answer :
CASE tools can support requirements determination by supporting JAD and prototyping with
diagramming, form and report design, repository access, and prototyping tools. The best-suited
CASE tools are upper CASE tools.

7.19 What is a DFD? Why do systems analysts use DFDs?

Answer :
A data flow diagram is a picture of the movement of data between external entities and the
processes and data stores within a system. Systems analysts use data flow diagrams to help them
model the processes internal to an information system as well as how data from the system’s
environment enter the system, are used by the system, and are returned to the environment. DFDs
help analysts understand how the organization handles information and what its information needs
are or might be. Analysts also use DFDs to study alternative information handling procedures
during the process of designing new information services.

7.20 Explain the rules for drawing good DFDs.

Answer :

Process:

• No process can have only outputs. It is making data from nothing (a miracle). If an object has
only outputs, then it must be a source.
• No process can have only inputs (a black hole). If an object has only inputs, then it must be a
sink.

• A process has a verb phrase label.

Data Store:

• Data cannot move directly from one data store to another data store. Data must be moved by a
process.

• Data cannot move directly from an outside source to a data store. Data must be move by a process
that receives data from the source and places the data into the data store.

• Data cannot move directly to an outside sink from a data store. Data must be moved by processes.

• A data store has a noun phrase label.

Source/Sink:

• Data cannot move directly from a source to a sink. Data must be moved by a process. If the data
are of any concern to our system. Otherwise, the data flow is not shown on the DFD.

• A source/sink has a noun phrase label

Data Flow:

• A data flow has only one direction of flow between symbols. It may flow in both directions
between a process and a data store to show a read before an update. The latter is usually indicated;
however, by two separate arrows because these happen at different times.

• A fork in a data flow means that exactly the same data goes from a common location to
two or more different processes, data stores, or sources/sinks (this usually indicates different copies
of the same data going to different locations).

• A join in a data flow means that exactly the same data come from any of two or more different
processes, data stores, or sources/sinks to a common location.
• A data flow cannot go directly back to the same process it leaves. There must be at least one
other process that handles the data flow, produces some other data flow, and returns the original
data flow to the beginning process.

• A data flow to a data store means update (delete or change).

• A data flow from a data store means retrieve or use.

• A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single
arrow as long as all of the flows on the same arrow move together as one package.

7.21 What is decomposition? What is balancing? How can you determine if DFDs are not
balanced?

Answer :

Decomposition is the iterative process by which a system description is broken down into finer
and finer detail, creating a set of diagrams in which one process on a given diagram is explained
in greater detail on a lower-level diagram.

Balancing is the conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level.

You can determine if a set of DFDs are balanced or not by observing whether or not a process that
appears in a level-n diagram has the same inputs and outputs when decomposed for a lower-level
diagram.

7.22 Explain the convention for naming different levels of DFDs.

Answer :

The highest level DFD is called a context diagram. It represents the system as a single process,
with all the related entities and the data flows in and out of the system.

The next level diagram, called a level-O, decomposes the one process from the context diagram
into between two to nine high-level processes.
Each process in a level-O diagram can be decomposed if necessary. Each resulting diagram is
called a level-1.

Should processes in a level-1 diagram be decomposed, each resulting diagram would be called a
level-2 diagram. Each of these processes would be decomposed on a level-3 diagram, and so on.

7.23 Why do analysts draw multiple sets of DFDs?

Answer :

The various views, among others, process, logic, and data, of an information system each have
their own unique characteristics and provide the most relevant information to different information
system specialists.

This variety is best understood, expressed, and managed by using diagrams and documentation
that are specifically tailored for each view of the system.

As for example, data flow diagrams are useful for capturing the flow of data through business
processes, but they are not useful for describing the forms and relationships among data. As
information systems become larger and more complex, it becomes even more important to use the
right tool and technique to develop each component to an information system.

One technique that captured all aspects of an information system model on one diagram or in one
notation would likely be too complex for systems professionals to handle.

7.24 How can DFDs be used as analysis tools?

Answer :

DFDs can be used as analysis tools to help determine the completeness of a system model and a
model’s internal consistency, as a way to determine when system events occur through analyzing
timeliness, and through iterative use, to develop and check models. Analysts can study DFDs to
find excessive information handling, thus identifying areas for possible efficiencies.
7.25 Explain the guidelines for deciding when to stop decomposing DFDs.

Answer :

The guidelines for deciding when to stop decomposing DFDs are as follows:

1. Each process is a single decision or calculation or a single data base operation, such as retrieve,
update, create, delete, or read.

2. Each data store represents data about a single entity, such as a customer, employee, product, or
order.

3. The system user does not care to see any more detail to do subsequent systems development
tasks

4. Every data flow does not need to be split further to show that different data are handled in
different ways.

5. You believe that you have shown each business form or transaction, computer screen, and report
as a single data flow

6. You believe there is a separate process for each choice on all lowest-level menu options for the
systems.

7.26 How do you decide if a system component should be represented as a source/sink or as a

process?

Answer :

Sources and sinks as always outside of the system being considered. They are of interest to the
system being considered only because they represent sources of data coming into the system and
destinations for data leaving the system. If any data processing occurs inside a source or sink, it
should be of no interest to the system being modeled. If the processing is of interest, however, or
if the identified source/sink has several inputs and outputs to and from the rest of the system, it
may be better considered as an internal process.
7A.13. What are use cases?

Answer :

Use case is a depiction of a system’s behavior or functionality under various conditions as the
system responds to requests from users. A use case shows the behavior or functionality of a system.
It consists of a set of possible sequences of interactions between a system and a user in a particular
environment, possible sequences that are related to a particular goal. A use case describes the
behavior of a system under various conditions as the system responds to requests from principal
actors. A principal actor initiates a request of the system, related to a goal, and the system responds.
A use case can be stated as a present-tense verb phrase, containing the verb (what the system is
supposed to do) and the object of the verb (what the system is to act on). For example, use case
names would include Enter Sales Data, Compute Commission, Generate Quarterly Report.

7A.14.What is use case modeling?

Answer :

Use case modeling, featuring use case diagrams and written use cases, is another method you can
use to model business processes. Use cases focus on system functionality and business processes,
and they provide little, if any, information about how data flow through a system. In many ways,
use case modeling complements DFD modeling. The use case approach provides another tool for
analysts to use in structuring system requirements.

7A.15.What is a use case diagram?

Answer :

Use case diagram is a picture showing system behavior, along with the key actors that interact with
the system.
7A.17.Explain an include relationship

Answer :

Include relationship is An association between two use cases where one use case uses the
functionality contained in the other. An include relationship is shown diagrammatically as a
dotted-line arrow pointed toward the use case that is being used. The dotted-line arrow does not
indicate any kind of data or process flow between use cases. An include relationship implies that
the use case where the arrow originates uses the use case where the arrow ends while it is executing.
Typically, the use case that is “included” represents a generic function that is common to many
business functions. Rather than reproduce that functionality within every use case that needs it, the
functionality is factored out into a separate use case that can then be used by other use cases. An
example of an include relationship is shown in Figure 7-27.

7A.18.Explain an extend relationship.

Answer :

extend relationship is An association between two use cases where one adds new behaviors or
actions to the other. extend relationship extends a use case by adding new behaviors or actions. It
is shown as a dotted-line arrow pointing toward the use case that has been extended and labeled
with the <<extend>> symbol. The dotted-line arrow does not indicate any kind of data or process
flow between use cases. In Figure 7-26, for example, the Register for Special Class use case
extends the Register for Classes use case by capturing the additional actions that need to be
performed in registering a student for a special class. Registering for a special class requires prior
permission of the instructor, in addition to the other steps carried out for a regular registration. You
may think of Register for Classes as the basic course, which is always performed—independent of
whether the extension is performed or not—and Register for Special Class as an alternative course,
which is performed only under special circumstances.
7A.19 Compare DFDs with use case diagrams.
Answer :

Use case diagram using UML gives a more detailed view of the system ascompared to a DFD. Use
case diagram using UML is used in object oriented design and analysis unlike context diagram
using DFD which are used in structured analysis and design.

7C.6 Contrast the following terms (you will have to use what
you learned in the object-oriented sections of Chapters 7

and 8 to contrast all of these terms):

a. Actor; use case

b. Extends relationship; uses relationship

c. Object class; object

d. Attribute; operation

e. Operation; method

f. Query operation; update operation

g. Abstract class; concrete class

h. Class diagram; object diagram

i. Association; aggregation

Answer :

A. Actor : Actor in a use case diagram is any entity that performs a role in one given system.
This could be a person, organization or an external system and usually drawn like skeleton
shown below.

Use Case : A use case represents a function or an action within the system. It’s drawn as
an oval and named with the function.
B. Extended relationship : Extending relationships shows the relationship of a concrete use
case, usually an abstract use case that is used to provide functionalities from an abstract
use case in the implementation of certain ways.

Use Relationship : While extending relationship deficits, one use case extends specific
implementation or additional functionality, a generalization relationship defines a
relationship where the child can replace the parent without affecting the overall process to
the user. While extending relationship deficits, one use case extends specific
implementation or additional functionality, a generalization relationship defines a
relationship where the child can replace the parent without affecting the overall process to
the user.

C. Object class : A graph of objects that are compatible with a given class diagram

Object : Instances of a class or classes. Objects can be added to a class diagram to represent
either concrete or prototypical instances.

D. Atribute : An attribute of a class that specifies a value common to an entire class rather
than a specific value for an instance

Operation : Operation A function or a service that is provided by all the instances of a class.

E. Operation : Operation A function or a service that is provided by all the instances of a

class.

Methods : The implementation of an operation.

F. Query operation : An operation that accesses the state of an object but does not alter the
state.

update operation : An operation that alters the state of an object.

G. Abstract class : A class that has no direct instances but whose descendants may have
direct instances.

concrete class : A class that can have direct instances.

H. Class diagram : A diagram that shows the static structure of an object-oriented model:
the object classes, their internal structure, and the relationships in which they participate.
 object diagram : A graph of objects that are compatible with a given class diagram.

I. Association : A named relationship between or among object classes.

Aggregation : A part-of relationship between a component object and an aggregate object

7D.7 What is a business process? Why is business process diagramming important?

Answer :

Business Process Mapping can be used to document a current process and to model a new one. Its
purpose is to gain a detailed understanding of the process, people, inputs, controls and outputs, and
then potentially to simplify it all, make it more efficient and/or improve theprocess results.

The Importance of Business Processes. The need and the advantages of abusiness process are quite
apparent in large organizations. A process forms the lifeline for any business and helps it
streamline individual activities and make sure that resources are put to their optimum use.

7D.8 What is BPMN? Who is responsible for it?

Answer :

he Business Process Management Initiative (BPMI) has developed a standard Business Process
Modeling Notation (BPMN).

7D.9 List and defne the four main concepts that are part of BPMN

Answr :

There are four basic forms used to model business processes, namely Rounded Rectangle,
Diamond, Circle, and Line