User Requirements Document (URD) - SourceForge
User Requirements Document (URD)Computer emulator for digital preservationVersionAuthorDateProject: 1.1: B. Lohman, J.R. van der Hoeven: 21-02-2006: Emulation projectKoninklijke Bibliotheek (National Library of the Netherlands)Nationaal Archief of the Netherlands
User Requirements Document (URD)I. Revision historyRevision numberRevision dateAuthorSummary of changes1.121-02-2006B. LohmanMinor changes to text; clarificationsII. Related documentsDocument nameDateAuthorUser Requirements Document [URD]21-02-2006B. LohmanEmulation report by KB/NA [EMU]20-06-2005J.R. van der HoevenAuthor:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 2
User Requirements Document (URD)III.Table of contentsI.Revision history . 2II.Related documents . 2III.Table of contents . 311.11.21.3Introduction . 4Purpose of this Document . 4Scope of this Document. 4Definition of Terms . 42.12.22.32.42.5General description . 5Project Context . 5General Capabilities . 5User Characteristics. 5System Context. 6Assumptions and Dependencies . 722.5.12.5.234567Assumptions. 7Dependencies . 72.6Outstanding Issues. 73.13.23.33.43.53.63.73.83.9Functional Requirements - Emulator. 8Processing devices. 8Output devices . 8Read / write devices. 8Input devices. 9Port devices . 9External files. 9User interface characteristics. 10Target software. 10Components. 104.14.24.3Functional Requirements – Library . 12Component management . 12Component use . 12Interface. 125.15.25.3Non-functional Requirements . 14Speed and Time Requirements . 14Capacity Requirements. 14Reliability Requirements . 146.16.26.36.46.5Design and Implementation Constraints and Standards. 15Safety. 15Security. 15Target Platforms . 15Development Tools . 15Project Requirements. 157.17.2Delivery Requirements . 17Delivery . 17Post-Delivery. 17Appendix AGlossary . 18Appendix BRWS characteristics . 19Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 3
User Requirements Document (URD)1Introduction1.1Purpose of this DocumentThis document formally describes the user requirements for the conceptual model of amodular emulator. It is intended for review by the project manager at the Nationaal Archief ofthe Netherlands (NA), project member of the Koninklijke Bibliotheek, National Library of theNetherlands (KB), as well as the coordinator of the development team at Tessella SupportServices plc.1.2Scope of this DocumentThe emulation report [EMU], written by the KB and NA in 2005, proposes construction of themodular emulator in three separate stages, with each stage specifying different userrequirements. For efficiency reasons, a different approach has been presented by Tessella.However, the user requirements of both approaches are identical.This document describes the requirements for the final concept of the modular emulator.Where necessary, user requirements defined in different stages will be identified as such.There are components described in the final concept that build upon results achieved in theprevious stages. As the work has a research element, and project decisions will be made basedon produced results during the project, it is difficult to estimate precisely how long thedevelopment of each stage will take. As a result, the implementation of these components willdepend on time available.Requirements for these modules are marked “O” (optional) and “E” (extensions). This doesnot imply they are not part of the scope of the project, but they will be determined at a efinition of TermsEmulation report by the KB and NA. See related documentsEmulator Specification Document, specifies the components of a particular emulatorKoninklijke Bibliotheek, the National Library of the NetherlandsModule Specification File, specifies the hardware properties of an emulatedcomponentNationaal Archief of the NetherlandsReference WorkstationThe Software Requirements Document, specifies the behaviour of the softwaresystem.System Maintenance Guide, specifies how to create a development environment andcreate a releaseThe User Requirements Document, catalogues the users’ requirements for thesystem (this document).Universal Virtual MachineB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 4
User Requirements Document (URD)2General descriptionThe goal of the project is to “ secure sustained accessibility to digital objects such asinteractive multi media applications, PDF documents and database systems.” These digitalobjects are currently accessed via a standard computer system. In this project, a model of thestandard computer system, the Reference Workstation (RWS), will be used; its capabilitiesreflect those of the standard computer system. See Appendix B for more details.For background on emulation the reader is referred to [EMU]. Definitions of technicalterminology and jargon common to emulation and used in this document are included in theGlossary in Appendix A.2.1Project ContextThis document lists requirements for the conceptual model of a modular emulator. Severalemulators exist, most notably Bochs and QEMU, but neither implement an emulator with thesame objective as desired in this project (see section 2.2). As both these systems are opensource, and fall under the GNU Lesser General Public License, they can be used as a startingpoint for creating the emulator specified in this project.The project consists of a number of stages, and will produce several versions during thecourse of development. Many of these versions should function as independent products, andwill be used to assess the progress of the project and to determine the project’s course.The final product will depend on the approach used to achieve the most successful results; itis recognised that depending on the approach taken, not all user requirements may be met atthe end of the project.2.2General CapabilitiesUsing the ‘software-emulation-of-hardware’ approach [EMU], the software will be capable ofreproducing, as closely as possible, the hardware environment of the Reference Workstation.The priorities of this reproduction are, in order, execution speed, graphics, sound andnetwork. The functional behaviour of the system of the software, compared to the RWS, willbe assessed using various digital test objects.Ideally, the system will consist of distinct modules that emulate specific RWS hardwarecomponents. Once an initial version of the system is produced that fulfils the abovecapabilities, it will be extended with a library of emulated components, and a controller tointerconnect these components. This will make the system capable of emulating multipleenvironments, besides that of the RWS. The hardware properties of each emulatedcomponents will be specified in a Module Specification File, while particular combinationsand usage of the components that make up the environment of an emulator will be specified inan Emulator Specification Document (ESD). The ESD can be associated with stored digitalobjects to easily access them in the required environment. The emulated components will bere-usable and will have the possibility to be enhanced.The ideal final software product will be platform independent, able to fulfil the abovecapabilities on different host hardware configurations.2.3Author:User CharacteristicsB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 5
User Requirements Document (URD)The target group of the software product is end-users of computer software. Their intent is torun software packages to access, read and write various digital objects, including interactivemultimedia applications, PDF documents, and database systems. These objects may no longerbe supported on current hardware and software systems. This raises the need to install older,unsupported operating systems in order to run the software packages necessary for accessingthe digital objects.The group can be classified as users with computer experience varying between minimal andknowledgeable.Those with minimal computer experience will have no knowledge how to install operatingsystems or software packages. They will need to be provided with a complete, existingenvironment that is targeted towards the documents they want to access, shielding them fromrequiring inside knowledge of the emulator. Assuming they have developed some familiaritywith the environment through continual use, simple interaction can be expected to load, read,write and save the requested objects.More experienced users can be expected to install the operating systems required fordocument access, as well as installation of software packages, once provided with the correctenvironment. Accessing more complex objects, more involved interactions within the systemcan be expected, resulting in higher loads to the system.Knowledgeable users will want to create their own environments on the fly, tailor-made totheir needs. Customising various modules to create specific settings, along with custominstallation of operating systems can be expected. The system will be used to the fullest,placing the highest stress on the system. Interchanging modules within one environment totest and compare settings can be expected to lead to various configurations.2.4System ContextProvided below is a simplified diagram, showing the information and control flows across thesystem rdwareTranslated hardwareinstructionsHost hardwarevaluesTarget slated softwareinstructionsTarget softwarevaluesHost emboundaryFigure 2.1: simplified diagram of system and its boundariesAuthor:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 6
User Requirements Document (URD)2.5Assumptions and DependenciesThere are several assumptions and dependencies which form the basis for some of thedecisions following. These are the following:2.5.1 2.5.2 2.6AssumptionsThe UVM used will be the Java Virtual Machine, unless a preferable alternative isfound, or initial development shows that the virtual machine approach is not feasible.JVM will continue to be widely used for the short to medium term and continue to besupported on a variety of platformsTaking in consideration the state of currently available emulators and theirimplementation, designing an emulator for portability using the JVM might introducea serious overhead; this may influence the performance of the emulator in such a waythat alternate strategies may need to be considered.All aspects of the design are assumed to be portable, that is that it can be implementedwithin the JVM. Initial investigations will test this assumption.DependenciesDirect interaction with host hardware depends on the capabilities of the developmentlanguage (Java).As suggested in section 2.5.1, developing an emulator that solely runs on the JavaVirtual Machine creates a dependency on support from the manufacturer.Detailed knowledge of the inner workings of components is required, much of whichmay be considered proprietary by the manufacturer. Reverse engineering may need tobe applied to gather enough information.Development will be incremental, so later stages depend on previous results. Giventhe limited timescale, prioritisation of tasks will be necessary to ensure the mostimportant items are completed first.Outstanding IssuesThe list below indicates areas where knowledge is lacking or unclear. These areas should beresolved before the document is used as intended. The reason for listing them in this section isthat they are not forgotten in the body of the document, and provide a readily available list fordiscussion when possible. Author:Hardware abstraction layer (HAL) emulation (low level) needs to be researched as analternative to the current JVM approach (high level).With the JVM as suggested approach, it needs to be seen whether this offers enoughfunctionality and speed that is desired.The release license specifics need to be determined.B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 7
User Requirements Document (URD)3Functional Requirements - EmulatorThis section contains all the users’ functional requirements with regard to the emulator aspectof the system. Each requirement is prioritised as follows:MDMandatory requirement. This feature must be built into the final system.Desirable requirement. This feature should be built into the final system unless itscost is too high.Optional requirement. This feature can be built into the final system at the ProjectManager's discretion.Possible future enhancement. This feature is recorded here so that the idea is notlost. The decision on whether to include it in the system will depend on progress onthe mandatory requirements.OE3.1Processing devicesLabelRequirementU3.1.1The software should provide code that emulates a processorcomparable to a socket 478 Intel Pentium 4 single core at 2.4 GHz.NecessityU3.1.2Issues: What if desired speed is not reached in emulation?The software should provide code that emulates a motherboardcomparable to a Compaq EVO D510 CMT with [type] chipset,[speed] Front Side Bus.MDIssues: Design question: is this part necessary to emulate?3.2Output devicesLabelRequirementU3.2.1The software should provide code that emulates a display adaptercomparable to a nVidia GeForce MX 420 with 32MB memory.NecessityU3.2.2Issues: The software should provide code that emulates sound comparable tothe AC’97 specification.Issues: This is a specification, not a hardware component – is this clearenough?The software should provide code that emulates a network adaptercomparable to the Intel Pro/1000 T.U3.2.3MDOIssues: -3.3Read / write devicesLabelAuthor:RequirementNecessityB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 8
User Requirements Document (URD)The software should provide code that emulate a hard disk,comparable to a 40GB Maxtor 6E040L0 or 40GB Western DigitalWD400BB-60CJA0U3.3.1MU3.3.2Issues: The software should provide code that emulates random accessmemory up to 1 GB.MU3.3.3Issues: The software should provide code that emulates an optical storagedevice, comparable to a Compaq JLMS DVD-ROM LTD-1665.DU3.3.4Issues: The software should provide code that emulates a 3.5” floppy drive,with average seek time.EIssues: -3.4Input devicesLabelRequirementU3.4.1The software should provide code that emulates a keyboard,comparable to IBM PC 101-key keyboard.NecessityU3.4.2Issues: The software should provide code that emulates a mouse, supportingthe PS/2 protocol.MMIssues: This does not specify anything about the mouse, only the protocol3.5Port devicesLabelRequirementU3.5.1The software should provide code that emulates a communications(COM) port.NecessityIssues: Hardware specifications?The software should provide code that emulates a parallelcommunications (LPT) port.U3.5.2Issues: Hardware specifications?The software should provide code that emulates a Universal SerialBus (USB) port.U3.5.3MDEIssues: Hardware specifications?3.6External filesLabelRequirementU3.6.1The software should be able to read and write EmulatorAuthor:NecessityB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 9M
User Requirements Document (URD)Specification Documents (ESDs), which contain a list of componentsthat make up a specific emulator.U3.6.2Issues: The Emulator Specification Document should contain properties forthe emulator that are user-configurableU3.6.3Issues: Each emulated component should have an associated ModuleSpecification File (MSF) or metadata that specifies the hardwareproperties of that component.DMIssues: -3.7User interface characteristicsLabelRequirementU3.7.1An Emulator Specification Document (ESD) can be created via auser interface.NecessityU3.7.2Issues: A specific emulator should be started when an EmulatorSpecification Document (ESD) is loaded in the user interface.U3.7.3Issues: The user interface contains logic to determine compatibility betweencomponents when loading / creating an Emulator SpecificationDocument (ESD).DDEIssues: -3.8Target softwareLabelRequirementU3.8.1The software should be able to host operating systems comparable toMicrosoft Windows 2000 Professional.NecessityU3.8.2Issues: The software should be able to host applications software within theoperating system capable of running the test objects.MMIssues: List of applications necessary?3.9ComponentsLabelRequirementU3.9.1There must be at least one emulated component (and associatedModule Specification File) for every type of hardware componentlisted in section Fout! Verwijzingsbron niet gevonden.Issues: It should be possible to refine existing emulated components forU3.9.2Author:NecessityB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 10MD
User Requirements Document (URD)highest compatibility, while keeping the previous versions.Issues: -Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 11
User Requirements Document (URD)4Functional Requirements – LibraryThis section contains all the users’ functional requirements with regard to the library aspect ofthe system. Each requirement is prioritised as follows:MDMandatory requirement. This feature must be built into the final system.Desirable requirement. This feature should be built into the final system unless itscost is too high.Optional requirement. This feature can be built into the final system at the ProjectManager's discretion.Possible future enhancement. This feature is recorded here so that the idea is notlost. The decision on whether to include it in the system will depend on progresson the mandatory requirements.OE4.1Component managementLabelRequirementU4.1.1Emulated components should be organised in a library, associatingemulated component code with Module Specification Files.NecessityU4.1.2Issues: The library should maintain a component list consisting of ModuleSpecification Files (MSF) or metadata that can be used in anemulator.U4.1.3Issues: The component list should be updateable with newer components,while maintaining a versioning system of modified emulatedcomponents.U4.1.4Issues: The library should be able to provide the emulator with the emulatedcomponent code based on information from the EmulationSpecification Document (ESD).MMMMIssues: -4.2Component useLabelRequirementU4.2.1It should be possible to re-use emulated components for multipleemulator configurations.NecessityMIssues: -4.3InterfaceLabelRequirementU4.3.1There should exist a mechanism (“controller”) capable ofinterconnecting modules that results in a working emulator.Author:NecessityB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 12M
User Requirements Document (URD)Issues: The process of interconnecting modules should be automated.U4.3.2Issues: -Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 13D
User Requirements Document (URD)5Non-functional Requirements5.1Speed and Time RequirementsLabelRequirementU5.1.1The software should be able to emulate the RWS at a reasonablespeed. However, this is not a mandatory requirement because it isassumed that computers will continue to become faster (based onMoore’s law). As this emulator will be focused on future use, speedis currently not an issue.NecessityDIssues: How fast is Java?5.2Capacity RequirementsLabelRequirementU5.2.1The software must be able to handle at least 40 GB target diskimages.NecessityMIssues: -5.3Reliability RequirementsLabelRequirementU5.3.1The software should be able to give a correct representation of thetest objects.NecessityIssues: this requires comparison tests between RWS and emulatedenvironment.Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 14M
User Requirements Document (URD)6Design and Implementation Constraints and Standards6.1SafetyThere are no relevant requirements in this section.6.2SecurityThere are no relevant requirements in this section.6.3Target PlatformsLabelRequirementU6.3.1The software should be able to run on the x86 platform.NecessityMU6.3.2Issues: The software should be able to run on the PowerPC platform.EIssues: The software should be able to run on any platform that theemulation approach supports (i.e. if the Java Virtual Machine ischosen, any platform that supports JVM).U6.3.3EIssues: -6.4Development ToolsLabelRequirementU6.4.1The software design and development will be based existingemulators such as Bochs and QEMU, or any virtualisationtechnology.NecessityIssues: Java should be used as a virtual layer.U6.4.2DDIssues: -6.5Project RequirementsLabelRequirementU6.5.1Emulation components should be defined as distinct modules – “afinite set of programming code that, when executed, emulates aspecific part of a computer system”.NecessityIssues: It is recognized that this approach makes a trade-off for speed infavour of modularityThe software should be constructed in a modular way.U6.5.2Issues: -Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 15MM
User Requirements Document (URD)U6.5.3Object-oriented methodology should be used in designing thesoftware.U6.5.4Issues: Knowledge, expertise and code should be shared with the opensource community.MU6.5.5Issues: All emulator information should be documented, including devicespecifications, protocol descriptions and standards.MIssues: All modules should be documented.U6.5.6MIssues: The software should be able to read and write the format of diskimages that are used as test objects. This format is equivalent to thedisk images used in Bochs and QEMU.U6.5.7Issues: Is a description of this format available for design purposes?Differences in performance between the RWS and the modularemulator should be made available.U6.5.8Issues: -Author:MB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 16MD
User Requirements Document (URD)7Delivery Requirements7.1DeliveryDescribe any constraints or requirements the client has specified relating to how the systemshould be delivered to them.LabelRequirementNecessityU7.1.1The emulator should be released under the GNU (Lesser) GeneralPublic License or compatible license.MIssues: To be decided officially when publicly releasing first set of code.The project should be delivered on the next working day after July 1,2007U7.1.2MIssues: -7.2Post-DeliveryDescribe any constraints or requirements the client has specified relating to activities whichare to take place following successful delivery of the systemLabelRequirementU7.2.1Other interested parties should be able to freely use, modify anddistribute the developed emulator in accordance to the license it isreleased under.NecessityIssues: Future developers should be able to recreate the emulator, using theSystem Maintenance Guide (SMG) document along with theavailable source code.U7.2.2Issues: -Author:B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 17MM
User Requirements Document (URD)Appendix AGlossaryThis glossary contains definitions of terms used within the User Requirement Specificationdocument. It defines terms that are used within the emulation context, but because of theircommon use or multiple meanings, require clarification.[EMU] and Wikipedia have been used as a basis for some of the definitions.EnvironmentHostLogical resourcesPlatformTargetAuthor:The collection of logical and physical resources used to support aplatformThe platform providing the emulator access to its services and hardwarefor it to runThe manifestation of physical devices in software, including operatingsystems.The framework, either in hardware or software, which allows software torun. This typically includes architecture, operating system, andprogramming languages and their runtime libraries.The platform that is to be emulated, using a host for its resourcesB. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 18
User Requirements Document (URD)Appendix BRWS characteristicsSoftwareApplicationMS Windows 2000 ProfessionalMS Direct X for NTDisplay Drivers (Compaq nVidia LPAGP GeForce2MX-400)Intel ChipsetIntel IdeIntel pro 1000TKeyboardVersionService Pack 386.13.10.4103Filesw2ksp3.exeDX80NTeng.exe41.03 95.exe (not used becauseit only enables the functionkeys on the top of l SoftwareApplicationMS Internet ExplorerVersion5.50.4134.0600MS Windows Media PlayerMS SysPrep (in deploy.cab)7.11.1Power Quest Drive Image Pro4.0Adobe Acrobat Reader5.01Java Plug-in for the browser [ IE]InterVideo WinDVD1.3.1 02 Standard EditionInternational2000Paragon CD-ROM emulator2.5 Personal EditionHardwareComponentMain boardProcessorInternal memoryHard disk devicesDisplay adapterInstall CD delivered withDVD-ROM Drive (COMPAQJLMS DVD-ROM LTD-1665)Install cd : iso ‘paragon cd.iso’SpecificationCompaq EVO D510 CMTIntel Pentium 4 system running at 2,4GHz1 GB RAM2 internal disks:40 GB Maxtor 6E040L040 GB WDC WD400BB-60CJA0nVidia GeForce4 MX 420 display adapterFill RateAuthor:Filesie552000 directory, setup isstarted via b and Windows 2000 SystemPreparation Tool (version 1.1)from Microsoft(sysprep update)Drive Image Pro 4.0 directory,subdirectory dp40en, subdirsetup, contains setup.exeAcrobat Reader 5.01 directory,rp501enu.exe (only used ondevelopment to read thedocumentation)j2re-1 3 1 02-win-i.exe: 1 Billion Texels/Sec.B. Lohman, J.R. van der HoevenDate:21-02-2006Project: emulation projectVersion:1.1Page: 19
User Requirements Document (URD)Sound deviceOptical storage devicesFloppy disk drivesPorts (external)Network adaptersMonitorTriangles per Second: 31 MillionMemory Bandwidth: 2.7GB/Sec.Maximum Memory: 32MBSoundMAX AC97 Integrated Digital AudioDVD-ROM Drive (COMPAQ JLMS DVD-ROM LTD-1665),Region 23.5”fl
SRD The Software Requirements Document, specifies the behaviour of the software system. SMG System Maintenance Guide, specifies how to create a development environment and create a release URD The User Requirements Document, catalogues the users’ requirements for the system (this
TRD 7th Injector system to use the URD Upgrade Kit. We now we offer a complete kit in addition to our 7th injector upgrade kits and our complete 6-injector fuel kits that have been around for years providing a complete range of performance options for your 5vz supercharger. The URD 5vz 7th Injector
TRD 7th Injector system to use the URD Upgrade Kit. We now we offer a complete kit in addition to our 7th injector upgrade kits and our complete 6-injector fuel kits that have been around for years providing a complete range of performance options for your 5vz supercharger. The URD 5vz 7th Injector
The World Tree (cont.) Beneath tree –sacred spring of fate called Well of Urd –looked after by 3 Norns 3 Norns : Urd (Fate), Verdandi (Being), Skuld (Necessity) –also called past, present, future Controlled destiny and nourish earth Eagle and hawk on top –wind, enemy lookout Giant serpent at roots –trying to destroy it –
the ability for mucin secretion and the expression of membrane water channel (aquaporine 8, AQP8) were increased significantly in the Lop Urd treated group compared with Lop Vehicle treated group. Finally, the activity of Urd was confirmed in primary smooth muscle of rat intestine cells (pRISMC) based on Gα expression and IP3 concentration.
This document complies with the speci cations for a User Requirements Document (URD) by the software engineering standards, as set by the European Space Agency [2]. During the project the group will create a tool in which Oc e’s
2009 Moses receives support from EuromatrixPlus, also EU-funded 2010 Moses now supports hierarchical and syntax-based models, using chart decoding 2011 Moses moves from sourceforge to github, after over 4000 sourceforge check-ins 2012 EU-funded MosesCore launched to support continued development of Moses
OpenCOBOL 1.0 the current o cial release version, hosted on SourceForge.net, compiles on: All 32-bit MS Windows (95/98/NT/2000/XP) All POSIX (Linux/BSD/UNIX-like OSes) OS/X OpenCOBOL 1.1, has been built on MS Windows native MS Windows with Cygwin POSIX Systems including OpenSol
The publication of the ISO 14001 standard for environmental managements systems (EMS) in 1996 and then revised in 2004 has proved to be very successful, as it is now implemented in more than 159 countries and has provided organizations with a powerful management tool to improve their environmental performance. More than 223 149 organizations have been certified worldwide against ISO 14001 at .
