Determine technical requirements
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 ecommerce 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.
Automation of processes
Computers and applications are commonly
used to automate stable repetitive tasks. In the
past, the focus was to automate internal
Figure 1: Business systems and data flow relationships
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).
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:
DetermineTechReq.docx © State of NSWs, DET
1
Determine technical requirements



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.
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
Figure 2: Business-to-business environment
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.
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.
Figure 3: Business-to-consumer environment
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
DetermineTechReq.docx © State of NSWs, DET
2
Determine technical requirements
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
Figure 4: Example of e-commerce self-service
systems and/or provide data to another system.
Consider an e-commerce solution. Customers want to know if products are in stock, so the ecommerce 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.
4. 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.
DetermineTechReq.docx © State of NSWs, DET
3
Determine technical requirements
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.
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.
DetermineTechReq.docx © State of NSWs, DET
4
Determine technical requirements
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.
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
 identifying the process, quality and environment requirements of the system, such as the clients,
the infrastructure policy or industry standards.
 confirming with clients any boundaries or constraints associated with the environment.
 documenting the technical requirements.
DetermineTechReq.docx © State of NSWs, DET
5
Determine technical requirements
Develop a business solution
Once you have assessed the business problem and identified the technical requirements, you need to
develop a solution based on these requirements. In an iterative approach to system development, you
need to develop an initial solution and present this to the client for feedback. The feedback is then
incorporated (where appropriate) into the specifications and another solution is developed. The
‘solution’ in this case does not refer to the full implementation of the system - just a description, model
or prototype of the solution.
Modelling techniques
When the requirements of a business have been determined, the relevant information is gathered,
organised and documented. As part of requirements analysis, this information is then analysed and
descriptions of the recommended solution are generated. Analysts and developers need a language
to construct visual and other models at different levels of abstraction for the current system
requirements and/or the proposed solutions.
Modelling the system
One of the better ways to develop technical requirements for the system is to use modelling
techniques. The choice of modelling technique is based on the proposed solution and the technology
to be used. For example:
 A website modelling technique is prototyping (either paper-based or computer-based). This
shows selected pages of a website and the navigation between the pages.
 A database-centred modelling technique uses data flow diagrams (DFD) and entity relationship
diagrams (ERD). These diagrams show the data stores, processes which interact with the data
stores and where the data has been sourced or supplied.
Prototyping
A prototype is an appropriate technique at both the requirements and design phases of development.
At the technical requirements stage, however, the focus is more on technical issues such as testing a
solution within a specific operating environment.
A prototype can be paper-based illustrating screen shots of the interface, navigation elements, etc. It
is more detailed than a storyboard.
A computer-based prototype involves the development of a cut-down version of the proposed system.
The developer implements just enough of the system to provide the stakeholders with a working
example of the system. A useful prototype would probably show the interface design and the typical
functions provided by the system.
The following example illustrates this. Notice there is no content added, just the navigation and major
divisions in the web page.
Figure 5: Prototype example
Prototypes are used in rapid application development (RAD) because they provide a means to
communicate the proposed solution to the client quickly and effectively. The client is able to provide
DetermineTechReq.docx © State of NSWs, DET
6
Determine technical requirements
feedback and suggestions about whether the prototype meets their needs. This feedback is used to
make adjustments and so the process continues until a solution is reached which is acceptable to all
key stakeholders. The graphic below illustrates this.
Prototyping is an appropriate technique for
many applications including website design.
Structured analysis
Structured analysis is most appropriate for
use with business information systems as
these systems are usually data-driven. A
data-driven system begins with the input of
data. The data is then moved through
processes and changed into information. The
data and the processes that change the data
into information must be modelled and
documented. Each process's logic must also
Figure 6: Rapid application development (RAD) prototyping
be included in the documentation.
The toolset for structured analysis may
include - but is not limited to - the following:
 data flow diagram: used for process modelling to represent the flow of data through the system
 context diagram: a top-level DFD that represents top-level functions and their components
 data dictionary: a text document that contains detailed definitions of all data flows, processes
and data stores
 structured English: a descriptive method used to describe process decision logic (often called
‘mini-specs’)
 decision trees and tables: a diagrammatic method used to illustrate process decision logic
 system flow charts: primarily used for the physical modelling of the major processes, inputs and
outputs of a system
 structure charts: a hierarchical diagram of system components
 entity relationship diagram: used for data modelling to show entities, their attributes and
relationships.
Object-oriented analysis
Object-oriented analysis is most appropriate for the development of complex event-driven systems
with real-time functionality such as e-commerce. Models evolve as requirements are defined and
refined. Models of real-world events and interactions can be produced.
The diagramming conventions for object-oriented modelling have been incorporated into a standard
object-oriented language called unified modelling language (UML).
The toolset within UML may include - but is not limited to - the following which you can read about:
Use case diagrams: (62 KB 2836_reading4.doc) used to model static system functions by illustrating
the interactions between external entities (actors) and a sequence of activities in a system (use
cases). A narrative description of each use case diagram should also be included.
Class diagrams: or Object class diagrams: (66 KB 2836_reading5.doc) used for data modelling to
illustrate objects, object properties (attributes and behaviours) and associations with other objects.
Sequence diagram: (40 KB 2836_reading6.doc) used to model dynamic system functions by
illustrating the interactions (messages) and sequence of interactions among objects.
Activity diagrams: (42 KB 2836_reading7.doc) used to represent the decision logic of processing
activities.
Statechart diagrams: (36 KB 2836_reading8.doc) used to model the state changes of an object and
the events that cause an object to change (temporal logic).
Source: Abstracts on this page (Structured analysis and Object-oriented analysis) have been
authored by Barrier Reef Institute of TAFE in consortium with TAFE Qld On-Line.
DetermineTechReq.docx © State of NSWs, DET
7
Determine technical requirements
Investigate products
Once you've made decisions regarding technical requirements, you should investigate off-the-shelf
products that will fulfil these requirements. This is likely to involve a search on the Internet for product
specifications or consultation with experts in the field. Most manufacturers of hardware and software
have websites which list the product specifications, so it should be a relatively straightforward process
to identify product specifications.
Some of the issues that may guide your choice are
 industry or organisational standards: In some fields there may be industry guidelines or
standards governing the choice of product; for example, government organisations may have a
policy of supporting certain manufacturers (such as Microsoft, Cisco, etc.).
 industry conventions: In some cases, certain products have become almost a de facto standard
where certain products are used by the majority of organisations in the field. One example would
be Adobe Photoshop for graphic design.
 support for the product: The level of support for a given product may be a consideration; an
uncommon or customised product may lack good support or documentation.
 ease of use: This is an important consideration where non-expert users will be accessing the
product.
 existing infrastructure: The existing hardware or software may dictate product selection. For
example, if the organisation is a Microsoft-only environment, it may not be feasible to choose a
product that doesn't run in a Microsoft environment.
Document results
The contents and degree of detail for a Requirements report will vary depending on the size and
scope of a project, but the report is generally an informal document that can be easily understood by
the customer. The report may contain only business requirements, or it may extend to technical
requirements and a feasibility study. Your organisation will often provide a template for requirements
documentation.
The purpose of the Requirements report is to communicate and confirm the requirements.
Note: A Requirements report is produced as part of the process of gathering data. The technical
specification is usually one component of the overall report. It is sometimes referred to as the nonfunctional requirements.
Table 3: Requirements report example
Introduction
Purpose
Scope
Definitions
Overview of document
System description
Overall system
Sub-systems
Operating environment
Functional requirements
Logical view
Physical view
Non-functional requirements
I/O requirements
Interface requirements
Process requirements. For example:
– Performance
– Quality
DetermineTechReq.docx © State of NSWs, DET
8
Determine technical requirements
– Business rules
Information domain
Data definitions
Structure
Project costs
Analysis
Software development
Hardware and network
Benefits
Tangible
Intangible
Introduction
Define the purpose of the document with a summary of the entire document. The introduction should
describe the scope of the system – that is, what functions the system will implement.
System description
Describe top-level functions of the system and the system environment. Diagrams (eg use cases and
context diagrams) can be used to model the system and interactions with its environment.
For example, if the system is a website you could include a top-level storyboard to demonstrate to the
client the main functions.
Functional requirements
Define the services that the system provides. Examples of mandatory and desirable functional
requirements might include the following:
 The system must associate non-stock purchases of raw materials to a specified customer order.
 The system must associate design work as well as production work to customer special orders.
 The system must provide a users' guide for products.
 The system must capture customer details online.
 The system may have password protection for a members-only section.
 The system may track the completion status of customer special orders.
Use case diagrams, data flow diagrams and statechart diagrams are common techniques used to
describe the system functions.
Non-functional requirements


Define any constraints within which the current system operates, such as database size, response
times, web page download times, etc.
This is the section that will be added in the technical requirements phase of the requirements
definition. It should specify
 I/O requirements
 interface requirements
 process requirements such as
performance or speed of the system
quality
 environmental requirements or business rules
 size
 ease of use
 reliability
 robustness
 portability.
DetermineTechReq.docx © State of NSWs, DET
9
Determine technical requirements
Information domain
Define the data requirements of the system. Entity relationship diagrams, class diagrams and data
dictionaries are common techniques used to describe a system’s data.
Project costs
Define estimated costs of the project in terms of development and running costs.
Benefits
Define the areas that the new system will improve. This includes benefits measurable in dollars
(tangible) and those that cannot be measured in dollars (intangible) but are important nonetheless.
Other project-specific topics
Define any other topics that may impact on the project. These may include such things as
methodology, legal implications or employee acceptance.
Summary
Technical requirements are not goals - they are requirements and should be achievable and
measurable. The purpose of this resource is to reinforce this and demonstrate identification and
documentation methods for technical requirements
DetermineTechReq.docx © State of NSWs, DET
10