Lecture 12 requirements modeling - (system analysis)

Introduction to Software Engineering
Muhammad Nasir
Requirements Modeling
(System Analysis)
m.nasir@iiu.edu.pk

Agenda
 Requirement Analysis
 Scenario-based Models
 Data Models
 Class-oriented Models
 Flow-Oriented Models
 Behavioral Models

Requirement Modeling
 Software engineering begins with a
series of modeling tasks
 that lead to a specification of
requirements and a design
representation for the software to be
built.
 The requirements model actually a
set of models—is the first technical
representation of a system

 Requirements analysis results in the
specification of software’s operational
characteristics, indicates software’s
interface with other system elements,
and establishes constraints that
software must meet.

 The requirements modeling action results in
one or more of the following types of models:
 Scenario-based Models of requirements from
the point of view of various system “actors”
 Data Models that depict the information domain
for the problem

 Class-oriented Models that represent object-oriented
classes (attributes and operations) and the
manner in which classes collaborate to achieve
system requirements
 Flow-oriented Models that represent the functional
elements of the system and how they transform
data as it moves through the system
 Behavioral Models that depict how the software
behaves as a consequence of external “events”

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.
 Each element of the analysis model should add to
an overall understanding of software requirements
and provide insight into the information domain,
function and behavior of the system.
 Delay consideration of infrastructure and other non-functional
models until design.

Analysis Rules of Thumb
 Minimize coupling throughout the system. - If level
of interconnectedness is high, efforts should be
made to reduce it.
 Assured that the analysis model provides value to all
stakeholders. – business stakeholder should validate
requirement, Designers should use the model as a
basis for design.
 Keep the model as simple as it can be. - No need to
use additional diagram and use notations.

Domain Analysis
 In the discussion of requirements engineering (Chapter
5), It can be observed that analysis patterns often
reoccur across many applications within a specific
business domain.
 If these patterns are defined and categorized in a
manner that allows you to recognize and apply them to
solve common problems, the creation of the analysis
model is expedited.
 More important, the likelihood of applying design
patterns and executable software components grows
dramatically.
 This improves time-to-market and reduces
development costs.

Domain Analysis
 “Software domain analysis is the
identification, analysis, and specification of
common requirements from a specific
application domain, typically for reuse on
multiple projects within that application
domain. . . .”

Domain Analysis
 [Object-oriented domain analysis is]
the identification, analysis, and
specification of common, reusable
capabilities within a specific
application domain, in terms of
common objects, classes,
subassemblies, and frameworks…

Scenario-based Modeling
 Use cases develops the understanding
that how the system would be used.
 Hence, requirements modeling with
UML begins with the creation of
scenarios in the form of use cases,
activity diagrams, and swimlane
diagrams.

Scenario-based Modeling
 In general, use cases are written first
in an informal narrative fashion.
 If more formality is required, the same
use case is rewritten using a
structured format

Writing Preliminary Use-Cases
 In SafeHome Example a Home owner
might interact in following way
 Select camera to view.
 Request thumbnails from all cameras.
 Display camera views in a PC window.
 Control pan and zoom for a specific camera.
 Selectively record camera output.
 Replay camera output.
 Access camera surveillance via the Internet.

Preliminary Use-Case
Diagram for SafeHome

The End
 Thanks for listening
 Questions would be appreciated.

Lecture 12 requirements modeling - (system analysis)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Lecture 12 requirements modeling - (system analysis)

Similar to Lecture 12 requirements modeling - (system analysis) (20)

More from IIUI

More from IIUI (20)

Recently uploaded

Recently uploaded (20)

Lecture 12 requirements modeling - (system analysis)

Editor's Notes