The document discusses the requirement analysis process which involves 5 steps: gathering requirements, developing service metrics, characterizing behavior, developing requirements, and mapping requirements. It describes gathering requirements from users, determining initial network conditions, developing metrics like capacity and availability, modeling user and application behavior, and mapping location information. Requirements are tracked and managed in documents or databases and updated periodically.

1. REQUIREMENT ANALYSIS
UNIT - II

2. 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

3. Metrics – measurements | behavior - range of actions
Develop
service
matrics
Character
ize
behavior
Develop
Rqrmnts
Map
Rqrmnts
Gather &
List
rqrmnts

4. 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.

5. 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 network
project may be determining its performance
target: multi-tier performance or single-tier
performance.

6. 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.

7. 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.

8. 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

9. 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.

10. 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, and
estimating resources and schedule.
 The intent is to inform customers, early in the
process, when their expectations are
not realistic.

11. WORKING WITH USER
 There are some successful techniques that
can 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.

12. TAKING PERFORMANCE MEASUREMENTS
 It is helpful to measure performance levels of
applications and devices that will be used in
the planned network.
 Either by testing applications and devices on
a separate, controlled network (e.g., testbed
network) or by measuring their performance
levels on the existing network.

14.  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.

15. 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.

16. 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.

17. 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)

18. MAPPING LOCATION INFORMATION

19. 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.

20. THANK YOU

21. 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

22. CHARACTERIZING BEHAVIOR
 Estimates of user session duration
 The number of active sessions
 Data sizes
 Complex / detailed models of user application
behaviour.

23. MODELLING AND SIMULATION
 Equipment type
 Placement
 Configuration
 Behavior under stress / failure.

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

25. 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.

26. DEVELOPING RMA REQUIREMENTS
 Reliability
 Maintainabiliy
 Availability.
 Monthly / weekly / yearly:
 Uptime (how to measure)
 Downtime (how to measure)

27. DEVELOPING CAPACITY REQUIREMENTS
 Capacity:
 Estimating data rates
 Peak data rate(PDA)
 Minimum data rate(MDR)

28. DEVELOPING SUPPLEMENTAL PERFORMANCE
REQUIREMENTS
 Operational suitability (operation/support)
 Supportability
 Confidence

29. RMA

30. TOOLS

31. REPAIR AND SPARE PARTS

32. REQUIREMENT MAPPING