Requirements Analysis: Process PDF

Requirements Analysis: Process Chapter 3 Gathering and Listing Requirements 1. Determining Initial Conditions 2. Setting Customer Expectations 3. Working with Users 4. Taking Performance Measurements 5. Tracking and Managing Requirements 6. Mapping Location Information Gather...

Requirements Analysis: Process Chapter 3 Gathering and Listing Requirements 1. Determining Initial Conditions 2. Setting Customer Expectations 3. Working with Users 4. Taking Performance Measurements 5. Tracking and Managing Requirements 6. Mapping Location Information Gathering and Listing Requirements 1. Determining Initial Conditions : A. The type of network project B. The scope of the architecture and design C. Initial architecture/design goals, and any outside forces acting on the network. For example : 2. Setting Customer Expectations: This consists of a rapid, initial evaluation of the problem, and estimating resources and schedule 3. Working with Users : may be to think “this takes too much time,” “they are not cooperative,” “they don’t know what they want,” and so on, but this is a vital By initially spending time with users, you gain a better understanding of their behavior patterns and environment. For the end users, discussing your network plans with them helps them to understand what you are trying to accomplish and builds lines of personal communication that will be useful when you are installing, debugging, and operating the network later on. There are some successful techniques that you can use: 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 to better understand what they do and how they do it 3. Working with Users : A key trade-off is the amount of time spent versus the quality of information gathered. it is important not to take a hit-and-run approach, By building relationships with the users, administration, and management, through discussing their requirements, advising them of results and anticipated actions, and informing them of progress with the network project, you are developing advocates for your network. This may be vital when you need to upgrade the network in the future, or if you have to defend your architectural and design decisions. 4. Taking Performance Measurements: Whenever possible, it is helpful to measure performance levels of applications and devices that will be used in the planned network This is often done either by testing applications and devices on a separate, controlled network (e.g., testbed network) Building a small testbed network to measure application and device performance can serve multiple purposes You will be able to measure peak performance to determine how much degradation in performance is experienced on the existing network Along with performance measurements, you can often capture all of the traffic from an application session Tools that can help capture traffic include Sniffer, Ethereal, and Etherpeak. If a testbed network cannot be built to measure performance, measurements can be made on the existing network 5. Tracking and Managing Requirements Requirements also need to be tracked and managed. A listing of requirements should be kept up to date There are a number of methods used to track and manage requirements : First is paragraph form: where a requirement is changed within its original paragraph Secondly using tabular form: In this method the requirement is kept in its original form, and any changes to it are added to a table. 6. Mapping Location Information : Developing Service Metrics After gathering requirements for our network We will develop and use performance thresholds and limits to distinguish between low and high performance, and also use performance characteristics to identify predictable and guaranteed performance levels. Performance thresholds and limits and performance characteristics are measured in the system with service metrics. performance characteristic to be useful, it must be configurable, measurable, and verifiable within the network.  Service metrics for RMA include: Reliability, in terms of mean time between failures (MTBF) and mean time between mission-critical failures (MTBCF) Maintainability, in terms of mean time to repair (MTTR) Availability, in terms of MTBF, MTBCF, MTTR Optionally, uptime and downtime (as a percent of total time), error and loss rates at various levels, such as packet error rate, bit error rate (BER), cell loss ratio (CLR), cell miss insertion ratio (CMR), frame and packet loss rates  Service metrics for capacity include: Data rates, in terms of peak data rate (PDR), sustained data rate (SDR), and minimum data rate (MDR) Data sizes, including burst sizes and durations Service metrics for delay include: End-to-end or round-trip delay Latency Delay variation  Measurement Tools ping which roughly measures round-trip delays between selected sources and destinations in the network. pathchar (available from ee.lbl.gov), which combines round-trip delay and per-link capacity measurements with path traces. as does another popular utility traceroute. TCPdump: Another popular tool to analyze TCP traffic. Characterizing Behavior Characterizing behavior means representing how users and applications use the network, in order to develop and understand their requirements. The goal of characterizing behavior for our network is to determine if we can estimate network performance requirements through understanding how users and applications behave across the network. The types of behavior that we examine include: User behavior Application behavior Network behavior Modeling and Simulation Developing models or simulations of user, application, and network behavior is often useful in predicting, determining, or estimating requirements and data flows. Models can range from easy, simplistic, first-order approximations to highly complex and time consuming. Modeling and simulation are useful throughout the analysis process for characterizing user, application, and existing network behaviors. They are also useful during the architecture and design processes for understanding the temporal and spatial behaviors of traffic flows  User Behavior Simple usage patterns can include User work times and durations; For each application the total number of users, the frequency that a user is expected to have an application session running (usually as number of sessions per user, per day). how long an average application session will last (usually on the order of minutes), and an estimate of the expected number of simultaneous user sessions for that application. Estimating the frequency and duration of application sessions and the number of simultaneous sessions allows you to apply a modifier to the performance requirement for each application Application Behavior It is also useful to determine the behavior of application sessions. Along with user behavior, application behavior can help you to modify performance requirements to achieve a better estimate of what services and performance levels you will need for your network. Developing RMA Requirements Reliability : Reliability is a statistical indicator of the frequency of failure of the network and its components and represents the unscheduled outages of service. mean time between mission-critical failure (MTBCF), usually expressed in hours. A related measure is the mean time between failure (MTBF) which considers all failures, regardless of their significance at the time of failure. Maintainability: statistical measure of the time to restore the system to fully operational status. Expressed as mean time to repair (MTTR)  Availability: the relationship between the frequency of mission-critical failure and the time to restore service. A = (MTBCF)/(MTBCF+MTTR) or A = (MTBF)/(MTBF+MTTR) Uptime and Downtime A common measure of availability is expressed in terms of percent of uptime or downtime. For Example a request for proposal (RFP) from a potential customer may state a required uptime of 99.999% (commonly known as “five nines”) Thresholds and Limits RMA requirements may include descriptions of thresholds and/or limits. RMA requirements are gathered and/or derived for each of the applications in your network from discussions with users. as well as from documentation on the applications and testing of the applications on the existing network or on a testbed network. Developing Delay Requirements For applications that have delay requirements, we use the terms end-to-end delay, round-trip delay, and delay variation as measures of delay in the network. We begin by introducing some useful general thresholds and limits for delay: Interaction delay (INTD): is an estimate of how long a user is willing to wait for a response from the system during an interactive session. depends on user behavior, the user’s environment, and the types of applications being used. Human response time(HRT): is an estimate of the time threshold at which users begin to perceive delay in the system. when the system response time is less than HRT, users generally do not perceive any delay in the system. Network propagation delay: is an estimate of how long it takes for a signal to cross a physical medium or link End-to-End and Round-Trip Delays End-to-End and Round-Trip Delays End-to-end and round-trip delays are composed of many sources of delay, including propagation, queuing, transmission, I/O, switching, and processing. It would be useful to be able to monitor and measure each source of delay, it is not practical for most networks. Delay variation Delay variation is often coupled with end-to-end or round-trip delay to give an overall delay performance requirement for applications that are sensitive to the interarrival time of information. Developing Capacity Requirements Estimating a data rate is based on how much information you know about the transmission characteristics of the application and how accurate the estimation needs to be. Commonly used data rates include peak data rate (PDR), sustained data rate (SDR), minimum data rate (MDR), or combinations of these. Supportability A key component of the customer’s satisfaction with the network, is its ability to maintain the high level of performance achieved on the day of delivery throughout the design life of the network. unsophisticated customer will recognize the poor quality of a design and implementation only when it is frequently out of service. an experienced and knowledgeable customer will examine the design carefully before authorizing implementation and will want to know if it will persistently provide quality performance for its entire life cycle. A sophisticated customer will understand the implications of an operations concept and a support concept and will respect the designer’s commitment to ongoing performance after the implementation is complete and the engineers are paid.  Supportability is driven by five major factors: 1. The reliability, maintainability, and operational availability (RMA) characteristics of the architecture/design; 2. Workforce, including training and staffing levels; 3. System procedures and technical documentation; 4. Tools, both standard and special; and 5. Spare and repair parts. Two classes of maintenance need to be performed on the network, once it is deployed: preventive and corrective. Support Concept The support concept describes the way in which the network is supported. A commonly accepted maintenance support concept is the three-tier model. Confidence Confidence is a measure of the network’s ability to deliver data without error or loss at the required throughput. This can be estimated in terms of error and/or loss rates.