ࡱ> _ bjbj,E,E N/N/I\Z Z 4hPLH.p("6^#^#^#r%p5:LbHdHdHdHdHdHdHIL*dHP<P%"r%P<P<dH^#^#yHBDBDBDP<v^#^#bHBDP<bHBDBDrFG^#@zx<*GNHH0HGL=RLGLGPP<P<BDP<P<P<P<P<dHdHBDP<P<P<HP<P<P<P<LP<P<P<P<P<P<P<P<P<Z z: University of Prishtina Faculty of Electrical and Computer Engineering Kodra e Diellit, p.n. 10000 - Prishtin, Kosova Software Requirements Specification FIEK Pizza Distribution list: Name (alphab.) Department Location Document Management History of changes VersionStatusDatePerson resp.Reason for Change Persons authorized to make changes Document was created using the following tools: WINWORD 9.0 Contents  TOC \o "1-4" 1 Introduction  GOTOBUTTON _Toc424456630  PAGEREF _Toc424456630 5 1.1 Purpose of the document  GOTOBUTTON _Toc424456631  PAGEREF _Toc424456631 5 1.2 Validity of the document  GOTOBUTTON _Toc424456632  PAGEREF _Toc424456632 5 1.3 Definitions of terms and abbreviations  GOTOBUTTON _Toc424456633  PAGEREF _Toc424456633 5 1.4 Relationship with other documents  GOTOBUTTON _Toc424456634  PAGEREF _Toc424456634 5 1.5 Overview of the document  GOTOBUTTON _Toc424456635  PAGEREF _Toc424456635 6 2 General description of the product  GOTOBUTTON _Toc424456636  PAGEREF _Toc424456636 7 2.1 Relationship with existing projects  GOTOBUTTON _Toc424456637  PAGEREF _Toc424456637 7 2.2 Relationship with earlier and follow-up projects  GOTOBUTTON _Toc424456638  PAGEREF _Toc424456638 7 2.3 Purpose of the product  GOTOBUTTON _Toc424456639  PAGEREF _Toc424456639 7 2.4 Delimitation and embedding of the product  GOTOBUTTON _Toc424456640  PAGEREF _Toc424456640 7 2.5 Overview of the required functionality  GOTOBUTTON _Toc424456641  PAGEREF _Toc424456641 7 2.6 General restrictions  GOTOBUTTON _Toc424456642  PAGEREF _Toc424456642 7 2.7 Hardware and software specifications  GOTOBUTTON _Toc424456643  PAGEREF _Toc424456643 8 2.8 Product users  GOTOBUTTON _Toc424456644  PAGEREF _Toc424456644 8 3 Detailed description of the required product features  GOTOBUTTON _Toc424456645  PAGEREF _Toc424456645 9 3.1 Scope of delivery  GOTOBUTTON _Toc424456646  PAGEREF _Toc424456646 9 3.2 Sequences (scenarios) of interactions with the environment  GOTOBUTTON _Toc424456647  PAGEREF _Toc424456647 9 3.3 User goals  GOTOBUTTON _Toc424456648  PAGEREF _Toc424456648 10 3.4 Required functions of the product  GOTOBUTTON _Toc424456649  PAGEREF _Toc424456649 10 3.4.1  GOTOBUTTON _Toc424456650  PAGEREF _Toc424456650 11 3.4.1.1 Effect of  GOTOBUTTON _Toc424456651  PAGEREF _Toc424456651 11 3.4.1.2 Dependencies/constraints  GOTOBUTTON _Toc424456652  PAGEREF _Toc424456652 11 3.4.2  GOTOBUTTON _Toc424456653  PAGEREF _Toc424456653 11 3.5 External interfaces of the product  GOTOBUTTON _Toc424456654  PAGEREF _Toc424456654 11 3.5.1 User interfaces  GOTOBUTTON _Toc424456655  PAGEREF _Toc424456655 11 3.5.2 System interfaces  GOTOBUTTON _Toc424456656  PAGEREF _Toc424456656 12 3.5.2.1  GOTOBUTTON _Toc424456657  PAGEREF _Toc424456657 12 3.5.2.2  GOTOBUTTON _Toc424456658  PAGEREF _Toc424456658 12 3.6 Other product features required  GOTOBUTTON _Toc424456659  PAGEREF _Toc424456659 12 3.6.1 Performance  GOTOBUTTON _Toc424456660  PAGEREF _Toc424456660 12 3.6.2 Resource  GOTOBUTTON _Toc424456661  PAGEREF _Toc424456661 13 3.6.3 Security  GOTOBUTTON _Toc424456662  PAGEREF _Toc424456662 13 3.6.4 Safety  GOTOBUTTON _Toc424456663  PAGEREF _Toc424456663 13 3.6.5 Portability  GOTOBUTTON _Toc424456664  PAGEREF _Toc424456664 13 3.6.6 Reliability  GOTOBUTTON _Toc424456665  PAGEREF _Toc424456665 13 3.6.7 Maintenance  GOTOBUTTON _Toc424456666  PAGEREF _Toc424456666 13 3.6.8 Reuse  GOTOBUTTON _Toc424456667  PAGEREF _Toc424456667 13 3.6.9 Usability  GOTOBUTTON _Toc424456668  PAGEREF _Toc424456668 14 4 Specifications for project management  GOTOBUTTON _Toc424456669  PAGEREF _Toc424456669 15 4.1 Implementation requirements  GOTOBUTTON _Toc424456670  PAGEREF _Toc424456670 15 4.2 Ready-to-use and bought-in components  GOTOBUTTON _Toc424456671  PAGEREF _Toc424456671 15 4.3 Subcontractors  GOTOBUTTON _Toc424456672  PAGEREF _Toc424456672 15 4.4 Acceptance conditions  GOTOBUTTON _Toc424456673  PAGEREF _Toc424456673 16 4.5 Terms of delivery  GOTOBUTTON _Toc424456674  PAGEREF _Toc424456674 16 4.6 Requirements for use  GOTOBUTTON _Toc424456675  PAGEREF _Toc424456675 16 4.7 Warranty  GOTOBUTTON _Toc424456676  PAGEREF _Toc424456676 16 5 Obligations of the client  GOTOBUTTON _Toc424456677  PAGEREF _Toc424456677 17 6 Literature  GOTOBUTTON _Toc424456678  PAGEREF _Toc424456678 18 7 Annex  GOTOBUTTON _Toc424456679  PAGEREF _Toc424456679 19  General remark: This commented table of contents of a software requirements specification relates to projects which deal primarily with SW development. Introduction Purpose of the document The purpose of the software requirements specification is to produce a specification for which is binding for the development and is as unambiguous as possible. To this end, it contains the sum of all the requirements which have been made (and accepted) on this product and project management from the perspective of the project. Validity of the document Which area does this software requirements specification apply to? Does the software requirements specification apply to a specific complete project? Does the software requirements specification apply to only part of a project? Is the software requirements specification based on an existing software requirements specification? Is the software requirements specification based on an existing product (new version, delta software requirements specification, etc.)? This is also a good point to say a little about updating of the document (who is responsible for changes, e.g. for version development or maintenance project?). Definitions of terms and abbreviations List of terms and abbreviations which are important for understanding the software requirements specification (IT expressions and terms from the application domain). This list will normally be in alphabetical order, but it can also be organized on a hierarchical basis if necessary, such that more specific terms (e.g. transaction with a cash dispenser) can be identified among more general terms (e.g. transaction). The term definitions are particularly important since the software requirements specification represents the common basis for ensuring that the client and contractor are talking the same language. If these terms occur in normal text, they should be highlighted to identify them as technical expressions. Example: IT information technology MTBF mean time between failure MTTR mean time to repair Relationship with other documents If no tender exists in which all the requirements are described on a legally binding basis, the software requirements specification will represent the binding basis, agreed between the client and contractor, for the development work and product acceptance. It is therefore equally relevant for client and contractor. If a legally binding tender exists, however, the software requirements specification will generally only be relevant for development on an internal level (unless agreed otherwise in the contract). In all matters which relate to product features, project management and the clients obligations, it is important to ensure agreement with the tender. No statements in this regard in the software requirements specification may contradict any statement in the tender. If a user requirements specification exists, the software requirements specification must refer to the latter as far as possible in order to ensure that the requirements described from the perspective of the client or user in this user requirements specification can be traced to the requirements made on the product in question and the project management. Unlike the user requirements specification, the software requirements specification must specify precisely what a product must be able to do. These details in the software requirements specification define how the product which is to be created satisfies the requirements set out in the user requirements specification. Overview of the document What is the content of the rest of the software requirements specification? How is the software requirements specification structured? General description of the product This general description of the product being created must take the form of a Management Summary, i.e. it should not describe specific product features. Relationship with existing projects If the project is related to existing projects, these should be outlined in brief in this section (e.g. umbrella projects, sister projects). Any interfaces which are required must then be described in section  REF _Ref398436595 \n 2.5 or in the full description of the system interfaces. Relationship with earlier and follow-up projects If the project is related to earlier or follow-up projects, these must be outlined in brief in this section. If the product is to replace an earlier product, section  REF _Ref398436606 \n 2.5 must describe the reasons for the new development. Purpose of the product What is the purpose of this product? What are its important features? What key advantages does it have over the current situation? If the product is to replace an earlier product, the reasons for the new development must be described in this section. Delimitation and embedding of the product This section must describe how the product to be created is delimited and embedded in its environment. What key functions is the product to support? Which will it not support, i.e. what belongs not to the product but to the environment? This description of where the system begins and ends must be consistent with any superordinate documents which exist. In the event that a user requirements specification exists, but significant restrictions in terms of functionality are to be made compared with this user requirements specification, these must be described at this point. How is this product related to other systems in its environment (e.g.: Is this an independent system or a subsystem of a larger system; does it replace an existing system?). If the product being created is a subsystem, the basic principles of the superordinate system and its relationships to other subsystems must be summarized at this point (e.g. in the form of a block diagram which shows the components, their interaction and the external interfaces). Overview of the required functionality This section must provide an overview of what the product which is to be created has to deliver to its environment (e.g. human users or other systems). This description is merely meant to provide an overview of the more detailed product description in section  REF _Ref398436624 \n 3. General restrictions This section must describe the key specifications which restrict the development and the product (e.g. specifications as regards interfaces, standards, methods). Hardware and software specifications Which HW environment is the target system to run in? Which SW environment is the target system to run in? Which HW environment is the system to be developed in? Which SW environment is the system to be developed in (operating systems, development tools)? Product users This section is intended to set out which users are to use the product to be created (e.g. prior training and knowledge in the use of software and computers). Different user classes may exist (e.g. production users and system administrators, daily users and occasional users). Detailed description of the required product features This section of the software requirements specification must define the product features requested (prescribed) by the client and agreed to by the development department. These features contain all functions, interfaces and other product features. A number of points should be taken into account in describing the features: Every required feature should: be uniquely identified be prioritized where necessary (e.g. with regard to releases) contain the origin of the requirement if there is any uncertainty as to who requires something if a user requirements specification exists, contain references to the relevant requirements in this user requirements specification (preferably with reference to a unique designation) (source); if references cannot be made to all requirements in the user requirements specification (if the functionality is restricted), reference should also be made to such requirements in the user requirements specification, complete with appropriate notes. Each required feature should be described so that: there is as little room for interpretation as possible (clarity) it must be possible to check the finished product (has the product been made correctly?) Scope of delivery The scope of delivery must contain a list of all deliverables (product and its subcomponents, project documentation to be supplied, user manuals, training documents, training, support in the introductory phase e.g. in the form of coaching, installation procedures, migration of data stocks, user support in the form of hotline or e-mail, etc.). Those components which do not form part of the product in the narrower sense (program), e.g. user documentation, training, etc., must be described accurately in this subsection; the product in the narrower sense is described in detail in the following subsections. Sequences (scenarios) of interactions with the environment This section should describe typical sequences of how one (or more) user(s) or another system in the environment of the product to be created interact(s) with the latter. Sequences of this kind are often termed scenarios. If such scenarios are already described in detail in an existing user requirements specification, they can be adopted from that user requirements specification and augmented where necessary. While it is generally not possible to describe all possible scenarios completely, a certain degree of completeness must be ensured as regards important relationships with the following functions of the product being created: It must be possible to use appropriate functions to implement all actions which the product must perform. Reference to these must be as accurate and explicit as possible (e.g. by function in 3.4.x). This is intended to ensure that no functions are forgotten. Each of the functions to be described below should occur in at least one sequence. This will ensure that no functions are requested for which no-one knows why they are needed. Likewise, it is recommended that references be made to the relevant interfaces described below in the case of all actions which are to be executed by users or other systems in the environment. Similarly, a certain degree of completeness must be achieved in terms of important relationships with the users goals to be described below: All scenarios should pursue one or more goals. If a goal is not immediately apparent (in the case of simple or short scenarios, for example), a reference must be made which is as accurate and explicit as possible. This will facilitate understanding of the scenarios. It must be possible to achieve each of the users goals described below through at least one sequence. This fact will demonstrate that these goals can also be attained using the product which is to be created. User goals This section should describe all user goals attained through the interactions with the product as described in the above scenarios (e.g. the users goal of having (more) cash will, in the normal run of events, be satisfied through his interactions with the cash dispenser). This makes the scenarios easier to understand. Generally speaking, several scenarios may be suitable for attaining a goal, or several goals may be satisfied through such a sequence. In any event, references to the relevant scenarios should be made as accurate and explicit as possible. In some cases, it can be useful to take a more general approach to investigating those of the clients goals which go beyond the direct goals of the user. Since such goals do not have so much to do with the scenarios, however, they should be described separately in a subsection of their own or in an annex. If this could cause problems to occur with the client, such goals should not be described at all in the software requirements specification. Required functions of the product This section must describe in detail what the product to be created must do (the description must be made from the perspective of the systems reactions; the requirements from the sequences must be depicted). This description must agree with the overview of the functionality required (in section  REF _Ref398436664 \n 2). A hierarchical functional structure (function tree) is generally suitable for the description. There are essentially two options for the hierarchical structure: 1) If specific functions are described on all levels, the subfunctions must be assigned to the superordinate composite functions. (For example, the specific function Identifying a bank customer includes (among other things) the specific functions Request to enter a code and Check of an entered code.) 2) If specific functions are only described on the lowest level, classes of such functions must be defined and the specific functions must be assigned to the relevant classes. (For example, the class Functions for identifying a bank customer by a cash dispenser consists of the specific functions Request to enter a code and Check of an entered code.) If a composite function (e.g. Identifying a bank customer in this example) requires interaction with the user when implemented (here: entering the code), it may be best to perform hierarchical structuring in accordance with the second option using classes of functions. In this case, every such class (Functions for identifying a bank customer in our example) should make up a separate subsection of the document which describes the associated specific functions. In principle, it is also possible and often desirable to define more specific subclasses for such classes of functions in order to achieve a more detailed hierarchical structure. Each description of a specific function must contain a unique designation, a description (effect from external perspective) and, if they exist, dependencies and constraints. Each function must have a unique designation. This designation should be used in the projects life cycle (i.e. Design, Implementation, etc.). Effect of This section must describe how the function works, i.e. the effect which this function of the newly-created product has on its environment. This should be done in sufficient detail so that only one interpretation of the functions effect is possible. Dependencies/constraints This section must set out any existing dependencies/relationships with other functions. This is designed to ensure that, where changes are made to a function described in this section, these dependent functions can also be examined selectively. In addition, this is intended to prevent any possible redundancies and, in particular, contradictions. Where significant constraints apply to any function described in this section (e.g. affecting the speed of the product when applied), these must be described below under the other product features and a reference made to these in this section (e.g. by referencing the relevant speed feature). .... External interfaces of the product This section must describe all user interfaces and all interfaces of the product being created to systems in the products environment. The external behavior, i.e. the interactions between the product to be created and its environment, should already have been described above in the form of scenarios. This section primarily describes the appearance and functions of the specific interfaces. User interfaces This section must describe how the product communicates with the users. In applications using graphical user interfaces, the subdivision should be oriented to the visible elements. When describing the user interfaces, it is advisable to subdivide the description into a general part, complete with details of the general setup of the user interface (e.g. Subdivision into menu/screen/status bar, How are Help Pages constructed?, Use of OK/Cancel buttons etc.), and into specific descriptions dealing with the individual parts of the user interface (e.g. entry masks, menus, etc.). This section should not describe how the user interface is implemented internally. Any specifications on the part of the client regarding the libraries which are to be used or GUI Builder should be described below in section  REF _Ref398436685 \n 4. This section can also contain references to prototypes or feasibility studies (increasingly, user interfaces are not being defined on paper). Examples of aspects which need to be described: Input data Dialog, user prompting Commands, control parameters Menus Entry masks Graphics Output data Logs, lists Operating messages Error responses Help texts Control elements (arrangement, function) Displays and signaling (arrangement, function) System interfaces This section must describe all interfaces to software and hardware systems which the product created will communicate with. It is important that every system interface of this type contains an appropriate designation, and a description of the communication type, data format and other details. A rough overview has already been provided in section  REF _Ref398436705 \n 2. If the system interfaces are so complex that this overview is insufficient to ensure a good understanding, a more detailed overview must be provided in this section. It is important to ensure in all cases that the relationships of the individual interfaces described below are unambiguous. Syntax/semantics of the interface data Data format Program interface Transfer protocols Data rates .... Other product features required This section deals with additional product features (often known as quality features) which identify the product in greater detail and extend beyond functions and interfaces (all additional requirements which need to be satisfied). To decide what really needs to be recorded in this section, the various reasons for a description should be considered: Explicit requirements by the client which the contractor agrees to meet. Additional important product features, even if they have not been requested explicitly (this plays an important part in safeguarding both parties since it prevents misinterpretations and incorrect hopes): Few things are really as straightforward as we would ourselves believe. Where no requirements relate to a specific subsection, this should also be documented (e.g. No special safety features required). Performance This section describes the features which determine the speed of the product (required values). Standard formulations such as rapid response times are required are to be avoided. Exact values should best be used. A number of examples of speed features include: Real-time, time-sharing, batch Response times Startup times Throughput rate Holding time Resource This section describes features which specify the resources required by the product being created. Inaccurate formulations (see above) must be avoided (latitude for interpretation!) Examples of resource features include: Data quantities CPU requirement CPU utilization Main memory Peripheral memory Peripheral units Output quantities (e.g. paper) Personnel required (does the system run unmanned or does someone need to respond to possible messages?) Security This section must describe those features which are used to protect the product from outside manipulations (against unauthorized access, violations of integrity through simultaneous file access, restrictions to read accesses, virus protection, etc.) Safety This section must set out all features which enhance safety. This covers features which limit damage after a software error or system failure. These include, for example, all forms of data backup or error treatment behavior. Considerations of safety features can be useful in identifying critical software elements. Portability This section must be used to list all features which support adaptation or portability of the product e.g. GUI tools, ANSI-C or similar. Explicit reference should also be made - where necessary - to all points which are of relevance for porting or adaptation. Reliability This section must define all features which provide information on the reliability and availability of the product. These can include failure times in minutes/year or mean time between software errors (MTBF = mean time between failure). Maintenance This section must contain information on product maintainability. This can include component structuring, the use of CASE tools, design tools or design methods, and information on the mean time for software corrections (MTTR = mean time to repair). Reuse This section deals with the requirements made on the product or product parts which enable subsequent reuse (e.g. increased standardization, modularization, documentation, etc.). Project-internal reuse, on the other hand, e.g. standards (templates, structures, etc.) and methods, etc. must be described in the RR plan if it has not been expressly required by the client. Usability This section must specify any usability features requested by the customer or implicitly requested on the basis of the user classes (see section REF _Ref398436723 \n 2). These specifications can include e.g. the maximum number of usability problems that may occur in a usability test in the framework of the acceptance tests using actual users. (It is also necessary to state that these actual users, for example, stem from a user class with little experience of using graphical user interfaces). Specifications for project management This section must describe all specifications relating to project management which are relevant for the client. All further specifications and conditions must be set out in the project plan, CM plan, QA plan or RR plan. All statements which are made must agree with any tender which has been submitted, i.e. statements in this software requirements specification must not contradict any statements in the tender. Implementation requirements This section must set out all the requirements and conditions for product implementation within the framework of project management. These include HW/SW, tools, methods, etc. Examples with explanations include: Hardware Development computer Operating resources for development work (printers, measuring instruments, network, etc.) Test installations Software Operating systems for the development computers Standard software for development work Languages, shells, compilers Class libraries SW tools Other Development method Design methods Provision of QA certificates Confidentiality class for development activities and documents Ready-to-use and bought-in components This section must describe all ready-to-use and bought-in components which are needed for the product or project management. Standard software Reused own software or software from the client (see section  REF _Ref398436789 \n 5) Operating systems Third-party development Subcontractors Depending on the contractual framework, subcontractors may need to be made known to the client. All subcontractors and their contributions to the product or project must be documented. Important delivery dates can also be included in the software requirements specification. Acceptance conditions This section must set out all the conditions which are relevant for the acceptance. Examples include: Framework conditions What will be used as reference for the acceptance? (Generally the software requirements specification) How will the acceptance be performed? (E.g. during the course of a joint acceptance test at the customers, or SW will be dispatched and acceptance will be performed with the involvement of the customer (complete with error messages and deadline)) Who will provide the test data? When must the test data be provided? Where will the acceptance take place? (E.g. at the customers, at the customer installation, in the development environment) Who signs the acceptance report? (Customer, development) Acceptance criteria Definition of the acceptance test At what point in time will the acceptance be considered acceptable? (E.g. residual error rate) Are the other features set out in the software requirements specification complied with? Acceptance documents (e.g. test records) Are additional documents required for acceptance? (E.g. certification of reviews with review reports or tests with test records) Specialist reports, safety certification Must specialist reports or safety certification be provided? Satisfaction of provisions and standards Does the product comply with prescribed standards and specifications? Terms of delivery This section must set out all terms of delivery. The terms of delivery must be agreed with the client. An accurate examination of the terms of delivery can also be very useful for the  REF _Ref398436816 \* MERGEFORMAT Obligations of the client section (section  REF _Ref398438025 \n 5). Set out below are examples of terms of delivery. In essence, the following questions need to be answered: When will the various deliverables be delivered? (E.g. delivery plan with dates. It is important to check that all the deliverables described in the scope of delivery are covered). How will the individual deliverables be delivered (delivery form)? (In electronic form, paper, tape, floppy disk, in source form or executable code only, etc.) What are the requirements for delivery? (E.g. documents to be provided with the delivery; these can include certification, permits, patents/licenses, QA certificates, etc.). Requirements for use This section must document all the requirements that need to be satisfied during use. In particular, they can cover requirements relating to the course of action in this phase. Examples can include, for example, special requirements relating to trial operation or the provision of personnel during commissioning. Warranty The Warranty subsection must document all agreements which are relevant for the product warranty. These can include e.g. term of warranty, scope of warranty, error reporting procedure, etc. Obligations of the client This section must list in full all the obligations which the client has within the scope of the project. Section  REF _Ref398436862 \n 4 may already have covered such obligations implicitly (e.g. in conjunction with the hardware prescribed by the client for project management). Nevertheless, this section must set out in concise form all the obligations on the part of the client (e.g. that the prescribed hardware must be provided by the client in accordance with the agreement concluded). When setting out the various requirements, the latter must agree with any tender which exists, i.e. statements in this software requirements specification must under no circumstances contradict the requirements in the tender. It is essential with many points that deadlines be specified (otherwise delays may result, for example, as a result of the client not supplying the necessary products in time). Examples include Provision of hardware (e.g. development computers) Provision of software (e.g. tools, licenses, standard SW, clients SW) Provision of documentation (e.g. of existing systems, signed user requirements specification, SW documentation) Obligations relating to training (e.g. training of developers by the client; client personnel requiring training) Responsibilities and contact persons at the clients (responsible persons, contact persons and project managers of the customer; any client-supplied developers, testing personnel, project assistants, pilot users) Preconditions and organization of tests (test data, test environment to be provided, etc.) Infrastructure (e.g. provision of rooms, computer center, cables, operating times, etc.) Installation requirements (e.g. preinstalled HW, access to clients installations, availability of specialist personnel with workplan) Clients response times to queries Procedure to be adopted if changes are needed to requirements Validation of user interfaces and program parts during the development work (prototyping) Etc. Literature This section must set out all the documents quoted in the software requirements specification. Annex If necessary, this section can list materials which are not covered elsewhere in the overall structure of the software requirements specification defined here, but which form part of the software requirements specification. Examples include models. These can be both in text form or in more or less formal notations (e.g. in Z, VDM, SDL, Entity-Relationship diagrams and/or finite state machines). Such models may merely be used to better understand the application domains and their relationships with the product which is to be created. However, it is also possible in principle and, in many cases, is also advantageous relative to the effort involved, to use models to represent the requirements themselves (working on the basis that the product which is to be created should be the same as the model).     Page PAGE12 /  NUMPAGES \* MERGEFORMAT 19 Copyright University of Prishtina - 2012For internal use onlyAuthor:Inspector: Dept.: Name: Tel.: Signature:Dept.: Name: Tel.: Signature:File: FILENAME \p \* MERGEFORMAT D:\Universiteti i Prishtines\Ligjeratat\Software Engineering\Project Templates\2. Definition Phase\FIEK Software Requirment Specification.docStatus:Date:File:Project file File directorySect.   STYLEREF Projekt \* MERGEFORMAT  Software Requirements Specification  STYLEREF berschrift \* MERGEFORMAT Contents  STYLEREF Version \* MERGEFORMAT  Software Requirements Specification  STYLEREF Projekt \* MERGEFORMAT FIEK Pizza  STYLEREF Version \* MERGEFORMAT   STYLEREF berschrift \* MERGEFORMAT Contents Page PAGE18 /  NUMPAGES \* MERGEFORMAT 18  STYLEREF Projekt \* MERGEFORMAT  Software Requirements Specification  STYLEREF "berschrift 1" \* MERGEFORMAT Detailed description of the required product features  STYLEREF Version \* MERGEFORMAT  Software Requirements Specification  STYLEREF Projekt \* MERGEFORMAT FIEK Pizza  STYLEREF Version \* MERGEFORMAT   STYLEREF "Heading 1" \* MERGEFORMAT Annex GH^noxC D W X  1 : Y Z h i x ~x~q~~~mc^cUh%mHnHu h%6jh%6Uh S h%5CJ h%CJ h%5 h%5CJ h%>*CJhEh% h%CJ$#hhH=CJaJmHnHsHuhhH=CJaJmHnHu#hhH=CJaJmHnHsHuhH=CJaJh){hH=CJaJh){hH=5CJ$jhH=CJ$UmHnHu!H^xyz{| - . /  <  <<xx1$$a$gdH= $xx1$a$gdH= $xxa$gdH=/ C D W X ` g l y <<$If<<$<<a$ YOOOOO <<$Ifkd$$IfF    r~{ p#0    4 Fa YOOOOO <<$Ifkd$$IfF    r~{ p#0    4 Fa YOOOOO <<$Ifkdj$$IfF    r~{ p#0    4 Fa  1 YSJAASJ  <$<<a$<<kd$$IfF    r~{ p#0    4 Fa1 = M N X Y  \  u 4 ]u1A_<<x y     # $ ? @ W X Y [       < = X Y p q r t   / 0 1 3 i j $%@AXYZ\h%mHnHujh%UmHnHu\<=XYpqrt,-.0GHcd{|}#$;<>@gh%&ABYZ\^h%mHnHujh%UmHnHu\_tf`9cinX7 :;VWnoqs,-HI`ace|}&'BCZ[]_op3468KLghh%mHnHujh%UmHnHu\)*EF]^`bst   /0KLcdfh45PQhikm  h%mHnHujh%UmHnHu\:;RSUWtu1246789Q+R+h+i+l+m+z,{,,,,,<3=3S3T3U3V3oCzDWEGJJJJJJZZZZZZ]]]]]]mmh%6B*phjh%Uh% h%6CJjh%6Uh%mHnHujh%UmHnHuL79:G`D1 !a""""#'#I#$$L% @ & Fgd X$a$L%W&X&()b)))\**++,,d--.m.n..j/k/H0I00282 & Fgd X $ & Fgd X$822X3m3444i44435A55V667778F88b:c:::0; & Fgd X $ & Fgd X$ & F^`gd X$0;B;<<==>??c@d@mABBBBnCoCzDLEWEFGGIIkI & Fgd X $ & Fgd X$ & Fgd XkIgfNp9J҈:"$:ZX$cΘS\}}I%M]O(%OP#GHEcrܿ_ryWvLgGQޮ&[9vK?΃Lִ;Vݾ$0F|y߆AvN}n.cGl: ?kZyVY߲lQrNꪘ_ʣ7;uJb9~TQS1Gojw՜-*6-״hMv?oe{uR]9yPs9N;'\3U9+A e&(9~\y}GVS&+"oZV￩߿_KN J) QN>Tu*ZSazg kVp>DWz 6Mc&+7{8I,qzE8_{gW͵>[ шYF'NگeHRwML !g7q7u}EI6D6"݌ڊ~^M}<Koik|Ŝ(%u;IF0j}I0vYԝd7Ϡgk5 r ~:hjD D#E&hj}=w83ߊXKW-ko89B4{WgЇb9NIusY{xYqb6.Z V 1F'>2]$HMU ш4&bpO#f]&^fI'2FBK D؍0,‰H']}~>W>Mi8CYaD _ D"?%O1DL f\h#INۮ0Hx $5&mD)hF==hڌy*όqиIgH%Eqsxh8E\MFDND망pS0 8H?sKNs?F]yFd9ubĒNI<^$$t/)Me~Ɋ#2ĒN"i3s XőN,i##byO};Q:I 8Ẁ*(Ľ3 (bs8JPr(ñ*ʢ5k[Sz_E"D Oqb1E0a4_ƞ(Ӕؔr(ʳ~Wqbq歄$(eXCc5ʽ׸'FeI1^ P_i~HDqCQOPh KƖ1g^ ٣B8)q Ptr'W14\ʂ8 #>*sIB_3IbI$q:19B:I,@1_DS.6BumWU$&CLRz*r8fT|8I*6^'byO}& !($I7>$FGsՌ$tPPgraKIhVU)bĐ6slY.lϸY`A-gGtNׅwq7`Υ$n@9ʻы1ͱ+|xK\yv/8%qOґt so|S G4`Ry@pALLI1|a6scgJq>(6s/r8'7c?soNd0dd`ɲT%RQ23Q{jy}\ɉɎlqOf霗^uO"}+\YEQE{v}qs@TBeNTCu oM2jFmڪMun/ u5\\&'AՒKjZT 1Ϋ&笪*,gX^} 0,bY>j-9svƜ͊=+?'YU4{3b%&,c-}F/I)7즼gݐF43PN@9AK;i㤏>ƟZ#1LNix9Cs;O;\VK/I+D%JG\\r#rqrUR2^2L$ d:0պ.S:n$ϘȜ{2GҨyZ}ߴHR>Ip^ϧr_>-YH ik!m/R͖L"1#2Y<5SW39lC,]|)dl<13h|.de,,/ZXXCXGz=6x6w6[d 5l԰;(R;(;ȱ~AQcl'pDrn/#W")kdVvclF0-nMhmo\)ѭckww]e\]/쌸Eh-_+=>H]{{;j3C#=CGOx~'ǭ̢M~Qf(3p!z23tLc.b &c&bcyb eFcF`8FRjxZL˃@z4^ԟmҏ7I_y9q8I'arué#iE0v#L N0#(c7~c8~ pg{W(p_o6.}d oƛe:oYqfc|h>yPS|FQb_B;Kio.com\M\[r-oui9cZx_rחo)cZBżQ9u.o; >Mc>>GpmPlM,o6M2y<~`bdfi.l.\93O:#zOZROHeQOHTO%_O%PoQF%H%TfB>6o'O~!Cl.Ԫq򸂈 Q^OTg W]U"wƧn|J'|w5uF/Dǵv}U *tAt[љok;ʊ (os7oj 0 E<c ?Ѿ>1I9C֛s8֗o#|;L50VUHh1{i 0 >e>ahSI?l&N晝³;gx: <۳6j\ag+$X lj_Vb+˰o_` }X̪_6z|<XaѦqK^#P>>Na߽[7,gs߄'eme.mVc Eȃo)k}H݉x$DVAYId'՟++b]bȸhʎinsa(\e8++bFI m")>TE5@MBmˬYucɯ>+s. e$2GX93VSX׮]u6U~sxW:yG\ȉl1x2KV"fM ǮĬlҘd'헃trrMȃVOœ!̅:Qz\7xJ#/H#Xjr&yZڔ3XF]ԑEv~?p"e,vʠ4J׊_lVl#t.|&kqשJ\EڨKzOuq 6a#6`zאXYE4Vbu˭RXX˹uXk63g[VթIjlx3ng6$b3s  X\%aXi"D{F'+9q1ZLͤ,̶Khc%q:9sy!A`WVB04z8"ј2QhBMьSo4bh'h}hI_Zѯ co˸[YIiV,s\Đ'9&R480jL[J5~+ba\ 6x>1 1kS15ӎ  cY%K9 ɻ+)jx u6q?q_qsssK UG5T%eT|EI]oPgy~VY|Џ*IK腜ǵ3 k&y+P"*ʨB]UQzjjZ2ưy\%XEXO<);:fbMTLɘ˵1MQp `1x`B_ߡc(qDcg47X##Fk$ìԷY]2Ak^fdk/}D^G>yS?b,|B4Y?ɇ'@_d ̜\U5H oKOO/}Az>I}9ʵ=ґ;V{jO;_qEZ%Z5sӆy1lN{lO:kj +I_ĥ d3NԷi;w*kys0~Y}_QȢYY\9Ӛ3i:gac6ި+t13~Eկ8Xtaeօ##ȏ|I]F%)M:9;N:1~#w $9L8_j6aim[:WGF]O=Q_R]I-,'.ו JʳktEڪ60f~n.⒎R HڈTWPWiDl0릎VIb 8`F[Ywwu_Ѹ߷ׇ_86z+e"| e[>7Xi8E4s_7X!|&bcbMeG?z8a,?;YvP=tGՉI&wT?䣮fs3܌59k}d1>UX5i>k~u(vQ_Cf@bKX֚/D :B<҇>"b-!CX_s%`BF'h!032ϼ m Ϭ1ysҜtKη$+Wbi}k=1ZY-S;ed~h5W6I̅Vs{_K4:91㘗X"e4k~X4FzF9Rw&1iHҁ"8 'm4.#J4BPuRkD p%p||7*^% ǜʨVE5TGMΙg9@=z҇ G.w??}u%Kp`F4Qdoi{LhcFE:X~>f}[g1Gu:̅Gøk3fW=jvmyvfO%~ދcʯ8m;#GGʽ=&O.Ġ iO? r/8%ȳy=; 6|L`G£W{x'AxR0X{z/;/a0 +3cK8~7v&?OD3I_MgD҉r'Na-Z/Os2^3FaI5^/Y'#}-g<1l1+r3er |M7axw/7T^Tiz):  G?<*ю~,JBq=S*:TuP9ءrCh?8F&8VfhNq8?-:Y1G%-C^$ɓ)Ol0^q~` ]3'bkkFa$_Fi$#9By#҈lhHOC: i^v5<陂tNco6o?s1?6x KYYFf94H~U.}9r!?Y>~r|&}Sv/m:}>m|lwȷ1?n0O>|\9r[Zz| h_ɜXpy2NQTi8vvb>=]694/xmǯ@[T>pnW?p[ƭF ]HYH.o1VRĝ};>զV{nԞ3hkA[ ZKNi{ӛʍwD'9θ]2n ܉v[O +{ }^;۽͝Ksyco6|>|d6Ӗ6W--6f͐{SnoT1Av<ߎ(p~c}O$/ ; 1y}xKPxA1W0 #^ '1s Sm6)!3t1n>)fo41*S):Y|'aXO0x`t_)Rxcz o8.cg;ˌel-ck[JYCV'^ʗRvS?k4k}Nݽ]WVRl]QLr\Nr) ZPŠ|BJ-V]U.^rT%$,bo_ďU*su~_W뫍5~]Wc`Q{Xl-*e;Vvb7#FXPO`}\U q5QanvqhK|`->(׉ Ca8DbbAQ9T>:OPpPT /Ԏ*J55aMGuk9E5 D5 UZ*?]Ϛ}Q`uuS("'_ڋ:ցI֚5'aIXݺڔZԴu5#nA5ja~\鿰f>\W;6Wӫ̛U*NJUtڿ" +Vb+6ѽ$;>l6cjk>~ լ;麗21 (+PyET}~cRYTOUWh_}R >,ʠy1~.c۸R:Vcm1+6"cradn4wߘͅmcyrSYl>W!ހl5`[)q}곑3u?3Jhf~qZ$S̛Sq gyVlΖ [-.v=)byRJ_]Q+uH_^joxNRV8ʝ`:q:'B o'۱ [}Nߓ/B{O8Aqhfhc3$y;kQ&D;hgc ߛhZIS 4sl4O8<АpxHZd&j:TE%{+ml}؊ uzo2 K5k㼌ssoL"Z͎rurM|)z "o,SJs*]o671G5W`ζ6n'܈ipzHOJvv]Ѕr[ nWAwЦf)"nLh}͸3ě?O2>6n^7^˷>~w .N~mq6_+;u~t]֥^~}ziW =m$4!.=(@qdɔǣ^>_5GFci28cQ<"ZOMDNK-S8aC21mǍ;$w&"we,p ,, ǫUU)ߓų0Sٙ$K/3|7q4cǯS#1X O(SׁWw^v/>z{)g4}T(7RLMjeԋSs l Kh4|Ox,)}^`ۃ>8;YODഄ)I3Ycd ζ1 teo&47oFo08~xA]=ظE{vޣ]vݭ=wſT8-q6Jnw庋CwuW7=!=^lbAO~cw|:.@+"\Kq. o~^Jz*Z\c<]c]c\k\k\k_c\c>\c^\MCy*vG_F;\ǘV5ʜ _ʹ'X%#رZczጇ^mNIL5˞GC^g3xV?ǟgD鸍Zd`v‘~hO\Sm*۱ 4I%G߇|Q8mc~uviFKsȑ*McU`~-v&l1fXGq}6  YPRg5Z\@5; xq4# 3YgCCSdɌA eR<(&=)ϒ}9,p66׆<_9~b_D#1">s#(k2MrG4YuNrg4w G8+|.𱳻"R>ped8[%Ψ/8{SOw6l`f,2%6N4H 㻹3ͩVJ 2p"Ng1dLlfMs3ŕdW6V$Lt3&HGfX"n&*뇬4}dW@?d-_~TWrIֻKNNw7#c}J|?XEVg!(6c]R|ҕ@JsW{)3W&Gl|D +⻖_s\~ 6U W)3 jG`L#35cnގvw'0,$XOX,y/smugeڻw{Yl{/d`A)޳eE賄%R!;n˔(`ntȕ+)[Ȕ^[toek+[U̶Kإm~b1 ݵXg|1".hY< Lp$e1X wJg; w ,XLÒ;{OR>%?(cGāMY.^Tż|/}ÇG##=P0؝;fg5 ՝AK)[NwXw$$wa7 {2'#Ww&'Dd\|HKQ/VwP . w.]Я]5X*|߯́8I7܃bt7(~.p:QrzulɘΘΘ>a]|nLXX*VѻN|[&r?_ſ;տ+a kCW+)Eczڻn[ɯ.>n~ x>b(} *ʨT¾*./yhdnF$ QYVtmw.܍{Mٿ>ܯă> .S͗ ?z?}膮wN܁ۑfF*_iVHWGm@o;hsm`wNbYխ=fl}mm7s36؈ s%$fB+d6#͎͖ٳA+ɨX97L95ȐM!{L^jR٩ \iT%x/B| \]k߷QoI-2v$} 99+98'Mp (4Ƒ6h@_}>BNa&6)Spy_8*aF:pN'"!E[b[vk|cߎ~1Ntt sqhԬ9,j#ͨ#:ܯNÄ ;zfaY̬kգul]=\WOzFA=(i`$5I^6;; GɁ oo(x{C)9 ƆI8ESq:pZ 9ld,`4O7"SԠ5 ˯~5~T+\Qt5֞6v6}%?cĦ5ÓSNsT:M|Ob}%g釳~jZ:Rԏ-yU6'esR/+%/,2Pvb+%*ZU_=")wHT?Z~]Ȏ6++o}Y}k~\>B@}ہ6mOߠX&\;Q%|1czlOArzϫycΉΞ9g<=:=]s+\sQU=[W8ZԳmȚwgG;K>Ǚr;JWI]Ή;Y@W`tsP/uG澩N]U%@5LLm,EQ>,r՝ x9x=cb ѪZp_Ot6Z(fN':U=9^98x;y{}Z| UnAKCcr-m73>&h{_R)U]iB[{ZnֹeY2?-)M?6»yo(S.*!U6kj{B#Y"{cz|/9s7zָ׳CLπ-gqN\8Zge jayF/GZٸP;:cBìe:~:GXk5;ӝneDc%ĥZ4gh ,b˵Ƽ87xՀw VuEDžZRG?ӺZ9SkGkHtEZH"w6ɃEV"]Aˉ|YGrAbDe# rGͷ`_ZO\_}ooZ.RZ}4- h;Wf"kX-z= |7ؾJՍvYZ8ԙGڿt5׋p>5+G^4}ygOP O9(W/8Ca4L5O>Wb$$If!vh#v#v#v#v#v:V F0    5555544 F$$If!vh#v#v#v#v#v:V F0    5555544 F$$If!vh#v#v#v#v#v:V F0    5555544 F$$If!vh#v#v#v#v#v:V F0    5555544 F$$If!vh#v#vb:V F4055a44 Ff4yt$$If!vh#v#vb:V F4055a44 Ff4yt$$If!vh#v#v#v[#v#v#v:V F40555[55544 Ff4yt$$If!vh#v#v#v#v:V F40555544 Ff4yt$$If!vh#v#v#v#v#v:V F405555544 Ff4yt^  666666666vvvvvvvvv666666>6666666666666666666666666666666666666666666666666hH6666666666666666666666666666666666666666666666666666666666666666662 0@P`p2( 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p 0@P`p8XV~_HmH nH sH tH T`T Normal5$7$8$9DH$CJOJQJ_HmH sH tH P@P  Heading 1$ & F<@& 5CJKHL@L  Heading 2$ & F<@&5CJH@H  Heading 3$ & Fx<@&5D@D  Heading 4$ & F<@&@@  Heading 5 & F<@&D@D  Heading 6 & F<@&6D@D  Heading 7 & F<@&CJH@H  Heading 8 & F<@&6CJH @H  Heading 9 & F<@&6CJDA D Default Paragraph FontVi@V 0 Table Normal :V 44 la (k ( 0No List J@J Header %&dPCJF @F Footer %$dNCJ>@> TOC 2 % <<^6@6 TOC 3 % ^:@: TOC 1 % x<5HOH berschrift$$h5CJPOP Kommentierter Inhalt 6B*ph6@6 TOC 4 % ^66 TOC 5 % p^p66 TOC 6 % L^L66 TOC 7 % (^(66 TOC 8 % ^66 TOC 9 % ^:O: Version xx1$CJ$:O: Projekt xx1$CJ$H@H H=0 Balloon TextCJOJQJ^JaJNoN H=0Balloon Text CharCJOJQJ^JaJPK![Content_Types].xmlN0EH-J@%ǎǢ|ș$زULTB l,3;rØJB+$G]7O٭V$ !)O^rC$y@/yH*񄴽)޵߻UDb`}"qۋJחX^)I`nEp)liV[]1M<OP6r=zgbIguSebORD۫qu gZo~ٺlAplxpT0+[}`jzAV2Fi@qv֬5\|ʜ̭NleXdsjcs7f W+Ն7`g ȘJj|h(KD- dXiJ؇(x$( :;˹! I_TS 1?E??ZBΪmU/?~xY'y5g&΋/ɋ>GMGeD3Vq%'#q$8K)fw9:ĵ x}rxwr:\TZaG*y8IjbRc|XŻǿI u3KGnD1NIBs RuK>V.EL+M2#'fi ~V vl{u8zH *:(W☕ ~JTe\O*tHGHY}KNP*ݾ˦TѼ9/#A7qZ$*c?qUnwN%Oi4 =3N)cbJ uV4(Tn 7_?m-ٛ{UBwznʜ"Z xJZp; {/<P;,)''KQk5qpN8KGbe Sd̛\17 pa>SR! 3K4'+rzQ TTIIvt]Kc⫲K#v5+|D~O@%\w_nN[L9KqgVhn R!y+Un;*&/HrT >>\ t=.Tġ S; Z~!P9giCڧ!# B,;X=ۻ,I2UWV9$lk=Aj;{AP79|s*Y;̠[MCۿhf]o{oY=1kyVV5E8Vk+֜\80X4D)!!?*|fv u"xA@T_q64)kڬuV7 t '%;i9s9x,ڎ-45xd8?ǘd/Y|t &LILJ`& -Gt/PK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 0_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!0C)theme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] /:1b C)+-[[[[[^x mbIQRTUV_hk/ 1 _7L%820;kIU])e pu~͌F\UtJKLMNOPSWXYZ[\]^`abcdefgijYhx#?WYZ<Xprs/12i$@XZ[<Xprs,./Gc{}~ # ; > ? g % A Y \ ]   : V n q r    , H ` c d |    & B Z ] ^ o 367Kg)E]`as   /Kcfg4Phkl :RUVt1457Q#h#l#z$$$<+S+U+BBBRRRUUUeeeQlhljlstt.tEtGtZyqysy 2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@2%@!<?6-OY%02T^`Awy(*RX^!      !      Tt ,2$R+WdFx^C@H 0(  (    s >A?"Picture 2#" ?B S  ?t _Toc367686382 _Toc424456630 _Toc367686383 _Toc379047275 _Toc424456631 _Toc379047276 _Toc424456632 _Toc424456633 _Toc379047278 _Toc424456634 _Toc379047279 _Toc424456635 _Toc379047280 _Ref398436664 _Ref398436705 _Ref398436723 _Toc424456636 _Toc379047281 _Toc424456637 _Toc379047282 _Toc424456638 _Toc379047283 _Toc424456639 _Toc379047284 _Toc424456640 _Toc379047285 _Ref398436595 _Ref398436606 _Toc424456641 _Toc379047286 _Toc424456642 _Toc379014611 _Toc404413581 _Toc424456643 _Toc424456644 _Toc367686388 _Toc379047289 _Ref398436624 _Toc424456645 _Toc367686389 _Toc379047290 _Toc424456646 _Toc379014614 _Toc404413584 _Toc424456647 _Toc379014615 _Toc404413585 _Toc424456648 _Toc379047293 _Toc424456649 _Toc367686391 _Toc379014617 _Toc404413587 _Toc424456650 _Toc367686392 _Toc379047295 _Toc424456651 _Toc367686393 _Toc379047296 _Toc424456652 _Toc367686394 _Toc379047297 _Toc424456653 _Toc367686395 _Toc379014619 _Toc404413589 _Toc424456654 _Toc379047299 _Toc424456655 _Toc367686397 _Toc379047300 _Toc424456656 _Toc367686398 _Toc379047301 _Toc424456657 _Toc367686399 _Toc379047302 _Toc424456658 _Toc367686400 _Toc379047303 _Toc424456659 _Toc367686401 _Toc379047304 _Toc424456660 _Toc367686402 _Toc379047305 _Toc424456661 _Toc367686403 _Toc379047306 _Toc424456662 _Toc367686404 _Toc379047307 _Toc424456663 _Toc367686405 _Toc379047308 _Toc424456664 _Toc367686406 _Toc379047309 _Toc424456665 _Toc367686407 _Toc379047310 _Toc424456666 _Toc367686408 _Toc379047311 _Toc424456667 _Toc367686409 _Toc379047312 _Toc424456668 _Toc379047313 _Ref398436685 _Ref398436859 _Ref398436862 _Toc424456669 _Toc367686410 _Toc379047314 _Toc424456670 _Toc367686412 _Toc379047315 _Toc424456671 _Toc367686413 _Toc379047316 _Toc424456672 _Toc367686414 _Toc379047317 _Toc424456673 _Toc367686415 _Toc379047318 _Toc424456674 _Toc367686416 _Toc379047319 _Toc424456675 _Toc379047320 _Toc424456676 _Toc367686417 _Toc367686411 _Toc379047321 _Ref398436789 _Ref398436813 _Ref398436816 _Ref398438025 _Toc424456677 _Toc367686418 _Toc379047322 _Toc424456678 _Toc379047323 _Toc424456679:GG'' !!!!!\"\"##$$%%****X+X+,,,3-V.W.W.W.030303555L=L=L=IAIA(I(I(I(IIIIJJJMMMMMMMSOSOhThThTWWWWWWWWWZZZj\j\j\6^6^6^9_9_9_|`|`|`aaabbbccceeeggggghhh_k_k_klllmmmsssvvvxxxxxxxxxx  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghkijlmnopqrstuvwxyz{|}~__HH!!!!!!!""##$$&&7*7*7*7*l+l+$,3,3,@-....A3A3A3555V=V=V=jAjA@I@I@I@IIIIKKKMMMMMMMbObOyTyTyT"W"W"WWWWWWW [ [ [r\r\r\>^>^>^?_?_?_```aaabbbccc e eg,g,g,g,g,ghhhkkklllmmm#s#s#svvxxxxxxxxxxCCIKLNOQRTU\aH] 0022;DNDEEMMWWChHhpptt';IKLNOQRTU҅33333333333333333^x/1=x#[<t3i$\<t0G @ g % ^  : s  , e |  & _ o 8K)bs/h4mWt6G`I !!!\""Q#m#z$$$$*8*<+V+X+m+,4,3-A-/003B3E<z<L=W=IAkABB(IAIJKMMSOcORRpS9ThTzTUUW#WJWWZ [\s\P]]6^?^9_@_|``aabbcce eeeg-ghhii2jNj~j kllQlklmllmm#nJnppq:q=rfrrrs$sst.tHtvvxxxxZytyn|| HIKLNOQRTUY^gjb҅p܇fO> )2p ib&wb@@.@..@...@ ....@ .....@ ......@ .......@ ........*@^`ph)@^`ph)&w2p i@ A@ ^`OJQJo(p A@ S^S`OJQJo(- 766H=:B S yV X#aCE%($E/IK@@@UnknownG.[x Times New Roman5Symbol3. .[x Arial5. .[`)TahomaA$BCambria Math"q=l=lpCpCxx202QP $P X6!xx     Oh+'0P    $08@H Normal.dotm1Microsoft Office Word@@x@xp՜.+,0 hp|  C  Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F`xData 1TableLWordDocumentSummaryInformation(DocumentSummaryInformation8CompObjr  F Microsoft Word 97-2003 Document MSWordDocWord.Document.89q