CHAPTER 3

DESIGN AND
METHODOLOGY
 This chapter will present the strategy and procedures to be
undertaken in the development of the research project. The
following are expected the included in this chapter:
This is the part where students need the expert technical and
theoretical inputs. This is why the students need good advisers who
will teach them on:
• Correct systems analysis tools and techniques
• Correct and appropriate algorithms to use
• Appropriate usability tests
• Correct and appropriate hardware
• Appropriate software tools
 For system or customized software development, the following are the
suggested contents of this chapter. Order of presentation of these sections
should be arranged logically depending on the nature of the project:
Requirement Analysis – The narrative description of the design to achieve
your project objectives. This section will include the following:
o Status of the current situation, which may include present system used, the
people involved, the present facility, etc.
o The presentation of how the present system works will be necessary and
the concept can be illustrated in a graphical diagram to visually present the
structure and concepts.
Software Requirements Specifications - is a description of a software
system to be developed. It lays out functional and non-functional
requirements and may include a set of use cases that describe user
interactions that the software must provide.
oFunctional Requirements – for software development this will refers
to the specific functionality that define what the system is supposed to
accomplish. In some cases this section can also be termed as Requirement
Documentation.
oNon-Functional Requirements - specifies how the system should
behave and that it is a constraint upon the systems behavior. It is the
quality attributes for of a system.
• Constraints - Constraints are a limiting factor and severely restrict
options for making design decisions. They are also fixed design
decisions that cannot be changed and must be satisfied. You could
think of constraints as the ultimate non-negotiable, "must have“
requirement. The following are common non-functional
requirements that are considered constraints in software design
(not inclusive):
o User interface and human factors
o Documentation
o Hardware and/or Software considerations
o Performance characteristics
o Error handling and extreme conditions
o System interfacing
o Quality issues
o System modifications
o Physical environment
o Security issues
o Resources and management issues
o Trade-off - A trade-off (or tradeoff) is a situation that involves losing one
quality, aspect or amount of something in return for gaining another quality,
aspect or amount. In computer science, tradeoffs are viewed as a tool of the
trade. Tradeoffs are presented in a situation in which one must chose between a
balance two or more things (constraints) that are opposite or difficult to attain at
the same time (Lavina, 2016).
o Design of Software, Systems, Product and/or Processes (whichever is more
appropriate of the three) – this section will describe in detail how the proponents
will design the proposed system in accordance with the standards.
 The following components of System and Analysis can be part or subsections of this
section. Present and discuss only the system analysis and design tools that were actually
used in the development of the project
• Conceptual design
• Data Models
• System Architecture
• Block diagrams and algorithms (whichever will be most appropriate). It is important
that the methodology used is correct and appropriate from the start.
• Software Development Tools- It should contain the discussion about the programming
language tools to be used specifically on : front and Back-end; Reuse or not; Open vs.
Licensed software- Criteria for selection ,i.e. maintainability, support, HCI capability,
database connectivity, simplicity, eases of use, etc.
o The documentation of system analysis to actual deployment should include
presentations in the form of tables, figures, and other similar diagrams used in
either structured or object-oriented approach. These are the approaches and
procedures learned by the students in “System Analysis and Design” and in
“Software Engineering”.
o System implementation is the installation and delivery of the proposed system
to be conducted by the researchers/developers. It includes conversion and
integration plan, database installation, system testing, user training and other
production activities.
• Software Testing – This will describe the standards to be used in the software
testing the software. The standards to be used and tradeoffs involved in the
design choices can be included here.
o The Verification, Validation and Testing Plans will be included here that
will contain the plan of activities to: verify and validate if you are
developing the system right and test the system if it works correctly without
any bugs or errors. Most importantly, use of any quantitative and qualitative
measures should be planned in order to achieve the research projects specific
objectives
• System or Software Evaluation – If appropriate and applicable a survey
evaluation of the system or software can be included in this chapter. This section
will present the procedures on the conduct of the system or software evaluation.
The following should be included under this section:

oRespondents or evaluators of the system/software – they are usually

the IT Experts who are presumed to be knowledgeable with the system.
Other evaluators will depend on the kind of system/software, which
maybe composed of the actual users of the system or the client.
o Evaluation Standard or Criteria to be used – the standards or criteria to be
used in evaluating the system/software. Established standards for software
evaluation can be used like the ISO 9126. However, if the proponents will use
their own criteria, it should be passed through proper validation procedures that
will also be describe in this section. There are numbers of validated software
evaluation from previous studies, they can be utilized, however proper citation
or permission should be done.
o Data Analysis Plan and Rating Scale– Statistical tool to be used should also be
describe under this section The rating scale (i.e. Likert Scale) to be used in the
questionnaire should also be presented and explained.
o Methodology
Identification of objectives of the program, presentation, module, etc. and
method of delivery. Description of the project should detail what you did. The
reader should be able to replicate your project based on what is included in this
section. You should include the following:
• IRB approval and status (actual documents should be
included as an appendix. Your approval letter should
state whether you are exempt, expedited, full review0
• Type of study or research designed used
Data Flow Diagram
oWhat is a Data Flow Diagram?
A data flow diagram (DFD) is a graphical tool that allows system
analysts (and system users) to depict the flow of data in an information
system.
The DFD is one of the methods that system analysts use to collect
information necessary to determine information system requirements.
oWhat is a Data Flow Diagram?
A Data Flow Diagram is intended to serve as a communication tool
among
 systems analysts
 end users
 data base designers
 system programmers
 other members of the project team
oWhy Draw Data Flow Diagrams?
To clearly and concisely communicate the flow of data through a
system.
Why use a DFD and not just text?
“Since we previously had no way of showing a tangible model, we have had to
build the next best thing, which is to use English narrative to describe the proposed
system. Can you imagine spending five years’ salary on a custom built house on
the basis of an exhaustive narrative description of how the house will be built? ...
If you use English to describe a complex system... the result takes up so much
space that it’s hard for the reader to grasp how the parts fit together - (Gane and
Sarson, Structured System Analysis, 1974)
DFD’s are easier to understand than text.
 DFD Example 1 The Broadway
Entertainment Company

An important first step to consider is to look at the key processes

under study.
These can be itemized into a hierarchical series, where the
highest level (level 0) describes a general department, or business
unit, to the lowest level. The lowest level is a point where you
cannot break a process into any more divisible components. These
are referred to as functional primitives.17
 DFD: Adding Levels of Detail

• The highest level, called the context diagram, is only an overview. More
detail is typically needed for system analysts.
• We add detail to a DFD by creating “levels”. The first level added after the
context diagram is called level “0”.
• Each new level breaks apart one process and “decomposes” the single process
into a new, more detailed DFD.
• A complete DFD can have many (up to 6 or 7) levels depending on the
complexity of system.Breaking the DFD into levels is referred to as
“Decomposition”.