Here are two potential factors that could have influenced business decisions for the project: 1. Policy changes - A new privacy policy was introduced that placed stricter requirements around data security and access. This may have impacted technical architecture decisions and increased security requirements. 2. Legislative changes - New legislation was passed requiring additional reporting and auditing of financial transactions. This could have prompted the need for an upgraded accounting system with stronger audit trails and reporting capabilities.

1. Translate business
needs into technical
requirements
ICAA5158A

2. Overview
 The analysis stage of a project involves identifying the
needs of a business or business process and then
quantifying those needs into technical requirements.
 Once the business needs have been established and
you have an idea of the technology to be used for the
solution, you can commence translating the business
needs into technical requirements.
 Technical requirements are often supported through the
use of modelling techniques such as data flow diagrams,
UML or entity relationship diagrams.
 In addition, technical requirements should be
measurable; that is, you should be able to validate if you
have been able to achieve or surpass the required
technical requirements.

3. Overview
 Sometimes the business requirements are
known as the functional requirements, and the
technical requirements are known as the non-
functional requirements or constraints. In
other situations, the technical requirements
are known as technical specifications, or just
specifications. Technical requirements are not
goals - they are requirements!
 This unit (ICAA5158A) will give you the
knowledge and skills to translate business needs
into technical requirements.
 Technical requirements may be used by a
development team to create a solution. At other
times, the technical requirements may be used
to validate the specifications for software
purchased off the shelf.

4. The topics for this unit are as follows:
 Compile business needs
 In this topic, you will learn how to clarify the business problem
and identify business opportunities as well as identify the
strategic direction and vision of the organisation and document
business needs.
 Determine technical requirements
 In this topic, you will learn how to identify technical requirements
by accessing the business problem, determining interface and
processing requirements and determining functional constraints.
Once the technical requirements have been determined
 Secure sign-off for technical requirements and solutions
 In this topic, you will learn how to manage the end of stage for
the sign-off process.

5. Compile business needs
 clarify the business problems and confirm
information with stakeholders
 identify the vision, strategic mission and
objectives of the business or business process
 identify key stakeholders and their
requirements
 document business objectives and problem and
confirm details with the appropriate person.

6. Clarifying the business problem
 You need to establish the business problem or
opportunity before you begin translating
business needs into technical requirements.
 This will often be documented in the business
requirements document or report.
 There are various techniques used to define and
refine the project needs such as interviews with
the client, online surveys or forms, user
discussion groups and questionnaires with
samples of the target audience. The major
purpose of this analysis is to develop an
understanding of what is achievable within the
project constraints.

7. Clarifying the business problem
 The process of needs analysis may result in a separate
business needs report, especially on large projects. On
smaller projects, the needs analysis and the information
gathered can often be documented with the proposed
solution in the one document.
 The main paragraphs of interest in this report are the
problem statement or opportunity statement, and the
functional requirements. The functional requirements
describe the way in which the different components and
functions in the solution will interact. The functional
requirements will further clarify how the solution is going
to work and how users will use it. If a business
requirements document or report has not been
completed, you will need to conduct a needs analysis.

8. For most IT applications, the needs analysis will broadly focus on
three aspects by analysing the following perspectives:
 business perspective – eg outline of the current
business climate, structure of the company and the
emerging industry issues that are driving this project –
the primary business aim or product
 technical perspective – eg outline of IT systems and
infrastructure of the company (including PC types,
numbers and locations, details on browsers, operating
systems, servers, security policies, networks and
bandwidth capacity)
 human perspective – eg outline the motivation of staff
to use new IT systems. This may also cover such
considerations as PC literacy, industrial relations issues
for staff, legalities and even language issues for users.

9. Methodology
 Some IT managers and analysts believe
that this style of methodology is a positive
way to approach IT development. The
idea behind it is to ensure that as an IT
professional, you focus on the solution
from all major angles. A common criticism
in the past has been that IT developers
have focused too heavily on the
technology and not enough on the users’
needs or the long-term business goals.

10. Identifying the vision or strategic
mission
 The business needs that have been identified
should align with the vision or strategic mission
of the business; however, often the system for
which you are writing the technical requirements
is only a small portion of the total business
systems. In this case you will need to clearly
understand the processes and procedures that
the new system will replace or automate. The
processes and procedures will form part of the
technical requirements.

11. Identifying stakeholders
 With the business requirements
established, your job will be to develop the
technical requirements. Sometimes these
are known as the non-functional
requirements or constraints. In order to
document the technical requirements, you
need to identify key stakeholders within
the business and stakeholders external to
the business. Their needs will form part of
the technical requirements.

12. Activity 1 – Stakeholders
 Select an IT project that you are familiar
with. Attempt to document all the
stakeholders involved with this project.
Divide them into two groups (internal and
external).
 Comment on the issues that may arise if
all the key stakeholders are not involved in
the project.

13. Documentation
 Technical requirement reports vary significantly
in content and there is not a definitive template
for writing the report. Your organisation or
project sponsor may request specific content in
the report, or the content may be at your
discretion. A technical requirements report for an
e-commerce website will have significantly
different content than a technical requirements
report for a database, software or network
system. There are some basic issues to
consider when analysing hardware and software
when creating a technical requirements report.

14. Hardware
 Compatibility – will the solution work with existing and future
systems?
 Support all formats – will the systems and architecture support all
types of media?
 Will the system be supported by existing resources within the
company?
 Is there funding available for new hardware (eg new servers)?
 What is the business disaster recovery and continuity strategy? Has
this been costed?
 Are there time restrictions or time delays for procuring hardware?
Will you be relying on another workgroup to set up the hardware? If
they don’t consider your project a priority, is that time delay factored
into your delivery strategy?
 Can other projects help absorb the cost of hardware?
 Is the network able to cope with the increase in bandwidth usage?

15. Software
 What is the total cost of ownership of the software?
 Are there licensing issues? (As the system is in development, should you
pay for all the licensing now or when the system is in development/live
mode?)
 Can the software be licensed for use by multiple users who use it on
different machines (concurrent licensing)?
 How long has the software been on the market? When is the next release
due? How stable is the release?
 What happens if the software company becomes insolvent? Who supports
it?
 Who owns the source code?
 What happens if the source code is modified – who supports the product
then?
 Does the solution work with all other company software systems?
 If web-based, does the solution function on all common browsers?
 Can the software be delivered in a ‘locked down’ format?
 Is the software cross-platform compliant?
 Is the software easy to use or are there major training issues and costs?

16. Activity 2 – Factors that
influence business decisions
 When preparing business needs
requirements documentation, issues like
policy changes, company takeovers,
industrial relations or legislative changes
often have a major affect on the business.
Select a project you are familiar with and
discuss how two of these issues
influenced the business decisions.