INTERDEPENDENCIES OF REQUIREMENTS Sample Clauses

INTERDEPENDENCIES OF REQUIREMENTS. The methods and techniques to apply to ensure that a CIS complies with the above model's requirements are not mutually independent. For a given system, two requirements may be “antagonists”: taking into account one requirement may, if one is not careful, result in an immediate or latent decline in the level of satisfaction with another requirement. The methodological approach is designed to counteract these effects. Conversely, for a given system, two requirements may be “convergent”: taking into account one requirement may inadvertently result in an immediate or latent improvement in the level of satisfaction with another requirement. The methodological approach is designed to reinforce these effects. There is no absolute rule of “systematic” antagonism or convergence between two requirements. Interdependencies between requirements vary for each project or system. However, experience shows that there are “natural” cause-and-effect relations between certain requirements. The figure and the table below illustrate the results of this experience. This is a key consideration. It means that one cannot merely apply a method to suit each requirement, but one must adopt a Example: Impact of uncontrolled actions to improve one requirement over other requirements Focusing exclusively on the security criteria can have: ▪ a positive impact on integrity ▪ a negative impact on performance, availability, capacity and usability ▪ a neutral or undetermined impact on maintainability and resilience “systemic” approach that addresses each requirement as much as its interdependencies with the other requirements. Another interesting example concerns performance. Although focusing on performance might have a negative impact on capacity (high volume of transactions and short response times are antagonistic a priori), capacity may nevertheless benefit from improved performance. Both assertions are arguable. One view is that performance improvements could cause capacity to be exceeded more quickly. On the other hand, they might also improve throughput capacity via faster processing. The table below provides a succinct illustration of the “natural” antagonism and convergence between the specific requirements of CISs. This table does not pretend to define a factual rule since there is no such absolute rules of “systematic” antagonism or convergence between two requirements. Its purpose is to help analyse these interdependencies and to structure the approach of those interdependencies...
AutoNDA by SimpleDocs
INTERDEPENDENCIES OF REQUIREMENTS. The methods and techniques to apply to ensure that a CIS complies with the above model's requirements are not mutually independent. For a given system, two requirements may be “antagonists”: taking into account one requirement may, if one is not careful, result in an immediate or latent decline in the level of satisfaction with another requirement. The methodological approach is designed to counteract these effects. Conversely, for a given system, two requirements may be “convergent”: taking into account one requirement may inadvertently result in an immediate or latent improvement in the level of satisfaction with another requirement. The methodological approach is designed to reinforce these effects. There is no absolute rule of “systematic” antagonism or convergence between two requirements. Interdependencies between requirements vary for each project or system. However, experience shows that there are “natural” cause-and-effect relations between certain requirements. The figure and the table below illustrate the results of this experience. This is a key consideration. It means that one cannot merely apply a method to suit each requirement, but one must adopt a “systemic” approach that addresses each requirement as much as its interdependencies with the other requirements. CW/CIS Best Practices for the Design and Development of Critical Information Systems rev. January 2012

Related to INTERDEPENDENCIES OF REQUIREMENTS

  • Functional Requirements Applications must implement controls that protect against known vulnerabilities and threats, including Open Web Application Security Project (OWASP) Top 10 Risks and denial of service (DDOS) attacks.

  • Interface Requirements 2.4.5.1 The NID shall be equal to or better than all of the requirements for NIDs set forth in the applicable industry standard technical references.

  • Specific Requirements compensation insurance with statutory limits required by South Dakota law. Coverage B-Employer’s Liability coverage of not less than $500,000 each accident, $500,000 disease-policy limit, and $500,000 disease-each employee.

  • Points of Interconnection and Trunk Types 2.1 Point(s) of Interconnection. 2.1.1 Each Party, at its own expense, shall provide transport facilities to the technically feasible Point(s) of Interconnection on Verizon’s network in a LATA selected by PNG.

  • Time Requirements The Independent Contractor will not be required to follow or establish a regular or daily work schedule, but shall devote during the term of this Agreement the time, energy and skill as necessary to perform the services of this engagement and shall, periodically or at any time upon the request of the Company, submit information as to the amount of time worked and scope of work performed.

  • Trunking Requirements The Parties will provide designed Interconnection facilities that meet the same technical criteria and service standards, such as probability of blocking in peak hours and transmission standards, in accordance with current industry standards.

  • Software Requirements 7 Developer shall prepare the Project Schedule using Oracle’s Primavera P6.

  • Trunk Types 2.2.1 In interconnecting their networks pursuant to this Attachment, the Parties will use, as appropriate, the following separate and distinct trunk groups: 2.2.1.1 Interconnection Trunks for the transmission and routing of Reciprocal Compensation Traffic, translated LEC IntraLATA toll free service access code (e.g., 800/888/877) traffic, and IntraLATA Toll Traffic, between their respective Telephone Exchange Service Customers, Tandem Transit Traffic, and, Measured Internet Traffic, all in accordance with Sections 5 through 8 of this Attachment; 2.2.1.2 Access Toll Connecting Trunks for the transmission and routing of Exchange Access traffic, including translated InterLATA toll free service access code (e.g., 800/888/877) traffic, between Ymax Telephone Exchange Service Customers and purchasers of Switched Exchange Access Service via a Verizon access Tandem in accordance with Sections 9 through 11 of this Attachment; and 2.2.1.3 Miscellaneous Trunk Groups as mutually agreed to by the Parties, including, but not limited to: (a) choke trunks for traffic congestion and testing; and, (b) untranslated IntraLATA/InterLATA toll free service access code (e.g. 800/888/877) traffic. 2.2.2 Other types of trunk groups may be used by the Parties as provided in other Attachments to this Agreement (e.g., 911/E911 Trunks) or in other separate agreements between the Parties (e.g., directory assistance trunks, operator services trunks, BLV/BLVI trunks or trunks for 500/555 traffic). 2.2.3 In accordance with the terms of this Agreement, the Parties will deploy One-Way Interconnection Trunks (trunks with traffic going in one direction, including one-way trunks and uni-directional two-way trunks) and/or Two-Way Interconnection Trunks (trunks with traffic going in both directions). 2.2.4 Ymax shall establish, at the technically feasible Point(s) of Interconnection on Verizon’s network in a LATA, separate Interconnection Trunk group(s) between such POI(s) and each Verizon Tandem in a LATA with a subtending End Office(s) to which Ymax originates calls for Verizon to terminate. 2.2.5 In the event the volume of traffic between a Verizon End Office and a technically feasible Point of Interconnection on Verizon’s network in a LATA, which is carried by a Final Tandem Interconnection Trunk group, exceeds (a) the Centium Call Seconds (Hundred Call Seconds) busy hour equivalent of one (1) DS1 at any time; (b) 200,000 minutes of use for a single month; and/or; (c) 600 busy hour Centium Call Seconds (BHCCS) of use for a single month: (i) if One-Way Interconnection Trunks are used, the originating Party shall promptly establish new or augment existing End Office One-Way Interconnection Trunk groups between the Verizon End Office and the technically feasible Point of Interconnection on Verizon’s network; or,

  • Switching System Hierarchy and Trunking Requirements For purposes of routing ECI traffic to Verizon, the subtending arrangements between Verizon Tandem Switches and Verizon End Office Switches shall be the same as the Tandem/End Office subtending arrangements Verizon maintains for the routing of its own or other carriers’ traffic (i.e., traffic will be routed to the appropriate Verizon Tandem subtended by the terminating End Office serving the Verizon Customer). For purposes of routing Verizon traffic to ECI, the subtending arrangements between ECI Tandem Switches and ECI End Office Switches shall be the same as the Tandem/End Office subtending arrangements that ECI maintains for the routing of its own or other carriers’ traffic.

  • Design Requirements The DG Facility shall be installed in compliance with Wisconsin Administrative Code Chapter PSC 119.

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!