requirements modelling stratigies

7/29/2019 Requirements Modelling Stratigies

1/74

Goals of Analysis Modeling

Provides the first technical representation of a system

Is easy to understand and maintain

Deals with the problem of size by partitioning the system

Uses graphics whenever possible

Differentiates between essential information versus implementationinformation

Helps in the tracking and evaluation of interfaces

Provides tools other than narrative text to describe software logic and

policy


2/74

A Set of Models

Flow-oriented modeling provides an indication of how data objects aretransformed by a set of processing functions

Scenario-based modeling represents the system from the user's point ofview

Class-based modeling defines objects, attributes, and relationships

Behavioral modeling depicts the states of the classes and the impact ofevents on these states


3/74

Analysis Modeling Approaches

Structured analysis

Considers data and the processes that transform the data as separate entities

Data is modeled in terms of only attributes and relationships (but no

operations) \\ ER Diagram

Processes are modeled to show the 1) input data, 2) the transformation that

occurs on that data, and 3) the resulting output data \\ DFD

Object-oriented analysis

Focuses on the definition of classes and the manner in which they collaborate

with one another to fulfill customer requirements


4/74

Elements of the Analysis Model(Requirements Modeling Strategies)

Use case text

Use case diagramsActivity diagrams

Swim lane diagrams

Scenario-based

modeling

Class diagrams

Analysis packages

CRC models

Collaboration diagrams

Class-basedmodeling

Data structure diagrams

Data flow diagramsControl-flow diagrams

Processing narratives

Flow-oriented

modeling

State diagrams

Sequence diagrams

Behavioralmodeling

Structured AnalysisObject-oriented Analysis


5/74

Analysis Model

Elements of the analysis model


6/74

Building the Requirements Model

(Elements of the Analysis Model)

Scenario-based elements Describe the system from the user's point of view using scenarios that

are depicted in use casesand activity diagrams

Class-based elements Identify the domain classes for the objects manipulated by the actors, the

attributes of these classes, and how they interact with one another; theyutilize class diagramsto do this

Behavioral elements Use state diagrams to represent the state of the system, the events that

cause the system to change state, and the actions that are taken as aresult of a particular event; can also be applied to each class in thesystem

Flow-oriented elements Use data flow diagrams to show the input data that comes into a system,

what functions are applied to that data to do transformations, and whatresulting output data are produced


7/74

Scenario-Based Modeling(Functional and Behavioral requirements)


8/74

Use-case Diagram

Use-case diagram for surveillance function


9/74

If the description is unclear, the use case can be

misleading or ambiguous. Focuses on Functional and Behavioral requirements.

Inappropriate for modeling with significant detail andprecisions.

Can the actor take some other action at this point?

Is it possible that the actor will encounter some errorcondition at this point?

Is it possible that the actor will encounter behaviorinvoked by some event outside the actors control?

Alternative Actions


10/74

Activity diagram for

Access camera

surveillancedisplay

camera views function

Supplements the use case

Graphical representation of the

flow of interaction within a specific

scenario.


11/74

Swimlane

diagram :A

variation of the

activity

diagram

Note : Use

cases, along

with activity and

swimlane

diagrams, are

procedurally

oriented, i.e.

represent the

manner in

which various

actors invoke

specific

functions


12/74

Flow-oriented Modeling


13/74

Structured Analysis Tools

Data Models

Entity Relationship Diagrams

Data Dictionary

Information Models and Functional Models

Data Flow Diagrams

Control Flow Diagrams

Process Specification


14/74

Data Dictionary

Purpose?

To define and describe all data elements

To serve as a central repository of information

about the systems data

To organize information about contents of data

flows, data stores, and, possibly, external entities

and processes. Often supported by CASE tool

Data Model


15/74

Data Dictionary

Data element documentation

name

aliases

type

length

output format

acceptable values

Source

security

user

comments

Data Model


16/74

Data Dictionary (possible components)

Data flow information

Data store information

Process information External entity information

Data structure information

Data Model


17/74

Data Structure Example

Customer Order = Customer Number +

Customer Name +

Address +

Telephone +

Catalog Number +Order Date +

{Order Items} +

Merchandise Total +

(Tax) +

Shipping and Handling +Order Total +

Method of Payment +

(Credit Card Type) +

(Credit Card Number) +

(Expiration Date)


18/74

Algebraic Notation

The symbols used are

Equal sign, meaning consists of

Plus sign, meaning "and

Braces {} meaning repetitive elements, a repeating

element or group of elements

Brackets [] for an either/or situation

The elements listed inside are mutually exclusive

Parentheses () for an optional element


19/74

Data Modeling

Identify the following items

Data objects (Entities)

Data attributes

Relationships

Cardinality (number of occurrences)

Data Model


20/74

Data Flow/Control Flow/Process Specification

Data Flow Diagram

Depicts how input is transformed into output as data objects

move through a system

Process Specification Describes data flow processing at the lowest level of

refinement in the data flow diagrams

Control Flow Diagram

Illustrates how events affect the behavior of a system

through the use of state diagrams

Information Models and Functional Models


21/74

Guidelines

Depict the system as single bubble in level 0.

Carefully note primary input and output.

Refine by isolating candidate processes and their

associated data objects and data stores. Label all elements with meaningful names.

Maintain information conformity between levels.

// Information flow continuity

Refine one bubble at a time.

Data Flow Model


22/74

Diagram Layering and Process

Refinement

Context-level diagram

Level 1 diagram

Process Specification Data Flow Model


23/74

Data Flow Diagram

Context-level DFD for SafeHome security function

Data Flow Model


24/74

Grammatical Parse

The SafeHomesecurity functionenables the homeowner to configure the securitysystem when it is installed, monitors all sensorsconnected to the security system, and

interacts with the homeowner through the Internet, a PC, or a control panel.

During installation, the SafeHome PC is used toprogram and configure the system.

Each sensor is assigned a number and type, a master password isprogrammed for

arming and disarming the system, and telephone number(s) are input for dialing when

a sensor event occurs.

When a sensor event is recognized, the software invokes an audible alarm attached to

the system. After a delay time that is specified by the homeowner during system

configuration activities, the software dials a telephone number of a monitoring service,

provides information about the location, reporting the nature of the event that has been

detected. The telephone number will be redialed every 20 seconds until a telephone

connection is obtained.

The homeownerreceivessecurity information via a control panel, the PC, or a

browser, collectively called an interface. The interface displays prompting messages

and systemstatus information on the control panel, the PC, or the browser window.

Homeowner interaction takes the following form

Data Flow Model


25/74

Data Flow Model


26/74

Level 2 DFD that refines the monitor sensors process Data Flow Model


27/74

Creating control flow model

Large class of applications are also required

control flow model apart from data model andDFD.

Large class of applications are driven byevents and produce control information

Heavy concern for time and performance.

Event or control item is implemented as aBoolean Value or a discrete list of conditions.

Eg. Sensor event(sensor is tripped), blinkflag(signal to blink the display), start/stopswitch

Control Flow Model


28/74

The Control Specification

Represents behavior of the system in 2 different ways. State Diagram : Sequential Specification of behaviour

Program Activation Table : Combinatorial specification of behaviour Determines in detail how/when the out control

flows of the control node are asserted(stated)

C-specs also specifies the condition under which theprocessing nodes in the corresponding DFD isactivated

Process Activation Table (PAT) It represents information contained in the state diagram in the

context of processes not states (Example given later)

The table indicates which processes (bubble) in the flow model willbe invoked when an event occurs.

PAT can be used as a guide for a designer who must build anexecutive, that controls the processes.

Control Flow Model


29/74


30/74

Example: C-Spec showing a Process Activation tableof Monitor Sensor controller

It is used to specify process activation for a

given combination of input controls


31/74

Control Flow Diagram

State diagram for SafeHome security function Control Flow Model


32/74

Process Specification

The content of PSPEC includes narrative text,

program design language (PDL), processalgorithms, mathematical equations, tables,

UML activity diagrams etc.

Used to create mini-specification Determines how the output data/control items

from a process in the DFD are determined from

the input data

Control Flow Model


33/74

P-Spec Example


34/74


35/74

Creating Behavioral Model

Represents the behaviour of the system as a function of specificevents and time

Indicates how software will respond to external events.

Steps to be performed:

1. Evaluate all use cases to fully understand the sequence ofinteraction within the system

2. Identify events that drive the interaction sequence andunderstand how these events relate to specific object

3. Prepare sequence for use case

4. Build State diagram

5. Review for accuracy and consistency

USE CASES STATE DIAGRAM

SEQUENCE DIAGRAM

ACTIVITY DIAGRAM

E i h h U C


36/74

Events with the Use Case

Represents a sequence of activities that involves actors and the

system.

An event occurs whenever the system and an actor exchangeinformation.

A use case is examined for points of information exchange. Actor

should be identified for each event.

State Representation1. The state of each class as the system performs its functions

2. The state of the system as observed from the outside as the

system performs its function.Sequence Diagrams

Indicates how events cause transitions from object to object.

Is a representation of how events cause flow from one object or

another as a function of time.


37/74


38/74

EX : The action connected to the password entered event is an

operation named validatePassword() that access the password

object and performs a digit-by-digit comparison to validate the

password entered.


39/74

St t di f th C t lP l l


40/74

State diagram for the ControlPanel class

EX : The action connected to the password entered event is an

operation named validatePassword() that access the password

object and performs a digit-by-digit comparison to validate the

password entered.


41/74

Sequence Diagram

Sequence diagram (partial) for the SafeHome security function


42/74

Class-Based Modeling


43/74

Identifying Analysis Classes

External entities that produce or consumeinformation

Things that are part of the information domain

Occurrences or events Roles played by people who interact with the system

Organizational units

Places that establish context

Structures that define a class of objects


44/74

Class Selection Criteria

1. Retained information

2. Needed services

3. Multiple attributes

4. Common attributes

5. Common operations

6. Essential requirements


45/74

Identifying Classes

Potential class Classification Accept / Reject

homeowner role; external entity reject: 1, 2 fail

sensor external entity accept

control panel external entity acceptinstallation occurrence reject

(security) system thing accept

number, type not objects, attributes reject: 3 fails

master password thing reject: 3 fails

telephone number thing reject: 3 fails

sensor event occurrence accept

audible alarm external entity accept: 1 fails

monitoring service organizational unit; ee reject: 1, 2 fail


46/74

Class Diagram

Class diagram for the system class


47/74

Class Diagram

Class diagram for FloorPlan

CRC Modeling


48/74

CRC Modeling

Entity Classes \\ Important to users but do not display,

persist throughout the duration of the application Boundary Classes \\ To create Interface

Controller Classes \\ 1. Creation of entity objects2. Instantiation of boundary objects

3. Validation of communication between objects

A CRC model index card for FloorPlan class

CRC Modeling


49/74

1. System intelligence should be distributed across classes to

best address the needs of the problem.

2. Each responsibility should be stated as generally as possible.

// hierarchy

3. Information and the behaviour related to it should reside

within the same class. // Encapsulation4. Information about one thing should be localized with a

single class, not distributed across multiple classes.

5. Responsibilities should be shared among related classes,

when appropriate.

CRC Modeling


50/74

Class Diagrams

Top: Multiplicity

Bottom: Dependencies


51/74


52/74


53/74


54/74


55/74


56/74


57/74


58/74


59/74

Requirement Modeling For WebApps

When the requirements are not properlyunderstood, at that time we perform

requirement Modeling

Req irement Modeling For WebApps


60/74

Requirement Modeling For WebApps

Requirement Analysis does take time, but solvingthe wrong problem takes even more time.

The question for every WebApp developer is

simple are you sure you understand therequirements of the problem?

If the answer is an unequivocal yes then it may

be possible to skip requirements modeling.

But if the answer is no, then requirementsmodeling should be performed.

How much analysis is enough?


61/74

y g

The degree to which requirements modelingfor WebApps is emphasized on the followingfactors:

Size and complexity of WebApp increment

Number of stakeholders (analysis can helpto identify conflicting requirements coming

from different sources)

Size of the WebApp team

Degree to which members of the WebApp team


62/74

Degree to which members of the WebApp team

have worked together before (analysis can help

develop a common understanding of the project)

Degree to which the organizations success is

directly dependent on the success of the WebApp.

Although it is a good idea to analyze the problem

before beginning design, it is not true that all

analysis must precede all design.

I f t th d i f ifi t f th


63/74

In fact, the design of a specific part of the

WebApp only demands an analysis of those

requirements that affect only that part of theWebApp.

For example, you could validly design the

overall website aesthetics without having

analyzed the functional requirements for

e-commerece capabilities

Requirement Modeling Input


64/74

Requirement Modeling Input

An agile version of the generic software process

can be applied when WebApps are engineered.

The process incorporates a communication activity

that identifies stakeholders and user categories, the

business context, defined informational andadaptive goals, general WebApp requirements, and

usage scenario information that becomes input to

requirements modeling.

Analysis takes this information, structures it using a

formally defined representation scheme

and then produces more rigorous models as an


65/74

and then produces more rigorous models as an

output.

It is reasonable to conclude that although the

communication activity provides a good foundation

for understanding, requirements analysis refines

this understanding by providing additionalinterpretation.

In short, input to the requirements model will be the

information collected during the communication

activity anything from informal mail to detailed

project brief complete with comprehensive usage

scenarios and product specification.

Requirement Modeling Output


66/74

Requirement Modeling Output

Requirement analysis provides a disciplinedmechanism for representing and evaluating WebAppcontent and function, the modes of interaction thatusers will encounter, and the environment andinfrastructure in which the WebApp resides.

Each of these characteristics can be represented asa set of models that allow the WebApp requirementsto be analyzed in a structured manner.

There are five main classes of models :

1) Content Model 2) Interaction Model 3) FunctionalModel 4) Navigation Model 5) Configuration Model.

Content Model For WebApps


67/74

Content Model For WebApps

Identifies the full spectrum of content to be provided

by the WebApp. Content includes text, graphics andimages, video, and audio data.

The content model contains structural elements thatprovide an important view of content requirements for

WebApps.

These structural elements encompass content

objects and all analysis classes- user visible entities

that are created or manipulated as a user interacts

with the WebApp.

A content object is any item of cohesive information


68/74

co te t object s a y te o co es e o at othat is to be presented to an end user. A contentobject might be a textual description of a product, an

article describing a news event, a users response ona discussion forum etc.

Content objects can be determined directly from use

case by examining the scenario description for directand indirect references to content.

The content model must be capable of describing

the content object.

In some cases, a simple list of content objects,coupled with a brief description of each object, is

sufficient to define the requirements for content that


69/74

qmust be designed and implemented. In some cases,the content model may benefit from a richer analysis

that graphically illustrates the relationship amongcontent objects and/or the hierarchy of contentmaintained by a WebApp.

A data tree is created for any content that iscomposed of multiple content objects and data items.

The data tree is developed in an effort to define

hierarchical relationship among content objects and toprovide a means for reviewing content so thatomissions and inconsistencies are uncovered beforedesign commences.

Interaction Model For WebApps


70/74

Interaction Model For WebApps

The vast majority of WebApp enable a conversion

between an end user and application functionality,content, and behavior.

This conversation can be described using aninteraction model that can be composed of one or

more of he following elements : (1) use case, (2)

sequence diagram, (3) state diagrams, and (4) user

interface prototype.

In some cases, a set of use case is sufficient to

describe the interaction at an analysis level.

Wh th f i t ti i l d


71/74

When the sequence of interaction is complex and

involves multiple analysis classes or many tasks, it is

sometimes worthwhile to depict it using a morerigorous diagrammatic form.

The layout of user interface, the content it presents,

overall details of user-WebApp connections havemuch to do with user satisfaction and overall

success.

The sooner that a physical representation of a user

interface can be reviewed, the higher the likelihood

that end users will get what they want.

Functional Model For WebApps


72/74

pp

Many WebApps deliver an array of computational

and manipulative functions that can be associatedwith content.

The functional model addresses two processing

elements representing different level of proceduralabstraction : (1) User observable functionality

(Higher level of abstraction) encompasses any

processing functions that are initiated directly by the

user. (2) the operations contained within analysis

classes (Lower level of abstraction) that implement

behaviour associated with the class.

Configuration Model For WebApps


73/74

Configuration Model For WebApps

The configuration model is nothing more than a list of

server-side and client-side attributes.

For more complex WebApps, a variety of configuration

complexities (e.g. distributing loads, cachingarchitecture, remote databases) 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.

Navigation Modeling


74/74

g g

Navigation modeling considers how each user

category will navigate from one WebApp element to

another.

At this stage, you should focus on overall navigation

requirements.

The following questions should be considered:

oFor which user category should optimal navigation bedesigned?

oShould a navigation log be maintained for user?

H h ld i i b h dl d?

requirements modelling stratigies

Documents