REQUIREMENT ANALYSISUNIT - II

REQUIREMENT ANALYSIS PROCESS

process of determining the needs or conditions to meet for a new or altered product.

Figure shows the requirements analysis process:

In involves [5] steps: Gather and list requirements Develop service metrics Characterize behavior Develop requirements Map requirements

Metrics – measurements | behavior - range of actions

Develop service matrics

Characterize

behavior

Develop Rqrmnts

Map Rqrmnts

Gather & List

rqrmnts

GATHERING AND LISTING REQUIREMENTS

Communicate with the users to gather their requirements.

Service requirements are gathered and developed with initial conditions on the architecture and design, with input from users, administration and management.

Then refined(process of purification/ unwanted requirements removed) by applying our experience and knowledge about the analysis process.

DETERMINING INITIAL CONDITIONS

It is the starting of the analysis process. Initial conditions consist of

Type of network project Scope/ Future of the architecture and

design( Project Scope and Product Scope) Initial architecture/ design goals.

Part of the initial conditions of new networkproject may be determining its performancetarget: multi-tier performance or single-tierperformance.

DETERMINING INITIAL CONDITIONS

Type of Network Project: New Network Modification of an Existing network

Scope/Future of Network Project: Network size Number of sites Analysis of network problems Outsourcing : across multiple vendors. Consolidation :  facilitate ability to pursue

financings for working capital. Upgrade: replacing a product with a newer

version.

DETERMINING INITIAL CONDITIONS

Initial Architecture / Design Goals: Upgrade technology/ vendor Improve performance to part / All of network Support new users, applications or devices Solve perceived(existing) problems within

system Increase security Support a new capability in system.

DETERMINING INITIAL CONDITIONS

Common constrains(activity) on a network project include Funding limitations Organizational rules and regulations Time and schedule limitations Technical constrains for existing users ,

applications, devices, networks and management.

performance target: Single tier performance Multi tier performance

SINGLE TIER VS MULTI TIER PERFORMANCE

Do not have a set of applications & users.

There is no threshold between low and high performance requirements.

Have a set of applications & users.

There is a threshold between low and high performance requirements.

SETTING CUSTOMER EXPECTATIONS

It is important to begin to set customer expectations. This consists of:a rapid(happening in a short time), initial evaluation(estimation) of the problem, andestimating resources and schedule.

The intent is to inform customers, early in theprocess, when their expectations are not realistic.

WORKING WITH USER

There are some successful techniques thatcan be used: developing a survey to email, FAX, or mail to

users. following up on the survey with one-on-one

telephone calls or conference calls. following up calls with face-to-face meetings

with selected individuals or groups. whiteboard sessions to elicit ideas from users. spending time with users while they work.

TAKING PERFORMANCE MEASUREMENTS

It is helpful to measure performance levels ofapplications and devices that will be used inthe planned network.

Either by testing applications and devices ona separate, controlled network (e.g., testbednetwork) or by measuring their performancelevels on the existing network.

Measurements of peak application and device performance can be used to determine how much degradation in performance is experienced on the existing network.

It become a validation of performance problems on the existing network.

Capture all of the traffic from an application session, by characterized monitoring of the network.

TRACKING AND MANAGING REQUIREMENTS

Requirements also need to be tracked(rough path) and managed.

A listing of requirements should be kept up to date, in a location where everyone involved in the process has access them.

Web is a great tool for posting, tracking and managing requirements.

Number of methods used to track and manage requirements.

TYPES OF MANAGING REQUIREMENTS

Two ways: Paragraph form Tabular form

Paragraph form: Where a requirement is changed within its

original paragraph.

Tabular form: Other software tools can be used for this

process, such as databases and spreadsheets. the key point is requirements documents should

be living documents, updated on a regular basis.

ID/NAME DATE TYPE DESCRIPTION

USER’S

REQUIREMENTS

26 -SEP-2014 ORIGINAL Technology based

upgrades

27 -SEP-2014 CHANGE Software based

upgrades.

28 -SEP-2014 DELETE topology based

upgrades.

(LAN,WAN,MAN)

MAPPING LOCATION INFORMATION

MAPPING LOCATION INFORMATION

The locations of applications and devices will be mapped to show their relative physical locations.

When gathering requirements, note the locations of servers and specialized devices and where specific applications are being used.

Shows an example of how this is done with a Metropolitan-Area Environment with devices and applications.

THANK YOU

DEVELOPING SERVICE METRICS

RMA CAPACITY DELAY

FRAME RELAY UPTIME DOWNTIME PACKET LOSS RATIO PACKET ERROR RATE BIT ERROR RATE

MEASUREMENT TOOLS Where to apply service metrics

CHARACTERIZING BEHAVIOR

Estimates of user session duration The number of active sessions Data sizes Complex / detailed models of user

application behaviour.

MODELLING AND SIMULATION

Equipment type Placement Configuration Behavior under stress / failure.

USER BEHAVIOUR

User work-time and durations Each application the total number of users. Duration of activity

APPLICATION BEHAVIOR

Characterizing application behaviour Data sizes that the application will be

processing Passing across the network Frequency and time duration. Flow directions(client to server) Requirements for multicasting/broadcasting.

DEVELOPING RMA REQUIREMENTS

Reliability Maintainabiliy Availability.

Monthly / weekly / yearly:

Uptime (how to measure) Downtime (how to measure)

DEVELOPING CAPACITY REQUIREMENTS

Capacity: Estimating data rates

Peak data rate(PDA) Minimum data rate(MDR)

DEVELOPING SUPPLEMENTAL PERFORMANCE REQUIREMENTS

Operational suitability (operation/support) Supportability Confidence

RMA

TOOLS

REPAIR AND SPARE PARTS

REQUIREMENT MAPPING