Hi everyone,

Let’s us wait for the others to join the meeting.

Start of class is on 8:20 am.

Mute your microphone/camera.

Thank you.
Prepared by: Ms. Sheila Mae L. Gunio
 How can I
validate
requirements?
 REQUIREMENT ANALYSIS
• Also known as “Requirements Engineering”
• It is the result in the specification of software’s operational characteristics,
indicates software’s interface with other system elements, and establishes
constraints that software must meet.
✓defining user expectations for a new software being built or
modified
✓encompasses those tasks that go into determining the needs or
conditions to meet for a new or altered product or project
✓taking account of the possibly conflicting requirements of the
various stakeholders
✓analyzing, documenting, validating and managing software or
system requirements.
 OBJECTIVES OF REQUIREMENT
ANALYSIS
FROM WHAT TO HOW

3 ORTHOGONAL VIEWS

SOFTWARE
ARCHITECTURE

ITERATIVE AND
INCREMENTAL PROCESS
• From What to How: Software engineering task bridging the gap between
system requirements engineering and software design.
• 3 Orthogonal Views: Provides software designer with a model of:
• system information (static view)
• function (functional view)
• behavior (dynamic view)
• Software Architecture: Model can be translated to data, architectural, and
component-level designs.
• Iterative and Incremental Process: Expect to do a little bit of design during
analysis and a little bit of analysis during design.
 TYPES OF REQUIREMENT
MODELLING
1. Scenario-based Model
2. Class-oriented Model
3. Data Model
4. Flow-Oriented Model
 1. SCENARIO-BASED MODEL
• Depicts how the user interacts with the system and the specific sequence of
activities that occur as the software use.
• This is a simple aid to define what exist outside the system (actors) and what should
be performed by the system .
• Use the use case or activity diagram.
• The requirements comes from the point of views of various system “actors”.
✓ System- application you are developing (represent by a rectangle).
✓Actors- a role played by a user or any other system that interacts with the
subject.
▪ Primary actor- also called the active actor; they initiate the use case and
independent.
▪ Secondary actor- also called the passive actor; used by the system but they
do not interact with the system on their own.
✓ Relationships-describes the interactions
between the system and actors in order to
achieve a goal for some stakeholders.
▪ Association- An actor must be associated
with at least one use case. An actor can be
associated with multiple use cases/multiple
actors can be associated with a single use
case.
▪ Include- a relationship in which one use case
(the base use case) includes the functionality
of another use case (the inclusion use case).
The include relationship supports the reuse of
functionality in a use-case model.
▪ Extend- specify that one use case (extension)
extends the behavior of another use case
(base). This type of relationship reveals details
about a system or application that are
typically hidden in a use case.
▪ Generalization- a relationship in which one
model element (the child) is based on
another model element (the parent).
✓ Use case- represent an action that
accomplishes the task within the system
(represent in oval shape)
 PARENT AND CHILD

PARENT
Payment

Customer

Pay from Pay from

CHILD Saving Current

New Customer Old Customer

 2. CLASS-ORIENTED MODEL
• Represent object-oriented class (attributes and operations) and the way
classes collaborate to achieve system requirements.
• A class-based model contains
✓ Objects: What the system will manipulate
✓ Operations (methods or services): What to be applied to the objects to affect
the manipulation
✓ Relationships (some hierarchical) between objects
✓ Collaborations between the classes that are defined
 3. DATA MODEL
• Depicts the information domain for the problem.
• Data modeling is the process of creating a simple diagram of a complex
software system, using text and symbols to represent the way data will flow.
• Phases:
• Conceptual model: describe WHAT the system contains. Set of square
shapes (entities) connected by a line (relationship of each entities).
• Logical model: describe HOW the system will be implemented
(regardless of the DBMS)
• Physical model: describe the HOW the system will be implemented
using specific DBMS
 3. DATA MODEL
• Depicts the information domain for the problem.
Key attribute
• Data modeling is the process of creating a simple diagram of a complex
software system, using text and symbols to represent the way data will flow. Non-Key
attributes
• Phases:
• Conceptual model: describe WHAT the system contains. Set of square
shapes (entities) connected by a line (relationship of each entities).
• Logical model: describe HOW the system will be implemented
(regardless of the DBMS). This expands the conceptual model by
adding more detail to it.
• Key attribute: define the uniqueness of the entities
• Non-key attribute-not unique and give additional information about the
entity
• Physical model: describe the HOW the system will be implemented
using specific DBMS
 3. DATA MODEL
• Depicts the information domain for the problem.
• Data modeling is the process of creating a simple diagram of a complex
software system, using text and symbols to represent the way data will flow.
• Phases:
• Conceptual model: describe WHAT the system contains. Set of square
shapes (entities) connected by a line (relationship of each entities).
• Logical model: describe HOW the system will be implemented
(regardless of the DBMS). This expands the conceptual model by
adding more detail to it.
• Key attribute: define the uniqueness of the entities
• Non-key attribute-not unique and give additional information about the
entity
• Physical model: describe the HOW the system will be implemented
using specific DBMS (specify to database)
• Entities- tables
• Attributes- columns
• Specify the data types
“what can you see about the names of each columns- they are compatible to
what?”
 4. FLOW-ORIENTED MODEL
• Represent the functional elements of
the system and how they transform
data as they move through the system.
• Focuses on the flow of information
where data comes from where it goes
and where it is stored.
• Use the DFD (Data Flow Diagram)
• It is a graphical technique that depicts
information flow and transforms that are
applied as data from input to output.
 REQUIREMENTS
MODEL AS A
BRIDGE BETWEEN
THE SYSTEM
DESCRIPTION AND
THE DESIGN MODEL
 OVERALL OBJECTIVES AND
PHILOSOPHY
• Requirement modelling primary focus is on WHAT, not HOW.
? What user interaction occurs in a particular circumstance
? what objects does the system manipulate
? what functions must the system perform
? what behaviors does the system exhibit
? what interfaces are defined
? what constraints apply
• The requirements model must achieve three primary objectives:
✓ to describe what the customer requires
✓ to establish a basis for the creation of a software design,
✓ to define a set of requirements that can be validated once the software is built.
 ANALYSIS RULES OF THUMB
• The model should focus on requirements that are visible within the problem
or business domain. The level of abstraction should be relatively high. "Don't
get bogged down in details” that try to explain how the system will work.
• Each element of the requirements model should add to an overall
understanding of software requirements and provide insight into the
information domain, function, and behavior of the system.
• Be certain that the requirements model provides value to all stakeholders.
Each constituency has its own use for the model.
• Keep the model as simple as it can be. Don't create additional diagrams
when they add no new information. Don’t use complex notational forms,
when a simple list will do.
 ASSIGNMENT
1. What is the purpose of requirement model?
2. It is possible to begin coding immediately after a requirement model has
been created? Explain your answer.
3. An analysis rule of thumb is that the model “should focus on requirements
that re visible within the problem or business domain”. What types of
requirements are NOT visible in these domain? Explain a few examples.
-Reminder:
Quiz on October 21, 2021 (Thursday)