5(re dfd-erd-data dictionay)


Published on

Published in: Technology, Business
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

5(re dfd-erd-data dictionay)

  1. 1. Requirements Engineering Lecture @LPU
  2. 2. Course Contents <ul><li>Introduction </li></ul><ul><li>Understanding Requirements </li></ul><ul><ul><li>Functional and Non –Functional Requirements </li></ul></ul><ul><ul><li>Other Classifications </li></ul></ul><ul><li>Modelling Requirements </li></ul><ul><ul><li>Overview </li></ul></ul><ul><ul><li>Data Flow Diagram </li></ul></ul><ul><ul><li>Entity Relationship Diagram </li></ul></ul><ul><ul><li>Data Dictionary </li></ul></ul><ul><ul><li>Decision tree and Decision tables </li></ul></ul><ul><ul><li>Structured English </li></ul></ul><ul><ul><li>State Transition Diagram </li></ul></ul><ul><li>Conclusion </li></ul>
  3. 3. Introduction <ul><li>The objectives of this module are </li></ul><ul><ul><li>To establish the importance / relevance of requirement specifications in software development </li></ul></ul><ul><ul><li>To bring out the problems involved in specifying requirements </li></ul></ul><ul><ul><li>To illustrate the use of modelling techniques to minimize problems in specifying requirements </li></ul></ul><ul><li>Requirements can be defined as follows: </li></ul><ul><ul><li>A condition or capability needed by a user to solve a problem or achieve an objective. </li></ul></ul><ul><ul><li>A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document </li></ul></ul>
  4. 4. High Level Requirements <ul><li>High level, requirements can be classified as user/client requirements and software requirements . </li></ul><ul><li>Client requirements are usually stated in terms of business needs . </li></ul><ul><li>Software requirements specify what the software must do to meet the business needs . </li></ul><ul><li>For example, a stores manager might state his requirements in terms of efficiency in stores management. </li></ul><ul><li>A bank manager might state his requirements in terms of time to service his customers . </li></ul><ul><li>It is the analyst's job to understand these requirements and provide an appropriate solution . </li></ul>
  5. 5. Understand the client’s business domain <ul><li>To be able to do this, the analyst must understand the client's business domain : </li></ul><ul><ul><li>Who are all the stake holders, </li></ul></ul><ul><ul><li>How they affect the system, </li></ul></ul><ul><ul><li>What are the constraints, </li></ul></ul><ul><ul><li>What is the adjustable, etc? </li></ul></ul><ul><li>The analyst should not blindly assume that only a software solution will solve a client's problem . </li></ul><ul><li>He should have a broader vision . Sometimes, re-engineering of the business processes may be required to improve efficiency and that may be all that is required . </li></ul><ul><li>After all this, if it is found that a software solution will add value , then a detailed statement of what the software must do to meet the client's needs should be prepared . This document is called Software Requirements Specification (SRS) document. </li></ul>
  6. 6. Understanding Requirements <ul><li>Stating and understanding requirements is not an easy task . Let us look at a few examples: </li></ul><ul><li>&quot;The counter value is picked up from the last record&quot; In the above statement, the word 'last' is ambiguous. It could mean the last accessed record, which could be anywhere in a random access file, or, it could be physically the last record in the file </li></ul><ul><li>&quot;Calculate the inverse of a square matrix 'M' of size 'n' such that LM=ML=In where 'L' is the inverse matrix and 'In' is the identity matrix of size 'n' &quot; This statement though appears to be complete, is missing on the type of the matrix elements. Are they integers, real numbers, or complex numbers. Depending on the answer to this question, the algorithm will be different. </li></ul><ul><li>&quot;The software should be highly user friendly &quot; How does one determine, whether this requirement is satisfied or not. </li></ul><ul><li>&quot;The output of the program shall usually be given within 10 seconds&quot; What are the exceptions to the 'usual 10 seconds' requirement? </li></ul>
  7. 7. The statement of requirements or SRS should possess the following properties: <ul><li>All requirements must be correct . There should be no accurate errors </li></ul><ul><li>All requirements should have one interpretation only . We have seen a few examples of ambiguous statements above. </li></ul><ul><li>The SRS should be complete in all respects . It is difficult to achieve this objective. Many times clients change the requirements as the development progresses or new requirements are added. The Agile development methodologies are specifically designed to take this factor in to account. They partition the requirements in to subsets called scenarios and each scenario is implemented separately. However, each scenario should be complete. </li></ul>
  8. 8. Contd…. <ul><li>All requirements must be verifiable , that is, it should be possible to verify if a requirement is met or not. Words like 'highly', 'usually', should not be used. </li></ul><ul><li>All requirements must be consistent and non-conflicting . </li></ul><ul><li>As we have stated earlier, requirements do change. So the format of the SRS should be such that the changes can be easily incorporated </li></ul>
  9. 9. Functional Requirements <ul><li>Requirements can be classified in to two types, namely , functional requirements and non-functional requirements. Functional requirements specify what the system should do . Examples are: </li></ul><ul><li>Calculate the compound interest at the rate of 14% per annum on a fixed deposit for a period of three years </li></ul><ul><li>Calculate tax at the rate of 30% on an annual income equal to and above Rs.2,00,000 but less than Rs.3,00,000 </li></ul><ul><li>Invert a square matrix of real numbers (maximum size 100 X 100) </li></ul>
  10. 10. Non-Functional Requirements <ul><li>Non-functional requirements specify the overall quality attributes the system must satisfy. </li></ul><ul><li>The following is a sample list of quality attributes : </li></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Testability </li></ul></ul><ul><ul><li>Modifiability </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Presentation </li></ul></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>Understandability </li></ul></ul><ul><ul><li>Acceptance Criteria </li></ul></ul><ul><ul><li>Interoperability </li></ul></ul>
  11. 11. Examples of non-functional requirements <ul><li>Some examples of non-functional requirements are : </li></ul><ul><ul><li>Number of significant digits to which accuracy should be maintained in all numerical calculations is 10. </li></ul></ul><ul><ul><li>The response time of the system should always be less than 5 seconds </li></ul></ul><ul><ul><li>The software should be developed using C language on a UNIX based system </li></ul></ul><ul><ul><li>A book can be deleted from the Library Management System by the Database Administrator only </li></ul></ul>
  12. 12. Other Classifications <ul><li>Requirements can also be classified in to the following categories: </li></ul><ul><ul><li>Satisfiability </li></ul></ul><ul><ul><li>Criticality </li></ul></ul><ul><ul><li>Stability </li></ul></ul><ul><ul><li>User categories </li></ul></ul><ul><li>Satisfiability: </li></ul><ul><ul><li>There are three types of Satisfiability, namely, normal, expected, and exciting . Normal requirements are specific statements of user needs . The user satisfaction level is directly proportional to the extent to which these requirements are satisfied by the system . </li></ul></ul>
  13. 13. Other Classifications Contd….. <ul><li>Expected requirements may not be stated by the users , but the developer is expected to meet them . If the requirements are met, the user satisfaction level may not increase, but if they are not met, users may be thoroughly dissatisfied. They are very important from the developer's point of view . </li></ul><ul><li>Exciting requirements , not only, are not stated by the users , they do not even expect them . But if the developer provides for them in the system, user satisfaction level will be very high . The trend over the years has been that the exciting requirements often become normal requirements and some of the normal requirements become expected requirements. </li></ul>
  14. 14. Satisfiability Requirements
  15. 15. Criticality <ul><li>Criticality : This is a form of prioritizing the requirements . They can be classified as mandatory, desirable, and non-essential . This classification should be done in consultation with the users and helps in determining the focus in an iterative development model. </li></ul><ul><li>Stability: Requirements can also be categorized as stable and non-stable . </li></ul><ul><li>Stable requirements don't change often, or atleast the time period of change will be very long. </li></ul><ul><li>Non - Stable requirements Some requirements may change often. </li></ul>
  16. 16. User categories <ul><li>User categories: </li></ul><ul><ul><li>As was stated in the introduction, there will be many stake holders in a system. Broadly they are of two kinds . Those who dictate the policies of the system and those who utilize the services of the system . All of them use the system. There can be further subdivisions among these classes depending on the information needs and services required. It is important that all stakeholders are identified and their requirements are captured. </li></ul></ul>
  17. 17. Modelling Requirements <ul><li>Overview </li></ul><ul><ul><li>Every software system has the following essential characteristics : </li></ul></ul><ul><ul><ul><li>It has a boundary. The boundary separates what is with in system scope and what is outside </li></ul></ul></ul><ul><ul><ul><li>It takes inputs from external agents and generates outputs. </li></ul></ul></ul><ul><ul><ul><li>It has processes which collaborate with each other to generate the outputs . </li></ul></ul></ul><ul><ul><ul><li>These processes operate on data by creating, modifying, destroying, and querying it. </li></ul></ul></ul><ul><ul><ul><li>The system may also use data stores to store data which has a life beyond the system </li></ul></ul></ul>
  18. 18. Structured Systems Analysis and Design Methodology (SSADM) <ul><li>Describing artifacts used by Structured Systems Analysis and Design Methodology (SSADM). It uses: </li></ul><ul><ul><li>Data Flow Diagram (DFD) for modelling processes and their interactions . </li></ul></ul><ul><ul><li>Entity Relationship Diagram (ERD) for modelling data and their relationships . </li></ul></ul><ul><ul><li>Data Dictionary to specify data </li></ul></ul><ul><ul><li>Decision Tables and Decision Trees to model complex decisions . </li></ul></ul><ul><ul><li>Structured English to paraphrase process algorithms . </li></ul></ul><ul><ul><li>State Transition Diagram to model state changes of the system . </li></ul></ul>
  19. 19. Data Flow Diagram (DFD) <ul><li>Data Flow Diagram (DFD) </li></ul><ul><li>Data flow diagram focuses on movement of data through the system and its transformations. </li></ul><ul><li>It is divided in to levels. Level 0, also known as the context diagram, defines the system scope. It consists of external agents, system boundary, and the data flow between the external agents and the system. </li></ul><ul><li>Level 1 is an explosion of Level 0, where all the major processes, data stores, and the data flow between them is shown. Level 2, Level 3, etc. show details of individual processes. </li></ul>
  20. 20. Symbols
  21. 21. The notation used in DFD <ul><li>External agents : They are external to the system , but interact with the system. They must be drawn at level 0, but need not be drawn at level 2 onwards . Duplicates are to be identified. They must be given meaningful names. </li></ul><ul><li>Process : They indicate information processing activity . They must be shown at all levels, At level 0, only a single process, depicting the system is shown . On subsequent levels, the number of processes should be limited to 7 ± 2. No duplicates are allowed. </li></ul>
  22. 22. The notation used in DFD Contd….
  23. 23. The notation used in DFD Contd…. <ul><li>Data Stores : They are used to store information . They are not shown at level 0. All data stores should be shown at level 1. Duplicates must be indicated. </li></ul>
  24. 24. The notation used in DFD Contd…. <ul><li>Data Flows : They indicate the flow of information . They must be shown at all levels and meaningful names must be given. </li></ul>
  25. 25. Getting started: <ul><li>Identify the inputs or events which trigger the system and outputs or responses from the system </li></ul><ul><li>Identify the corresponding sources and destinations (external agents) </li></ul><ul><li>Produce a context diagram (Level 0). It should show the system boundary, external agents, and the data flows connecting the system and the external agents . </li></ul><ul><li>Produce Level 1 diagram . It must show all the external agents, all the major processes, all the data stores, and all the data flows connecting the various artifacts . The artifacts should be placed based on logical precedence rather than temporal precedence. Avoid dataflow crossings. </li></ul><ul><li>Refine the Level 1 diagram. </li></ul><ul><li>Explode the individual processes as necessary. </li></ul>
  26. 26. Points to remember <ul><li>1) Remember to name every external agent, every process, every data store, and every dataflow. </li></ul><ul><li>2) Do not show how things begin and end . </li></ul><ul><li>3) Do not show loops, and decisions. </li></ul><ul><li>4) Do not show data flows between external agents . They are outside the scope of the system. </li></ul>
  27. 27. Points to remember Contd….. <ul><li>5) Do not show dataflow between an external agent and a data store. There should be a process in between . </li></ul>
  28. 28. Points to remember Contd….. <ul><li>6) Do not show dataflow between two data stores . There should be a process in between. </li></ul>
  29. 29. Points to remember Contd….. <ul><li>7) There should not be any unconnected external agent, process, or data store. </li></ul><ul><li>8) Beware of read-only or write-only data stores </li></ul><ul><li>9) Beware of processes which take inputs without generating any outputs. Also, beware of processes which generate outputs spontaneously without taking any inputs. </li></ul>
  30. 30. Entity Relationship Diagram (ERD ) <ul><li>ERD complements DFD. </li></ul><ul><li>While DFD focuses on processes and data flow between them, </li></ul><ul><li>ERD focuses on data and the relationships between them. </li></ul><ul><li>It helps to organize data used by a system in a disciplined way. </li></ul><ul><li>It helps to ensure completeness, adaptability and stability of data. </li></ul><ul><li>It is an effective tool to communicate with senior management (what is the data needed to run the business), data administrators (how to manage and control data), database designers (how to organize data efficiently and remove redundancies). </li></ul>
  31. 31. ERD Components <ul><li>It consists of three components. </li></ul><ul><ul><li>Entity </li></ul></ul><ul><ul><li>Attributes </li></ul></ul><ul><ul><li>Relationships </li></ul></ul><ul><li>Entity : It represents a collection of objects or things in the real world whose individual members or instances have the following characteristics: </li></ul><ul><ul><li>Each can be identified uniquely in some fashion. </li></ul></ul><ul><ul><li>Each plays a necessary role in the system we are building. </li></ul></ul><ul><ul><li>Each can be described by one or more data elements (attributes). </li></ul></ul><ul><ul><li>Entities generally correspond to persons, objects, locations, events, etc. Examples are employee, vendor, supplier, materials, warehouse, delivery , etc. </li></ul></ul>
  32. 32. Types of Entities <ul><li>There are five types of entities. </li></ul><ul><li>Fundamental entity : It does not depend on any other entity for its existence. </li></ul><ul><ul><li>For e.g. materials </li></ul></ul><ul><li>Subordinate entity : It depends on another entity for its existence. </li></ul><ul><ul><li>For example, in an inventory management system, purchase order can be an entity and it will depend on materials being procured. Similarly invoices will depend on purchase orders. </li></ul></ul><ul><li>Associative entity: It depends on two or more entities for its existence. </li></ul><ul><ul><li>For example, student grades will depend on the student and the course. </li></ul></ul><ul><li>Generalization entity: It encapsulates common characteristics of many subordinate entities. </li></ul><ul><ul><li>For example, a four wheeler is a type of vehicle. A truck is a type of four wheeler . </li></ul></ul><ul><li>Aggregation entity : It consists of or an aggregation of other entities. </li></ul><ul><ul><li>For example, a car consists of engine, chasis, gear box, etc. A vehicle can also be regarded as an aggregation entity, because a vehicle can be regarded as an aggregation of many parts. </li></ul></ul>
  33. 33. Attributes <ul><li>Attributes : They express the properties of the entities . </li></ul><ul><li>Every entity will have many attributes, but only a subset, which are relevant for the system under study, will be chosen. </li></ul><ul><li>For example, an employee entity will have professional attributes like name, designation, salary, etc . and also physical attributes like height, weight , etc. But only one set will be chosen depending on the context. </li></ul>
  34. 34. Relationships <ul><li>Relationships : They describe the association between entities . They are characterized by optionality and cardinality . Optionality is of two types, namely, mandatory and optional . </li></ul><ul><li>Mandatory relationship means associated with every instance of the first entity there will be at least one instance of the second entity. </li></ul><ul><li>Optional relationship means that there may be instances of the first entity, which are not associated with any instance of the second entity. </li></ul><ul><li>For example, employee-spouse relationship has to be optional because there could be unmarried employees. It is not correct to make the relationship mandatory. </li></ul>
  35. 35. Relationships Contd….. <ul><li>Cardinality is of three types: one-to-one, one-to-many, many-to-many . </li></ul><ul><li>One-to-one relationship means an instance of the first entity is associated with only one instance of the second entity. Similarly, each instance of the second entity is related to one instance of the first entity. </li></ul><ul><li>One-to-many relationship means that one instance of the first entity is related to many instances of the second entity, while an instance of the second entity is associated with only one instance of the first entity. </li></ul><ul><li>In many-to-many relationship an instance of the first entity is related to many instances of the second entity and the same is true in the reverse direction also. </li></ul><ul><li>Other types of relationships are multiple relationships between entities, relationships leading to associative entities, relationship of entity with itself, EXCLUSIVE-OR and AND relationships </li></ul>
  36. 36. ERD Notation <ul><li>ERD notation : There are two type of notation used: </li></ul><ul><li>Peter Chen notation </li></ul><ul><li>Bachman notation </li></ul><ul><li>Components Notations </li></ul><ul><ul><li>Entity or Object type </li></ul></ul><ul><ul><li>Relationship </li></ul></ul><ul><ul><li>Cardinality </li></ul></ul><ul><ul><li>Optionality </li></ul></ul>Purchase Order
  37. 37. Example for Peter Chen notation <ul><li>A tender is floated either for materials or services but not both. </li></ul><ul><li>A car consists of an engine and a chasis </li></ul>
  38. 38. ER diagrams using Bachman notation <ul><li>In a company, each division is managed by only one manager and each manager manages only one division. </li></ul><ul><li>Among the automobile manufacturing companies, a company manufactures many cars, but a given car is manufactured in only one company . </li></ul><ul><li>In a college, every student takes many courses and every course is taken by many students </li></ul>
  39. 39. ER diagrams using Bachman notation <ul><li>In a library, a member may borrow many books and there may be books which are not borrowed by any member </li></ul><ul><li>A teacher teaches many students and a student is taught by many teachers. A teacher conducts examination for many students and a student is examined by many teachers. </li></ul>
  40. 40. Data Dictionary <ul><li>Data Dictionary </li></ul><ul><ul><li>It contains </li></ul></ul><ul><ul><ul><li>an organized list of data elements, data structures, data flows, and data stores </li></ul></ul></ul><ul><ul><ul><li>Mini specifications of the primitive processes in the system </li></ul></ul></ul><ul><ul><ul><li>It will provide useful information on the system </li></ul></ul></ul><ul><li>Data element is piece of data, which can not be decomposed further in the current context of the system. </li></ul><ul><ul><li>Examples are purchase_order_no., employee_name, interest_rate, etc. Each data element is a member of a domain. The dictionary entry of a data element should also specify the domain. </li></ul></ul>
  41. 41. Data Dictionary Contd… <ul><li>Data structure is composed of data elements or other data structures . </li></ul><ul><li>Examples are Customer_details, which may be composed of Customer_name and Customer_address. Cutomer_address in turn is a structure. </li></ul><ul><li>Data flow is composed of data structures and/or data elements . Definitions of dependent data structures/data elements precede the definition of data flow. While defining the data flow the connecting points should be mentioned. </li></ul><ul><li>Also useful to include the flow volume/frequency and growth rates . </li></ul>
  42. 42. Data Dictionary Contd…. <ul><li>Data store , like data flow is made up of a combination of data structures and/or data elements. The description is similar to data flows. </li></ul><ul><li>The notation elements used in the data dictionary are the following: </li></ul><ul><li>[last_name] This indicates that last_name is optional </li></ul><ul><li>{dependent_name,   relationship} * (0 to 15) This indicates that the data strucure can be repeated 0 to 15 times </li></ul>
  43. 43. Data Dictionary Contd…. <ul><li>{expense_description,   company_name,   charge} * (1 to N) This indicates that the data structure may be repeated 1 to N where N is not fixed. </li></ul><ul><li>voter_identity_number/customer_account_number This indicates that either of the elements will be present. </li></ul>
  44. 44. Data Dictionary Symbol’s & Example <ul><li>The symbols used are: </li></ul><ul><ul><li>Equal sign, meaning “consists of”. </li></ul></ul><ul><ul><li>Plus sign, meaning &quot;and”. </li></ul></ul><ul><ul><li>Braces {} meaning repetitive elements, a repeating element or group of elements. </li></ul></ul><ul><ul><li>Brackets [] for an either/or situation. </li></ul></ul><ul><ul><ul><li>The elements listed inside are mutually exclusive. </li></ul></ul></ul><ul><ul><li>Parentheses () for an optional element. </li></ul></ul><ul><li>Structural Record Example: </li></ul><ul><ul><li>Customer Name =First Name +Middle Initial) +Last Name </li></ul></ul><ul><ul><li>Address = Street +(Apartment) +City +State + Zip + (Zip Expansion) + (Country) </li></ul></ul><ul><ul><li>Telephone = Area code + Local number </li></ul></ul>
  45. 45. Decision Tree and Decision Tables <ul><li>Decision Tree and Decision Tables </li></ul><ul><li>A decision tree represents complex decisions in the form of a tree. </li></ul><ul><li>An example is given below </li></ul><ul><li>Rules for electricity billing are as below: </li></ul><ul><ul><li>If the meter reading is &quot;OK&quot;, calculate on spending basis(i.e. meter reading) If the meter reading appears &quot;LOW&quot;, then check if the house is occupied. If the house is occupied, calculate on seasonal spending basis otherwise calculate on utilization basis If the meter is damaged, calculate based on maximum possible electricity usage. </li></ul></ul>
  46. 46. Decision Tables <ul><li>There are two types of decision tables. </li></ul><ul><li>Binary-valued (yes or no) </li></ul><ul><li>Multi-valued. </li></ul><ul><li>An example follows: ELECTRICITY BILL CALCULATION BASED ON CUSTOMER CLASS If a customer uses electricity for domestic purposes and if the utilization is less than 300 units per month then bill with minimum monthly charges. Domestic customers with a utilization of 300 units or more per month are billed at special rate. Non-domestic users are charged double that of domestic users ( minimum and special rates are double). </li></ul>
  47. 47. BINARY-VALUED DECISION TABLE Domestic Customer Y Y N N Consumtion < 300 units per month Y N Y N Minimum rate Y N N N Special rate N Y N N Double minimum rate N N Y N Double special rate N N N Y
  48. 48. MULTI-VALUED DECISION TABLE Customer D D N N utilization ≥ 300 <300 ≥ 300 <300 Rate S M 2S 2M
  49. 49. Structure English <ul><li>Structured English </li></ul><ul><ul><ul><li>To specify the processes (minispecifications) structured English is used. </li></ul></ul></ul><ul><ul><ul><li>It consists of: </li></ul></ul></ul><ul><ul><ul><ul><li>sequences of instructions (action statements) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>decisions (if-else) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>loops (repeat-until) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>case </li></ul></ul></ul></ul><ul><ul><ul><ul><li>groups of instructions </li></ul></ul></ul></ul><ul><li>Examples: Loose, normal English : In the case of 'Bill', a master file is updated with the bill (that is consumer account number and bill date). A control file is also to be updated for the 'total bill amount'. A similar treatment is to be given to 'Payment' </li></ul>
  50. 50. Structure English Contd… <ul><li>Structured English: If transaction is 'BILL' then     update bill in the Accounts master file     update total bill amount in the Control file If transaction is 'PAYMENT' then     update receipt in the Accounts master file     update total receipt amount in the Control file Another example: If previous reading and new reading match then      perform 'status-check' If status is 'dead' then      calculate bills based on average utilization Else      compute bill based on actual utilization </li></ul>
  51. 51. State Transition Diagram <ul><li>State Transition Diagram </li></ul><ul><li>Another useful diagram is the state transition diagram. </li></ul><ul><li>It can be used to model the state changes of the system. </li></ul><ul><li>A system is in a state and will remain in that state till a condition and an action force it to change state. </li></ul>
  52. 52. State Transition Diagram Contd….
  53. 53. Conclusion <ul><li>The output of the requirements engineering phase is the software requirements specifications (SRS) document . </li></ul><ul><li>At a minimum, it should contain the DFD, ERD, and the data dictionary and the minispecifications. </li></ul><ul><li>The other diagrams may be used as required. </li></ul><ul><li>The standards body of Institute for Electrical Electronics Engineers (IEEE) has defined a set of recommended practices called &quot;IEEE Recommended Practice for Software Requirements Specifications&quot;, IEEE standards 830-1998. It can be used as a guideline document for SRS. </li></ul>
  54. 54. <ul><li>Thank U </li></ul>