Week11 Determine Technical Requirements


Published on

Published in: Economy & Finance, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Week11 Determine Technical Requirements

  1. 1. Determine technical requirements
  2. 2. Overview <ul><li>You should already know about compiling business needs. </li></ul><ul><li>This resource will help you to determine technical requirements within an information technology environment. </li></ul>
  3. 3. In this topic you will learn how to: <ul><li>review and assess business problems, opportunities and objectives </li></ul><ul><li>identify technical requirements in respect of input/output, interface, process flow or quality requirements </li></ul><ul><li>develop business solutions in response to problems and technical requirements as identified </li></ul><ul><li>investigate a range of supplier products to determine which one best meets technical requirements </li></ul><ul><li>document results and make recommendations against business requirements </li></ul>
  4. 4. Identify technical requirements <ul><li>Identifying technical requirements involves </li></ul><ul><li>assessing the business problem (including input/output requirements, interface requirements, process requirements) </li></ul><ul><li>developing a business solution </li></ul><ul><li>investigating products </li></ul><ul><li>and documenting results. </li></ul>
  5. 5. Assess the business problem <ul><li>To assess a problem or an opportunity faced by a business, it is necessary to look at the technical requirements of the business. These fall into three general categories: </li></ul><ul><li>input/output requirements </li></ul><ul><li>interface requirements </li></ul><ul><li>process requirements. </li></ul>
  6. 6. Solutions <ul><li>Once the technical requirements have been identified, it is possible to develop a solution such as software or hardware upgrade, network installation, inventory management or an e-commerce solution. At this stage, the solution will include an investigation into suitable products. Finally, the recommendations will need to be measured against the technical requirements and documented. The following figure illustrates the relationship between the systems within a business and the data flow between the systems. </li></ul>
  7. 7. Business systems and data flow relationships
  8. 8. Automation of processes <ul><li>Computers and applications are commonly used to automate stable repetitive tasks. In the past, the focus was to automate internal processes, and this remains a priority today. However, many organisations that are satisfied with the automation of internal processes are now shifting their focus to automating processes which integrate interaction with their suppliers and customers. </li></ul>
  9. 9. Supply chain management <ul><li>Supply chain management covers a broad spectrum of business activities including contractual arrangements, service level agreements, relationship development, disclosure of information, and more. Our interest is to identify the technical requirements for the computer-based interaction. </li></ul>
  10. 10. common interfacing methods <ul><li>Two common interfacing methods are EDI ( electronic data interchange ) and XML ( extendable mark-up language ). Detailed discussion on these exchange standards is outside the scope of this topic, but a brief overview is provided in the following documents: </li></ul><ul><li>EDI (52 KB 2836_reading1.doc) </li></ul><ul><li>XML (92 KB 2836_reading2.doc) </li></ul>
  11. 11. Interacting with customers <ul><li>Organisations are actively pursuing methods of automating procedures for communicating with customers. Two of the main types of automation are </li></ul><ul><li>interfacing with external computer systems ( B2B ) </li></ul><ul><li>enabling customer self-service over the Internet ( B2C ). </li></ul>
  12. 12. Interfacing with external computer systems <ul><li>Interfacing with external computer systems means you are accessing a computer outside of your organisation. </li></ul><ul><li>In a business-to-business ( B2B ) environment you may need to consider the following: </li></ul><ul><li>in a sales system: there is a need to provide data (price, availability, invoice number, etc.) to the buyer's computer system. </li></ul><ul><li>in a purchasing system: there is a need to provide data (order number, product identification, quantity, delivery address, etc.) to the seller's computer system. </li></ul><ul><li>if the system requires data from third parties: such as credit-check information or authentication of users, you need to consider the data that must be provided and what data will be returned. </li></ul>
  13. 13. Business-to-Business environment
  14. 14. <ul><li>The other side of interfacing with customers' systems is interfacing with suppliers' systems. The organisation's position within the supply chain determines whether it is a customer or a supplier. </li></ul>
  15. 15. Enabling self-service over the Internet <ul><li>Enabling self-service over the Internet means you are enabling customers to negotiate and search your website for information. More advanced self-service involves enabling the customer to enter data to automate or trigger a business process. </li></ul>
  16. 16. In a business-to-consumer ( B2C ) environment you may need to consider the following: <ul><li>if the system supplies information: what information should be displayed on screen? How should the customer interact with the system? </li></ul><ul><li>if the system is an e-commerce solution: you will need to consider the technical requirements of a payment gateway for a financial institution. </li></ul><ul><li>if the system deals with confidential or personal information: you may need to consider passwords and encryption. </li></ul><ul><li>Image: Diagram of an arrow with the word data connecting a star with the words Proposed system to four figures and the word Customers underneath </li></ul>
  17. 17. Business-to-consumer environment
  18. 18. An ideal example of self-service is an e-commerce transaction where the customer selects a product, then provides their delivery address and credit card details to enable the transaction. Screen shot of ABC website order form showing the delivery information questions.
  19. 19. Identifying technical requirements for input/output <ul><li>The stages involved in identifying technical requirements for input/output: </li></ul><ul><li>Identify the interaction process (whether for business to business or business to consumer). </li></ul><ul><li>Identify the trigger/s that begins the interaction. </li></ul><ul><li>Identify the input/output data required for the process. </li></ul><ul><li>Identify relevant protocols for the data exchange. </li></ul>
  20. 20. Document the input and output requirements for the interaction Interface requirements <ul><li>Many systems need to provide data for other business systems or for users. For example: </li></ul><ul><li>if the system is a sales system it may need to source or provide data to the inventory or accounting systems. </li></ul><ul><li>if the system is to be used by remote workers you may need to provide dial-up access or enable WAP. </li></ul><ul><li>if the system is a web-based e-commerce solution you may need to interface with backend sales systems. </li></ul><ul><li>if the system is a network you may need to connect a number of LANs. </li></ul>
  21. 21. Interfacing with computer systems <ul><li>Many computer-based systems require data from other systems and/or provide data to another system. </li></ul><ul><li>Consider an e-commerce solution. Customers want to know if products are in stock, so the e-commerce solution may need to interface with the backend inventory system to enable the identification of product availability. </li></ul><ul><li>In addition, the e-commerce solution will capture data regarding customer transactions; this information is required for accounting and sales systems. </li></ul><ul><li>The methods of interfacing with backend systems vary depending on the desired level of automation and control. </li></ul>
  22. 22. Interface methods <ul><li>Four possible levels of interface are provided here. The examples are not fully comprehensive; that is, other interface options exist. </li></ul>
  23. 23. <ul><li>Data from one system is printed and re-keyed into another system. This method has inherent risks of errors and fraud and is labour intensive and costly. This method is not recommended! </li></ul><ul><li>Data from one system is manually uploaded/downloaded from one system to another. This method reduces the risk of typing errors and reduces the risk of fraud, but if data is not uploaded/downloaded in a regular and timely manner, there may be risks of inaccuracy in the backend systems. </li></ul><ul><li>Data from one system is uploaded/downloaded in automated batch processing. This method reduces errors and fraud; however, there are still risks of data inaccuracy in the backend systems between the batch uploads/downloads. The duration between batch processings may be specified from minutes to overnight to weekly. The greater the frequency of batch processing, the lower the risk of data inaccuracy, but there will also be an increase in network traffic and CPU usage. </li></ul><ul><li>Data from one system is seamlessly interfaced with another system. In this situation a shared database may be used or systems are dynamically connected. This method reduces the risk of errors associated with data inaccuracy but increases the risk of hacking into backend systems. In addition, there may be less control over inappropriate data transfers. </li></ul><ul><li>The technical requirements for each of the interface systems above are significantly different. </li></ul>
  24. 24. Interfaces for internal users <ul><li>Staff within the organisation may need to access information or enter data into the system. You need to consider the display requirements and the data capture requirements for internal users. Typically, the interface required for internal users is an on-screen display or report, such as </li></ul><ul><li>data entry in a sales or accounting system </li></ul><ul><li>an order screen for a purchasing officer </li></ul><ul><li>sales reports for a sales manager. </li></ul><ul><li>When assessing technical requirements for interfacing with internal users, you need to consider exactly what data needs to be captured, and you also need to consider any protocols that may be appropriate. For example: </li></ul><ul><li>is an encryption system required? </li></ul><ul><li>will there be a password field that shouldn't display clear text? </li></ul><ul><li>which job roles should have access to reports and data entry screens? </li></ul><ul><li>There may be other interface-related requirements specified by the client such as screen colour and type of navigation. </li></ul>
  25. 25. Identifying interface requirements <ul><li>The stages involved in identifying the interface requirements: </li></ul><ul><li>Identify the sources of required data. </li></ul><ul><li>Identify the data items and data structures required for the exchange. </li></ul><ul><li>Consider alternatives or select methods of data exchange. </li></ul><ul><li>Identify relevant protocols for the data exchange. Document or reference the technical requirements for data exchange including the source, data items, data structures, timing, method and protocols. </li></ul>
  26. 26. Activity 1 <ul><li>Select a familiar IT process and attempt to document the data capture/input interface methods. What are the positives and negatives of the selected method? In what way could the system be improved? </li></ul>