Requirements Modeling

Requirements Analysis
The requirements modelling 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.”
• Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes
collaborate to achieve system requirements.
• Behavioural and patterns-based models that depict how the
software behaves as a consequence of external “events.”
• Data models that depict the information domain for the
problem.
• Flow-oriented models that represent the functional elements
of the system and how they transform data as they move
through the system.
• The requirements model must achieve three
primary objectives:
(1) to describe what the customer requires,
(2) to establish a basis for the creation of a
software design, and
(3) to define a set of requirements that can be
validated once the software is built.
The requirements model as a bridge between
the system description and the design model
 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 requirements model should add to an
overall understanding of software requirements and provide
insight into the information domain, function, and behaviour
of the system.
• Delay consideration of infrastructure and other non-
functional models until design.
Cont……

• Minimize coupling throughout the system. It is important to

represent relationships between classes and functions.
• Be certain that the requirements model provides value to all
stakeholders. Each constituency has its own use for the
model. For example, business stakeholders should use the
model to validate requirements; designers should use the
model as a basis for design; QA people should use the model
to help plan acceptance tests.
• Keep the model as simple as it can be. Don’t add additional
diagrams when they add no new information. Don’t use
complex notational forms when a simple list will do.
 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
• 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.
Input and output for domain analysis
Elements of the analysis model
 DATA MODELING CONCEPTS

• Data Objects
• Data Attributes
• Relationships

10
Dr. K. K. Baseer [Link]
 Cont..
Data Objects
A data object is a representation of composite information
that must be understood by software.
• A data object can be an external entity (e.g., anything
that produces or consumes information)
• a thing (e.g., a report or a display)
• an occurrence (e.g., a telephone call) or
• event (e.g., an alarm)
• a role (e.g., salesperson)
• an organizational unit (e.g., accounting department),
a place (e.g., a warehouse), or a structure (e.g., a
file).

11
Dr. K. K. Baseer [Link]
 Cont..

Figure. Tabular representation of data objects

12
Dr. K. K. Baseer [Link]
 Cont..

Data Attributes
Data attributes define the properties of a data object and take
on one of three different characteristics. They can be used to
(1) name an instance of the data object
(2) Describe the instance or
(3) make reference to another instance in another table.

13
Dr. K. K. Baseer [Link]
 Cont..
Relationships
• Data objects are connected to one another in different ways.

Figure. Relationships between data objects

14
Dr. K. K. Baseer [Link]
 Flow Oriented Modelling
• It represents how data objects are
transformed at they move through the system.
• DFDs describe the flow of data or information
into and out of a system
what does the system do to the data?
• A DFD is a graphic representation of the flow
of data or information through a system
DFD for SafeHome system
 SCENARIO-BASED MODELING
(1) what to write about,
(2) how much to write about it,
(3) how detailed to make your description, and
(4) ) how to organize the description?
These are the questions that must be answered
if use cases are to provide value as a
requirements modeling tool
 The SafeHome home surveillance function
that are performed by the homeowner actor:
• 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.
 Use case: Access camera surveillance via the
Internet—display camera views
Actor: homeowner
1. The homeowner logs onto the SafeHome Products website.
2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight
characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major
function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
 Refining a Preliminary Use Case
Therefore, each step in the primary scenario is
evaluated by asking the following questions
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error
condition at this point? If so, what might it be?
• Is it possible that the actor will encounter some other
behavior at this point (e.g., behavior that is invoked
by some event outside the actor’s control)? If so,
what might it be?
Preliminary use case diagram for the
SafeHome system
 UML MODELS THAT SUPPLEMENT THE USE
CASE
There are many requirements modeling
situations in which a text-based model— even
one as simple as a use case—may not impart
information in a clear and concise manner. In
such cases, you can choose from a broad array
of UML graphical models.
• Developing an Activity Diagram
• Swimlane Diagrams
Activity diagram for Access camera surveillance via the Internet— display
camera views function.
Swimlane diagram for Access camera surveillance via the Internet—display camera
views function.
 Case study on Requirements modeling for Web and
MobileApps

 How Much Analysis Is Enough?

 Requirements Modeling Input
 Requirements Modeling Output
 Content Model
 Interaction Model for Web and Mobile Apps
 Functional Model
 Configuration Models for WebApps
 Navigation Modeling

28
Dr. K. K. Baseer [Link]
 Cont..
How Much Analysis Is Enough?

1. The size and complexity of the application increment

2. The number of stakeholders (analysis can help to identify
conflicting requirements coming from different sources)
3. The size of the app development team
4. The degree to which members of the team have worked
together before (analysis can help develop a common
understanding of the project), and
5. The degree to which the organization’s success is directly
dependent on the success of the application.

29
Dr. K. K. Baseer [Link]
 Cont..
Requirements Modeling Input

 The inputs to the requirements model will be the information

collected during the communication activity—anything from an
informal e-mail to a detailed project brief complete with
comprehensive usage scenarios and product specifications.

 This information is represented in the form of natural

language descriptions, rough outlines, sketches, and
other informal representations.

30
Dr. K. K. Baseer [Link]
 Cont..
Requirements Modeling Output
There are five main classes of models:
1. Content model —identifies the full spectrum of content to be
provided by the application. Content includes text, graphics and
images, video, and audio data.
2. Interaction model —describes the manner in which users interact
with the app.
3. Functional model —defines the operations that will be applied to
manipulate content and describes other processing functions that
are independent of content but necessary to the end user.
4. Navigation model —defines the overall navigation strategy for the
app.
5. Configuration model —describes the environment and
infrastructure in which the app resides.

31
Dr. K. K. Baseer [Link]
 Cont..

Content Model
• The content model contains structural elements that
provide an important view of content requirements for an
application.

• These structural elements encompass content objects and

all analysis classes—user-visible entities that are created or
manipulated as a user interacts with the app through a
browser or a mobile device.

32
Dr. K. K. Baseer [Link]
 Cont..

Figure. Data tree for a [Link]

component

33
Dr. K. K. Baseer [Link]
 Cont..

Interaction Model for Web and Mobile Apps

 The vast majority of Web and mobile apps enable a

“conversation” between an end user and application
functionality, content, and behavior.
 This conversation can be described using an interaction model
that can be composed of one or more of the following
elements:
(1) use cases
(2) sequence diagrams
(3) state diagrams and/or
(4) user interface prototypes.

34
Dr. K. K. Baseer [Link]
 Cont..
Functional Model

The functional model addresses two app processing elements,

each representing a different level of procedural abstraction:

(1) User-observable functionality that is delivered by the app to

end users and

(2) The operations contained within analysis classes that

implement behaviors associated with the class.

35
Dr. K. K. Baseer [Link]
 Cont..

Figure. Activity diagram for the takeControlOf-Camera()

operation
36
Dr. K. K. Baseer [Link]
 Cont..

Configuration Models for WebApps

 In some cases, the configuration model is nothing more
than a list of server-side and client-side attributes.
 However, for more complex apps, a variety of
configuration complexities (e.g., distributing load among
multiple servers, caching architectures, remote
databases, multiple servers serving various objects)
may have an impact on analysis and design.
 The UML deployment diagram can be used in
situations in which complex configuration
architectures must be considered.

37
Dr. K. K. Baseer [Link]
 Cont..
Navigation Modeling
 In most mobile applications that reside on smartphone
platforms, navigation is generally constrained to relatively
simple button lists and icon-based menus.

 In addition, the depth of navigation (i.e., the number of

levels into the hypermedia hierarchy) is relatively shallow. For
these reasons, navigation modeling is relatively simple.

 For WebApps and an increasing number of tablet-based

mobile applications, navigation modeling is more complex and
often considers how each user category will navigate from one
WebApp element (e.g., content object) to another.

38
Dr. K. K. Baseer [Link]
Thank You