Determine technical requirements
Overview
Image: Overview
You should already know about compiling business needs. This resource will help you to determine technical requirements within an information technology environment.
In this topic you will learn how to:
· review and assess business problems, opportunities and objectives
· identify technical requirements in respect of input/output, interface, process flow or quality requirements
· develop business solutions in response to problems and technical requirements as identified
· investigate a range of supplier products to determine which one best meets technical requirements
· document results and make recommendations against business requirements
This topic contains:
· reading notes
· activities
· references
· a topic quiz.
As you work through the reading notes you will be directed to activities that will help you practise what you are learning. The topic also includes references to aid further learning and a topic quiz to check your understanding.
Download a print version of this whole topic: Determine technical requirements (345 KB 2836.doc)
Reading notes
Image: Reading notes
Identify technical requirements
Identifying technical requirements involves
· assessing the business problem (including input/output requirements, interface requirements, process requirements)
· developing a business solution
· investigating products
· and documenting results.
Assess the business problem
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:
· input/output requirements
· interface requirements
· process requirements.
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.
Image: Diagram with arrows showing data flow between internal support systems and a proposed system and the data flow between the proposed system, suppliers, customers and the customer’s computer system
Figure 1: Business systems and data flow relationships
Automation of processes
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.
Supply chain management
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.
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:
EDI (52 KB 2836_reading1.doc)
XML (92 KB 2836_reading2.doc)
Interacting with customers
Organisations are actively pursuing methods of automating procedures for communicating with customers. Two of the main types of automation are
· interfacing with external computer systems (B2B)
· enabling customer self-service over the Internet (B2C).
Interfacing with external computer systems
Interfacing with external computer systems means you are accessing a computer outside of your organisation.
In a business-to-business (B2B) environment you may need to consider the following:
· in a sales system: there is a need to provide data (price, availability, invoice number, etc.) to the buyer's computer system.
· 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.
· 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.
Image: Diagram of an arrow with the word data connecting two stars with proposed system on one and customer’s computer system on the other.
Figure 2: Business-to-business environment
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.
Enabling self-service over the Internet
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.
In a business-to-consumer (B2C) environment you may need to consider the following:
· if the system supplies information: what information should be displayed on screen? How should the customer interact with the system?
· if the system is an e-commerce solution: you will need to consider the technical requirements of a payment gateway for a financial institution.
· if the system deals with confidential or personal information: you may need to consider passwords and encryption.
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
Figure 3: Business-to-consumer environment
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.
Image: Screen shot of ABC website order form showing the delivery information questions.
Figure 4: Example of e-commerce self-service
Table 1: Identifying technical requirements for input/output
The stages involved in identifying technical requirements for input/output:· Identify the interaction process (whether for business to business or business to consumer).
· Identify the trigger/s that begins the interaction.
· Identify the input/output data required for the process.
· Identify relevant protocols for the data exchange.
· Document the input and output requirements for the interaction
Interface requirements
Many systems need to provide data for other business systems or for users. For example:
· if the system is a sales system it may need to source or provide data to the inventory or accounting systems.
· if the system is to be used by remote workers you may need to provide dial-up access or enable WAP.
· if the system is a web-based e-commerce solution you may need to interface with backend sales systems.
· if the system is a network you may need to connect a number of LANs.
Interfacing with computer systems
Many computer-based systems require data from other systems and/or provide data to another system.
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. In addition, the e-commerce solution will capture data regarding customer transactions; this information is required for accounting and sales systems. The methods of interfacing with backend systems vary depending on the desired level of automation and control.
Interface methods
Four possible levels of interface are provided here. The examples are not fully comprehensive; that is, other interface options exist.
1. 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!
2. 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.
3. 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.
- 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.
The technical requirements for each of the interface systems above are significantly different.
Interfaces for internal users
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
· data entry in a sales or accounting system
· an order screen for a purchasing officer
· sales reports for a sales manager.
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:
· is an encryption system required?
· will there be a password field that shouldn't display clear text?
· which job roles should have access to reports and data entry screens?
There may be other interface-related requirements specified by the client such as screen colour and type of navigation.
Table 2: Identifying interface requirements
The stages involved in identifying the interface requirements:· Identify the sources of required data.
· Identify the data items and data structures required for the exchange.
· Consider alternatives or select methods of data exchange.
· 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.
Activity 1
To practise documenting the interface methods, go to Activity 1 – Interface methods, located in the Activities section of the Topic menu.
Process requirements
Most computer-based systems perform some automated procedures or processes; even the simplest website enables a visitor to navigate around the site to find information. More complex websites authenticate visitors and may automate transactions through e-commerce.
Technical requirements for system procedures and processes identify the non-functional specifications of the proposed system itself. The non-functional requirements can include the following:
· performance or speed of the system
· quality
· environmental requirements or business rules
· size
· ease of use
· reliability
· robustness
· portability.
Here are some examples:
· If the system is a sales system technical requirements may address the number of transactions per minute.
· If the system is a website the technical requirements may address the page display speed, compatibility with browsers and hardware platforms.
· If the system is a database-centred system the technical requirements may address the constructs of the database, number of records or processing time.
· If the system is an inventory control system the technical requirements may address the ability to set the alarm levels for high and low stocks.
· If the system is a network the technical requirements may address download or response times, application access, redundancy procedures, disk access speeds, number of users, etc.
In addition, technical requirements for system procedures and processes may address the application architecture, development environment or network topology and protocols.
System requirements
To date we have discussed the technical requirements for transferring data to and from external suppliers, external customers and internal systems. This section discusses the technical requirements for the system itself.
The technical requirements for the system will influence the design and construction of the system. You need to have some idea of the technology to be used in the solution before defining the technical requirements for the system. The technical requirements for the proposed system describe what the system will do and how it will do it.
Technical requirements for the proposed system should be high level - that is, the requirements or specifications may constrain the design but they should not determine the design.
Environmental requirements
Technical requirements for the system may describe the environment of the proposed system (eg operating system or network infrastructure). The environment may be specified by the client or sponsor, or it may be left undetermined. Often the client will specify an environment in order to standardise their computing infrastructure. You may need to locate and read the client's IT infrastructure policy.
Environmental requirements may constrain the solution. In addition, the environmental requirements may determine the skill set of project team members. The extent of environmental influence must be confirmed with the client.
An example of an environmental requirement specified by the client is that the client requires a database built for Microsoft Access or MySQL or Oracle.
Generally, technical requirements influenced by the environment are associated with one or more of the following:
· systems hardware
· network infrastructure
· operating system
· application architecture
· internal/external interface requirements and protocols
· the development tools
· industry standards or guidelines.
Website development example
If the system being developed is a website, there are likely to be environmental requirements related to usability and accessibility.
These are constraints based on general industry standards or guidelines. These requirements are not necessarily imposed by the client. The client may not in fact know what these guidelines are. However, a professional site should conform to these guidelines.
To determine these requirements, the developer may need to conduct an ’environmental scan’ of industry websites and/or publications.
For an example of usability and accessibility guidelines in website development see the Website development example (79 KB 2836_reading3.doc).
Identifying technical requirements for processes and quality
The stages in identifying technical requirements for how the system will function and what the system will do include