“REQUIREMENTS DETERMINATION”

Requirements Determination

▪ This is an essential feature of developing a new system which may

contain processing or gathering of data, handling the activities of
business, producing information and supporting the management.
▪ Requirements determination includes examining the existing system
and gathering details to find out how it works, what are the
requirements and where improvements should be made.
Major Activities in Requirement Determination
▪ Requirements Anticipation - It predicts the characteristics of system
based on previous experience which include certain problems or
features and requirements for a new system.

▪ Requirements Investigation - It is studying the current system and

documenting its features for further analysis.

▪ Requirements Specifications - It includes the analysis of data which

determine the requirement specification, description of features for
new system, and specifying what information requirements will be
provided.
Requirements-Gathering Techniques
▪ Before the start of the development, determining what are the tasks
to be performed come at first. These tasks may have none or one or
more related techniques. A technique should be related to at least
one task.
 “Brainstorming’’
Brainstorming is used in
requirement gathering to get
as many ideas as possible
from group of people.
Generally used to identify
possible solutions to
problems, and clarify details
of opportunities.
“Document Analysis”

Reviewing the documentation

of an existing system can help
when creating AS–IS process
document, as well as driving
gap analysis for scoping of
migration projects.
 “Focus Group”
A focus group is a gathering of
people who are
representative of the users or
customers of a product to get
feedback.
“Interface analysis”
Interfaces for a software
product can be human or
machine. Integration with
external systems and devices
is just another interface. User
centric design approaches are
very effective at making sure
that we create usable
software.
 “Interview”
Interviews of stakeholders
and users are critical to
creating the great software.
Without understanding the
goals and expectations of the
users and stakeholders, we
are very unlikely to satisfy
them.
 “Observation”
By observing users, an analyst
can identify a process flow,
steps, pain points and
opportunities for
improvement. Observations
can be passive or active
(asking questions while
observing).
 “Prototyping”
Prototyping is a relatively
modern technique for
gathering requirements. In
this approach, you gather
preliminary requirements that
you use to build an initial
version of the solution
 “Requirement
Workshops”
Workshops can be very effective for
gathering requirements. More
structured than a brainstorming
session, involved parties collaborate
to document requirements. One way
to capture the collaboration is with
creation of domain-model artifacts
(like static diagrams, activity
diagrams). A workshop will be more
effective with two analysts than with
one.
“Reverse Engineering”
When a migration project does not
have access to sufficient
documentation of the existing
system, reverse engineering will
identify what the system does. It
will not identify what the system
should do, and will not identify
when the system does the wrong
thing.
“Survey/Questionnaire”
When collecting information from
many people – too many to
interview with budget and time
constraints – a survey or
questionnaire can be used. The
survey can force users to select
from choices, rate something
(“Agree Strongly, agree…”), or have
open ended questions allowing
free-form responses.
Requirements Analysis
▪ Before the project team can determine what requirements are
appropriate for a given system, there needs to be a clear vision of the
kind of system that will be created and the level of change that it will
bring to the organization.
▪ Requirements analysis strategies help the analyst lead users through
the analysis steps so that the vision of the system can be developed.
Requirements Analysis Strategies

▪ Problem Analysis ▪ Root Cause Analysis

-Problem analysis means asking -Sometimes the solutions is
the users and managers to suitable, but most of the time
identify problems with the as-is it’s just addressing a symptom
system and to describe how to of the problem, not the root
solve them in the to-be system. cause itself.
Requirements Analysis Strategies
▪ Duration Analysis ▪ Activity-Based Costing
-This requires a detailed -This is a similar analysis; it
examination of the amount of examines the cost of each major
time it takes to perform each process or step in a business
process in the current as-is process rather than the time
system. taken. The analysts identify the
costs associated with each of the
basic functional steps or
processes, identify the most costly
processes, and focus their
improvement eff orts on them.
Requirements Analysis Strategies
▪ Informal Benchmarking ▪ Outcome Analysis
-It refers to studying how other -With this approach, system
organizations perform a analysts encourage the managers
business process in order to and project sponsor to pretend
learn how your organization can they are customers and to think
do something better carefully about what the
organization’s products and
services enable the customers to
do—and what they could enable
the customer to do.
Requirements Analysis Strategies
▪ Technology Analysis ▪ Activity Elimination
-Analysts and managers create a -The analysts and managers
list of important technologies work together to identify how
and then group identifies how a the organization could eliminate
certain technology could each activity in the business
applied to the business and how process, how the function could
the business would benefit. operate without it, and what
effects are likely to occur.
Modeling with Unified Modeling Language (UML)

▪ A standard set of diagramming techniques. The objectives of UML are

to create a common vocabulary of object-oriented terms and
diagramming techniques. Grady Booch, Ivar Jacobson, and James
Rumbaugh, these three people was the ones who worked together to
create Unified Modeling Language.
Structure diagrams
▪ show the static structure of the system and its parts on different
abstraction and implementation levels and how they are related to
each other.
Type of Structure diagrams Description
1. Class Diagram is a UML diagram type that describes a
system by visualizing the different types of
objects within a system and the kinds of
static relationships that exist among them. 
2. Component Diagram A component diagram, also known as a
UML component diagram, describes the
organization and wiring of the physical
components in a system
3. Deployment Diagram A deployment diagram is a UML diagram
type that shows the execution architecture
of a system, including nodes such as
hardware or software execution
environments, and the middleware
connecting them. 
Type of Structure diagrams Description
4. Object Diagram An object diagram is a graph of instances,
including objects and data values
5. Package Diagram structural diagrams used to show the
organization and arrangement of various
model elements in the form of packages.
6. Composite Structure Diagram a composite structure diagram depicts
the internal structure of structured
classifiers by using parts, ports, and
connectors. 

7. Profile Diagram A Profile diagram is any diagram created

in a «profile» Package.
Class Diagram
▪ The class diagram is a central
modeling technique that runs
through nearly all object-oriented
methods. This diagram describes ▪ Association - represent
the types of objects in the system relationships between instances of
and various kinds of static types (a person works for a
relationships which exist between company; a company has a number
them. of offices.
▪ Inheritance - the most obvious
addition to ER diagrams for use in
OO. It has an immediate
correspondence to inheritance in
OO design.
▪ Aggregation-Aggregation, a form of
object composition in object-
oriented design.
Behavior diagrams
▪ show the dynamic behavior of the Types of Behavior diagrams
objects in a system, which can be
described as a series of changes to ▪ Use Case Diagram
the system over time, there are ▪ Activity Diagram
seven types of behavior diagrams
as follows: ▪ State Machine Diagram
▪ Sequence Diagram
▪ Communication Diagram
▪ Interaction Overview Diagram
▪ Timing Diagram