Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Requirement analysis

1,980 views

Published on

Requirement analysis

Published in: Engineering
  • Be the first to comment

Requirement analysis

  1. 1. REQUIREMENT ANALYSIS UNIT - II
  2. 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. 3. Metrics – measurements | behavior - range of actions Develop service matrics Character ize behavior Develop Rqrmnts Map Rqrmnts Gather & List rqrmnts
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  13. 13.  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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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)
  17. 17. MAPPING LOCATION INFORMATION
  18. 18. 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.
  19. 19. THANK YOU
  20. 20. 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
  21. 21. CHARACTERIZING BEHAVIOR  Estimates of user session duration  The number of active sessions  Data sizes  Complex / detailed models of user application behaviour.
  22. 22. MODELLING AND SIMULATION  Equipment type  Placement  Configuration  Behavior under stress / failure.
  23. 23. USER BEHAVIOUR  User work-time and durations  Each application the total number of users.  Duration of activity
  24. 24. 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.
  25. 25. DEVELOPING RMA REQUIREMENTS  Reliability  Maintainabiliy  Availability.  Monthly / weekly / yearly:  Uptime (how to measure)  Downtime (how to measure)
  26. 26. DEVELOPING CAPACITY REQUIREMENTS  Capacity:  Estimating data rates  Peak data rate(PDA)  Minimum data rate(MDR)
  27. 27. DEVELOPING SUPPLEMENTAL PERFORMANCE REQUIREMENTS  Operational suitability (operation/support)  Supportability  Confidence
  28. 28. RMA
  29. 29. TOOLS
  30. 30. REPAIR AND SPARE PARTS
  31. 31. REQUIREMENT MAPPING

×