This document provides the detailed IP interface Requirements/Feature Specifications (R/FS) for Avaya 96x1 telephones with H.323 software, based on high-level requirements in the 96x1 IP Deskphone H.323 Software Product Requirements Document [7.1-1c].
1.1 Document Process, Approval, Access and Change Control
The current approved version of this document will be available on COMPAS. After this document is approved, MRs (Modification Requests) will also be entered on COMPAS. Note that approved MRs are considered to be a part of the document, even if a new issue of the document that incorporates the MR content has not yet been generated. Quality records pertaining to the initial approval and changes to this document are archived in the following Outlook email folder:
Public Folders / All Public Folders / Product Organizations / Communications Appliances Division / ECAS R&D /
Systems Engineering / John Soltes / 96x1H-IPI
The body of a requirement, as defined below, takes precedence over any surrounding or explanatory content (e.g., text, tables, figures, etc.) that is not a part of the body of a requirement. In order to streamline the maintenance of this document and to encourage the author to add and clarify explanatory content, an MR is only required to add a new requirement or to change the body of an approved requirement (i.e., not for changes to Titles, Issues, Notes, Rationales, or other surrounding text), although an MR may also be entered against other content if desired. Therefore, the bodies of requirements are under change control, but the rest of the document is author-controlled.
MR approval requires approval by each document approver (see the table below) or their delegate whose functional area would be impacted by the MR. The author is responsible for ensuring that a Quality Record for each approval is archived in the location specified above, including the creation and circulation (to the document approvers) of Quality Records to document verbal approvals that do not occur in meetings for which sufficiently detailed, archiveable meeting notes are produced. However (again to streamline the maintenance of the document), the author may also make editorial, non-substantive changes to the body of a requirement without the need for an MR, and may unilaterally approve an MR and make appropriate changes to the body of a requirement without getting additional approvals, when such an MR deals with minor editorial changes without substantive content.
All MRs incorporated in an issue will be listed in Appendix D: Document Change History.
In addition to the author, the approvers of this document are as follows:
-
Name
|
Project Functional Responsibility
|
Oliver Bengtsson
|
Product Management
|
Eyal Serero
|
Software Development
|
Pankaj Dwivedi
|
System Verification
|
-
Issue
|
Date
|
6.0
|
January 10, 2010
|
6.0 (Revision 1)
|
March 12, 2010
|
6.1
|
June 18, 2010
|
6.1 (Revision 1)
|
September 17, 2010
|
6.1 (Revision 2)
|
December 2, 2010
|
6.1 (Revision 3)
|
August 8, 2010
|
6.2
|
October 6, 2011
|
6.2 (Revision 1)
|
March 7, 2012
|
6.2 (Revision 2)
|
March 20, 2012
|
6.3
|
April 8, 2013
|
6.3 (Revision 1)
|
August 8, 2013
|
6.3 (Revision 2)
|
October 7, 2013
|
6.3.1
|
October 22, 2013
|
6.4
|
June 02, 2014
|
Requirements in this document use the following format:
96x1H-IPI.x.y.zzz: </b>
<br /></td> </tr> <tr valign="top"> <td width="106">
<br /><i><b><status></b></i>
<br /></td> <td width="537">
<br /><body>
<br /></td> </tr> <tr valign="top"> <td width="106">
<br /><i><b>Issue:</b></i>
<br /></td> <td width="537">
<br /><i><text of issue></i>
<br /></td> </tr> <tr valign="top"> <td width="106">
<br /><i><b>Note:</b></i>
<br /></td> <td width="537">
<br /><i><text of note></i>
<br /></td> </tr> <tr valign="top"> <td width="106">
<br /><i><b>Example:</b></i>
<br /></td> <td width="537">
<br /><i><text of example></i>
<br /></td> </tr> <tr valign="top"> <td width="106">
<br /><i><b>Rationale:</b></i>
<br /></td> <td width="537">
<br /><i><text of rationale></i>
<br /></td> </tr> </table>
<br />where:
<br /><table width="672" cellpadding="7" cellspacing="0"> <col width="107"> <col width="537"> <tr valign="top"> <td width="107" height="2">
<br /><b>96x1H-IPI.x.y.zzz:</b>
<br /></td> <td width="537">
<br />is the requirement identifier, a unique string that identifies the requirement. The identifier will not change after the requirement is approved (to facilitate traceability). <b>96x1H-IPI</b> is the document <a href="/standard-development-report-v2.html">identifier for this document</a>, <b>x.y</b> is the second-level section number and <b>zzz</b> is a requirement number within that section.
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><b><title></b>
<br /></td> <td width="537">
<br />gives a one-line description of the subject of the requirement. The title is <b>not</b> part of the body of the requirement.
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><i><b><status></b></i>
<br /></td> <td width="537">
<br />is <i><b>DRAFT</b></i> if the requirement has open blocking issues or is otherwise not yet ready for approval, <i><b>READY</b></i> if the author believes that it is ready for approval and <i><b>Approved</b></i> if it has been approved. <i><b>Approved for S6.1+</b></i> means that the requirement (or a portion of a requirement) applies to software release S6.1 and all subsequent software releases (the ‘+’ means “and all subsequent releases”), but does <b>not</b> apply to previous software releases. Any status that is not further qualified applies to all releases of the product. After Issue 6.0, requirements (or portions thereof) <a href="/approved-company-approved-agent-fidelity-investments.html">that are not yet approved</a>, or that are changes from the previously approved version, will also be highlighted with shading.
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><body>
<br /></td> <td width="537">
<br />is the requirement itself. Note that the applicability of the requirement to specific telephones is usually indicated first in <b>bold type</b>, such as “<b>All telephones that have a secondary Ethernet interface </b>will...”.
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><i><b>Issue:</b></i>
<br /></td> <td width="537">
<br /><i>identifies open questions, issues, or areas for further consideration or <a href="/unit-title-hit-and-miss-teachers.html">refinement of the requirement</a>, but issues are </i><i><b>not</b></i><i> part of the body of the requirement. Zero, one or multiple Issues may be present. Issues with approved requirements will be highlighted with shading, but need not be entered as MRs until their resolution is being actively worked.</i>
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><i><b>Note:</b></i>
<br /></td> <td width="537">
<br /><i>provides information related to the requirement (such as explicitly stating consequences of the requirement on product operation) but notes are </i><i><b>not</b></i><i> part of the body of the requirement. Zero, one or multiple Notes may be present.</i>
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><i><b>Example:</b></i>
<br /></td> <td width="537">
<br /><i>provides an example to illustrate a requirement, <a href="/multi-core-software-development-with-examples-in-c.html">but examples are </a></i><i><b>not</b></i><i> part of the body of the requirement, and are always in italic type. Zero, one or multiple Examples may be present.</i>
<br /></td> </tr> <tr valign="top"> <td width="107">
<br /><i><b>Rationale:</b></i>
<br /></td> <td width="537">
<br /><i>provides information related to why the requirement is what it is, but the rationale is </i><i><b>not</b></i><i> part of the body of the requirement. Zero, one or multiple Rationales may be present.</i>
<br /></td> </tr> </table>
<br />References to other documents are indicated by square brackets (e.g., [7.1-1], which means the first document listed in Section 7.1).
<br /></body></status> | |
