REQUIREMENTS MODELING

 REQUIREMENTS
MODELING
 involves fact-finding to describe the current system and
identification of the requirements for the new system, such as
outputs, inputs, processes, performance, and security.

 Outputs refer to electronic or printed information produced

by the system.

 Inputs refer to necessary data that enters the system, either

manually or in an automated manner.
 Processes refer to the logical rules that are applied to
transform the data into meaningful information.

 Performance refers to system characteristics such as speed,

volume, capacity, availability, and reliability.

 Security refers to hardware, software, and procedural

controls that safeguard and protect the system and its data
from internal or external threats.
 DATA AND PROCESS MODELING
 represent graphically system data and processes using
traditional structured analysis techniques

 structured analysis identifies the data flowing into a process,

the business rules that transform the data, and the resulting
output data flow.
 OBJECT MODELING
 combines data and the processes that act on the data into
things called objects. These objects represent actual people,
things, transactions, and events that affect the system.
 DEVELOPMENT STRATEGIES
 consider various development options and prepare for the
transition to the systems design phase of the SDLC. You will learn
about software trends, acquisition and development alternatives,
outsourcing, and formally documenting requirements for the new
system. The deliverable, or end product, of the systems analysis
phase is a system requirements document, which is an overall
design for the new system. In addition, each activity within the
systems analysis phase has an end product and one or more
milestones.
Analytical skills enable you to identify a problem, evaluate the key
elements, and develop a useful solution.

Interpersonal skills are especially valuable to a systems analyst

who must work with people at all organizational levels, balance
conflicting needs of users, and communicate effectively. Because
information systems affect people throughout the company, you
should consider team-oriented strategies as you begin the
systems analysis phase.
METHODS IN DEVELOPING SYSTEM

JOINT APPLICATION DEVELOPMENT (JAD)

RAPID APPLICATION DEVELOPMENT (RAD)
AGILE METHOD
JOINT APPLICATION DEVELOPMENT
 is a popular fact-finding technique that brings users into the
development process as active participants.
RAPID APPLICATION DEVELOPMENT
 is a team-based technique that speeds up information
systems development and produces a functioning information
system. Like JAD, RAD uses a group approach, but goes much
further. While the end product of JAD is a requirements
model, the end product of RAD is the new information
system. RAD is a complete methodology, with a four-phase life
cycle that parallels the traditional SDLC phases. Companies
use RAD to reduce cost and development time, and increase
the probability of success.
 The RAD process allows users to examine a working model as
early as possible, determine if it meets their needs, and
suggest necessary changes.
 REQUIREMENTS PLANNING - The requirements planning
phase combines elements of the systems planning and
systems analysis phases of the SDLC. Users, managers, and IT
staff members discuss and agree on business needs, project
scope, constraints, and system requirements. The
requirements planning phase ends when the team agrees on
the key issues and obtains management authorization to
continue.
 USER DESIGN During the user design phase, users interact
with systems analysts and develop models and prototypes
that represent all system processes, outputs, and inputs. The
RAD group or subgroups typically use a combination of JAD
techniques and CASE tools to translate user needs into
working models. User design is a continuous, interactive
process that allows users to understand, modify, and
eventually approve a working model of the system that meets
their needs.
 CONSTRUCTION The construction phase focuses on program
and application development tasks similar to the SDLC. In
RAD, however, users continue to participate and still can
suggest changes or improvements as actual screens or reports
are developed.

 CUTOVER The cutover phase resembles the final tasks in the

SDLC implementation phase, including data conversion,
testing, changeover to the new system, and user training.
Compared with traditional methods, the entire process is
compressed. As a result, the new system is built, delivered,
and placed in operation much sooner.
 RAD OBJECTIVES
 The main objective of all RAD approaches is to cut
development time and expense by involving users in every
phase of systems development. Because it is a continuous
process, RAD allows the development team to make
necessary modifications quickly, as the design evolves. In
times of tight corporate budgets, it is especially important to
limit the cost of changes that typically occur in a long,
drawn-out development schedule.
 RAD Advantages and Disadvantages
 The primary advantage is that systems can be developed more
quickly with significant cost savings. A disadvantage is that RAD
stresses the mechanics of the system itself and does not
emphasize the company’s strategic business needs. The risk is
that a system might work well in the short term, but the
corporate and long-term objectives for the system might not be
met. Another potential disadvantage is that the accelerated time
cycle might allow less time to develop quality, consistency, and
design standards.
AGILE METHOD
 The Agilian modeling toolset includes support for many
modeling tools, such as the Unified Modeling Language,
entity-relationship diagrams, data flow diagrams, and business
process modeling, among others.
 Functional Decomposition Diagrams (FDD)
 is a topdown representation of a function or process. Using an
FDD, an analyst can show business functions and break them
down into lower-level functions and processes.

 During requirements modeling, analysts use FDDs to model

business functions and show how they are organized into lower-
level processes. Those processes translate into program modules
during application development.
Functional Decomposition Diagram (FDD)
  Business Process Modeling
 business process model (BPM) describes one or more business
processes, such as handling an airline reservation, filling a product
order, or updating a customer account. During requirements
modeling, analysts often create models that use a standard
language called business process modeling notation (BPMN).
BPMN includes various shapes and symbols to represent events,
processes, and workflows.
  Business Process Modeling
 the overall diagram is called a pool, and the designated customer
areas are called swim lanes
  Business Process Modeling
 the overall diagram is called a pool, and the designated customer
areas are called swim lanes
 Business Process Modeling
  Data Flow Diagrams
 A data flow diagram shows the way information flows through a
process or system. It includes data inputs and outputs, data stores,
and the various sub-processes the data moves through. DFDs are
built using standardized symbols and notation to describe various
entities and their relationships.
  USE CASE DIAGRAMS
 A use case diagram visually represents the interaction between
users and the information system. In a use case diagram, the user
becomes an actor, with a specific role that describes how he or she
interacts with the system.
 USE CASE DIAGRAMS
  SEQUENCE DIAGRAM
 A sequence diagram shows the timing of interactions between
objects as they occur. A systems analyst might use a sequence
diagram to show all possible outcomes, or focus on a single
scenario.
CAGAYAN STATE UNIVERSITY – GONZAGA CAMPUS

THANK YOU !