Requirement analysis

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