Chapter 6

Software Analysis
and Design Tools
Malasmas, Antonio Jr
IT31
 Software Analysis and Design Tools

Its form was readable to

humans. Even a person who
was not on the field of
technology can understand it Benefits
It was used to serves as a Can easily able to
convert into actual
guide to transform code.
requirements specification to
implementation
 Requirements specification

Functional Non-Functional
It was not related to the
It was related to the system functionality but
system functionality. it defines how it should

perform.
Example: Button feature

Example: Should hear a

sound when you click a
button
 Data Flow Diagram (DFD)

It was a graph that represent the flow of

data in the system. It represent the in and
out of data flow and stored data but does
not mention how the data flows throughout
the system.
 Difference between DFD and Flowchart

DFD Flowchart

01 DFD never show unnamed data

flow
01 Flowchart shows arrows without
labels or description

02 DFD only shows important steps

02 Flowchart descriptively shows
steps
 Two main types of DFD notation

Yourdon and Gane & Sarson

Coad
 DFD Components

Entity - It was the source of the data and

the destination of the information data.
Process - an activity or action.
Data Store - it refers to the accumulate
data that need to process.
Data Flow - represents as a movement of
data.
 Levels of DFD

Level 0 - it's also known as context level DFDs and the most abstract
level in DFD because it doesn't show the underlying details
Level 1 - This level occur when the level 0 is broken down. It shows the
basic process and modules of the system.
Level 2 - This level occur when the level 1 is broken down. It was the
more descriptive than the other previous level.
 Structure Charts

It represents the structures of modules. It

was more detailed than DFD since it was
derived from it.
 Symbols in Structure Charts

Module - it represent the process or task. There are three parts:

Control module - it branches to more than one sub-module.
Sub-module - it was child of module of another module.
Library module - it can be callable or reusable from any module.
 Symbols in Structure Charts

Condinational call - it was the diamonds symbols. It

indicates that control module can select from any
sub-module below.
 Symbols in Structure Charts

Loop - the curved arrow here represents the loop in the control
module which means all of the sub-module that covered by loop
needs to repeat the execution in control module.
 Symbols in Structure Charts

Data flow - below it was the arrow with empty circle.

 Symbols in Structure Charts

Control flow - below it was the arrow with filled circle.

 Hierarchical Input Process
Output (HIPO)
It organize the software system module into hierarchy. It was
very useful in documentation because it can provide better
visualization on the idea of system structure.
 Difference and similarities
between HIPO and IPO

HIPO unlike IPO it doesn't shows any data flow or control flow.
Both of them are used for documentation and structure design
for software program.
 Structured English

It only uses plain English words but it shows

what should be code and how to code it. It
helps the programmer to lessen or prevent
an error when coding. We also need to keep
in mind that structured english is
independent to programming language.
Structured English Example
 Pseudo-Code

Compare to structured english it contains

programming details and written close to
programming language.
 Pseudo-Code Example

Write pseudo code that reads in three numbers and writes them all in
sorted order.
 Decision Table

Decision table are in tabular format where there are a multiple

rule with an actions that resulting in suitable outputs
 Entity-Relationship Model

ER Model is used in database it has a real world entity and

relationship.
 Entity-Relationship Model

Entity - it is real world being and contains an attribute.

Relationship - it is the relation among entities. It can be map in
various ways and can be differentiate in the number of
association between the two entities.

List of mapping cardinalities

1. One to one
2. One to many
3. Many to one
4. Many to many
 Data Dictionary

It was used in database and it was a collection of names, attributes

and etc that your database will use.
Thank You
Chapter 7
Capturing the
Requirements
Malasmas, Antonio Jr
IT31
 Software Requirements

It was the features and the functionality in a descriptive manner

of the system. It depends on the user, stakeholders, or the client
what kinds of requirements they want.
 Requirements Engineering

It is the process on how you are going to gather the requirements

from your user, stakeholders, or client.

It has 4 steps:
1. Feasibility Study
2. Requirements gathering
3. Software Requirements Specification
4. Software Requirements Validation
 Feasibility Study

Feasibility tackles the questions how easy or hard the system or

the requirements can be accomplished. This phase have an output
called feasibility study report where it should have a comments,
suggestions, and recommendations whether the project should
continue or not.
 Requirements Gathering

In this phase communication was important because you

want to know from your client, user, or stakeholders what
should the system provide or what feature it contains or
should not have.
 Software Requirements
Specification(SRS)
In this phase the system analyst plays a bigger role because after
the requirements gathering the system analyst will going to
determine how the system will interact to the devices, security,
limitations, quality etc. The system analyst should make a report in
understandable manner to be able to comprehend by the user,
stakeholders, and the client. The GUI, the sample prototype, and
natural language are good practice that needs to be considered.
 Software Requirements
Validation

In this phase the software requirements

specification(SRS) are validated. This phase
was crucial because if it validate without
extensive review the problem will occur
 Software Requirements
Specification(SRS)
In this phase the system analyst plays a bigger role because after
the requirements gathering the system analyst will going to
determine how the system will interact to the devices, security,
limitations, quality etc. The system analyst should make a report in
understandable manner to be able to comprehend by the user,
stakeholders, and the client. The GUI, the sample prototype, and
natural language are good practice that needs to be considered.
Requirements Elicitation Process
 Requirements Elicitation Process

In the diagram we have:

Requirements gathering - it will coming from the user,
stakeholders, and client.
Requirements Organization - it is the sorting of the task from
most important to least significant.
Requirements negotitation - the stakeholders and the developer
will going to have a conversation on what changes will happen to
make the system feasible.
 Requirements Elicitation
Techniques

It was the process on how are you going to get the

requirements that your system need. There are various
ways to get the requirements.

1. Interviews whether oral or written

2. Surveys
3. Questionnaires
4. Task Analysis
 Requirements Elicitation
Techniques

5. Domain Analysis
6. Brainstorming
7. Prototyping
8. Observation
 Software Requirements
Characteristics
Since it software requirements are guide to develop the system it
should be in a positive manner. It must be:
1. Clear 9. Credible Source
2. Concise 10. Traceable
3. Consistent 11. Modifiable
4. Coherent
5. Comprehensible
6. Verifiable
7. Prioritized
8. Tracede
 Two Categories of Software
Requirements
1. Functional - it tackles the functionality of the system. Example:
There are search option that is given to the user.
Non-Functional - it tackles the characteristics of software. Example:
Security, Storage, Cost, Flexibility, etc.

Requirements are can also be categorize logically:

I. Must have - It is the most important to possess.
II. Should have - To improve the system.
III. Could have - The potential requirements for the system.
IV. Wish list - It can be take into consideration but does not
necessarily include in mapping the objectives.
 User Interface Requirements

It is the design of the system it is widely accepted if it is

easy to operate, quick to response, effectively handling
the errors, consistent interface. It is the only way the
user will going to visualize the system. That's why it is
important to be clear, consistent, attractive, and
responsive.
 Software System Analyst

It is responsible for analyzing the

requirements of the system and whether the
system is realistic to make it doable and it is
important for them to equip with knowledge. It
is also the responsible to ensure that the user
requirements will be accomplished.
 Software Metric and Measures

It tackles the measurement of the requirements and

various aspect of software process and software
product.

Some software metrics:

Size Metrics - Lines of codes
Function Point Count - it is the count of how many
funcationality your system possess.
 Software Metric and Measures

Complexity Metrics - use to measure the maintainability

and realibility of the system.
Quality Metrics - tackles the defect, severity, etc. to
know the quality of the product.
Process Metrics - tackles the development process
used in the system Example: SDLC
Resource Metrics - tackles the effort, money, time and
other resources use.
Thank You
Chapter 9
Formal
Specification
Malasmas, Antonio Jr
IT31
 Specification in Software
Process

Design and Specification are very imposible to

seperate. Since design are important to create a
specification.
Formal Specification are expressed in
mathematical notation with accurate vocabulary,
and syntax.
Specification and Design
Specification in Software
Process
 Why aren't formal methods used

It is hard to show the advantages of formal specification

in an objective way.
Many software engineering are not train or lack the
training in discrete math for necessary formal
specification.
System customers may be unwilling to fund specification
activities
There is a widespread ignorance of the applicability of
formal specification
 Advantage of Formal
Specification
It can provide an insight into software requirements and
the design.
It can use to analyzed mathematically to demonstrate
consistency and completeness of the specification.
With a used of mathematics it can be possible to prove
the implementation corresponds to specification.
 The reason why aren't formal
methods used
Formal specifications techniques can't fit or cope
effectively with graphical user interface specification.
Other successful software engineering are investing on
other methods that may be cost effective.
Development cost with formal
specification
Thank You