Medspiration â System Requirements Document - Data User Element
Medspiration â System Requirements Document - Data User Element
Medspiration â System Requirements Document - Data User Element
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Medspiration</strong><br />
<strong>System</strong> <strong>Requirements</strong> <strong>Document</strong><br />
list below:<br />
MED-SOC-RS-001_1<br />
Issue F<br />
RD.1<br />
<strong>Medspiration</strong> Statement of Work.<br />
RD.2<br />
<strong>Medspiration</strong> <strong>User</strong> <strong>Requirements</strong> <strong>Document</strong><br />
RD.3 The Recommended GHRSST-PP Processing Specification GDS Version 1<br />
revision 1.1, 7 th January, 2004<br />
1.4 Definitions of Terms<br />
The following terms have been used in this report with the meanings shown.<br />
Term<br />
Definition<br />
External Interface<br />
An interface external to the <strong>Medspiration</strong> system<br />
Internal Interface<br />
An interfaces contained entirely within the system e.g.<br />
inter-module interfaces.<br />
1.5 <strong>System</strong> Requirement Format<br />
Each SR has been identified with a unique identifier of the form:<br />
SR.[CLA.]MOD.NUM.V<br />
where:<br />
SR = <strong>System</strong> Requirement,<br />
CLA = Class of requirement (see Table 1-2 for definitions). This field is<br />
absent in the label for functional requirements.<br />
MOD = Functional Module or Class (see Table 1-1 for definitions),<br />
NUM = Requirement number and<br />
V = Version. Initially this is not required. However any subsequent<br />
versions are labelled A… Z.<br />
Note: the method of requirement validation is not included in the actual<br />
identifier, but rather separated by “/”. Validation methods include: T –<br />
Test, I – Inspection & A – Analysis.<br />
© 2004 SOC Page 11 of 193
Change language