Scribd
Upload
75 views

IT-510 Module 4 Part Two

Decision tables and decision trees are tools used to visualize logical models and decompose business scenarios. A decision table lists conditions that could impact outcomes in a matrix. A decision tree represents the same information in a graphical format. Both tools help analysts understand complex systems but require practice to use effectively. Good documentation is important for analysts to capture decisions and justify design choices as a project progresses.

Uploaded by

petetg5172
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
75 views

IT-510 Module 4 Part Two

Decision tables and decision trees are tools used to visualize logical models and decompose business scenarios. A decision table lists conditions that could impact outcomes in a matrix. A decision tree represents the same information in a graphical format. Both tools help analysts understand complex systems but require practice to use effectively. Good documentation is important for analysts to capture decisions and justify design choices as a project progresses.

Uploaded by

petetg5172
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Decision Tables and Decision Trees

Decision tables and decision trees are additional tools


used to decompose and visualize the logical model. A
decision table is a great way to work through business
scenarios. The decision tree is an aide in visualizing the
decision table. In a decision table, a cross tab of condition
to outcome is created. A good systems analyst relies
heavily on this matrix. As the system complexity builds out,
the decision table matrix serves as a reference to quickly
assess an outcome. For smaller projects, an experienced
systems analyst can visualize the system complexities.
However, as a best practice, it is always good to
document.

The decision table lists the condition on the left as a row.


In practice, the row number uniquely identifies the
conditions for reference in the system analysis
documentation. The columns are the permutation of
possible outcomes. A column condition is marked as “Y” or
“N” in each permutation, or a “–” is used if the column
condition does not affect the outcome. Then, by evaluating
the Y/N/–combinations of a permutation column, an
outcome is determined. An outcome could be “Accept” or
“Reject,” or an outcome could be any number of other
business processes based on the result.

The decision tree is a representation of the condition,


outcome, and action, as defined in a decision table. The
use of the decision tree or decision table is a preference of
the analyst and will depend on the complexity of the
scenario being analyzed. A decision table is better suited
for a more complex analysis while a decision tree is
excellent for quick and simpler versions of the decision
table. The decision tree versus a decision table is similar
to a flow chart versus a DFD. Decision trees and flow
charts are best used in presentations and meetings.

The decision table and decision tree are challenging for a


systems analyst to initially learn. Decision tables need to
be practiced, as creating one can require a different type
of thinking than most new systems analysts are
comfortable with. With more practice and experience,
decision tables become a natural part of the systems
analyst thought process.

Documenting
Documenting tasks are something all methodologies
include, but projects shed as timelines compress. As a
systems analyst, documenting is one of the single most
important project tasks. A systems analyst’s role in a
project is to take a business concept from inception
through design, construction, and implementation. The
logical design is where the bulk of documentation occurs.
Consider that the DFDs, flow charts, and decision tables
are all a form of documentation. As a systems analyst
creates these documents, including thoughts as part of the
documentation brings context to the design and
information about the decisions made in the design. A
systems analyst manages so much information in a day,
week, and month that trying to remember every decision
and/or justification for performing a task in a certain way
does not work in the long run. A best practice is to take
good notes and document along the way.

The systems analyst must be diligent in note taking and


documentation during these modeling steps. Documenting
will make the rest of the systems analyst’s path to system
implementation much more manageable.

In Module Five, students will explore object oriented (OO)


design, which is an alternate method to structured design.
OO design is intended to accomplish the same outcome;
however, the method has different tools, techniques, and
approaches when compared to the more traditional
structured design focused on in Module Four.

You might also like