Introduction

The competence “Gathering Data on Business Requirements” provides information

and activities to enable you to gain the skills required to identify the needs of a business or
business process and quantify those needs into technical requirements that will enable the
business or process to meet expectations.

LO1: Identify key information sources

In this topic, you will learn how to identify information repositories, review organisational
documentation, develop critical questions to elicit information from stakeholders and
ensure that quality information gathering techniques are used.

LO2: Gather data through formal processes

In this topic, you will learn how to conduct information gathering workshops and
interviews, review reports and other data sources for relevant business information,
confirm business-critical factors, and analyse group and individual responses to define
business priorities.

LO3: Ensure analysis is accurate and complete

In this topic, you will learn how to analyse and evaluate information gathered for accuracy
and consistency, and how to document and resolve conflicts in the information gathered
with stakeholders.

LO4: Submit analysis and gain agreement

In this topic, you will learn how to prepare a report according to organisational
documentation standards for the purpose of communicating data gathered and gain
consensus and agreement on business requirements.

Page | 1
LO1: Identify key information sources

Overview

This resource will help you to identify key information sources within information
technology environment.

In this topic you will learn how to:

 Identify information repositories across the business
 Review current organisational documentation
 Develop critical questions to elicit information from key stakeholders using
a mixture of open and closed questions
 Ensure information gathering techniques use a quality assurance
methodology and meet budgetary constraints
This topic contains:

 Information Sheet

 Self check

 Operation sheet

 LAP test

Identify key information sources

Information sheet
 Information sources
 Searching for information and data
 Categories of data
 Statistics and sampling
 Review Documents
 Assess methods
 Interviews
 Questionnaires
 Observation
 Workshops
 Summary

Page | 2
Information sources

Defining information
So what is information? What is the relationship between information, data and
knowledge?

When information is entered and stored in a computer, it is generally referred to

as “data.” After processing (such as formatting and printing), output data can
again be perceived as “information.” When information is packaged or used for
understanding or doing something, it is known as "knowledge".

Within this resource, the conceptual boundaries of data and information blur when
we talk about gathering information and data to define the business and user
needs. At the end of this topic you should be armed with sufficient information to
gain an understanding of the business requirements - you should have acquired
knowledge.

Searching for information and data

When you start your investigation, you will find that there is a wide variety of
information sources available to you such as organisational charts, internal
memos and product catalogues. You will be able to extract information easily from
some sources; with other sources, the extraction process is complex. Some
sources provide reliable information; other sources may be obsolete or biased. It
is your task to define the location of information sources and extract meaningful
and reliable information with a reasonable effort to satisfy the requirements of a
project.

Data or information may be collected from within the organisation (internal) or it

may be sourced from external organisations. In order to collect the right
information, you may need to read many documents and interview many people.

Categories of data

Quantitative vs. qualitative data

You may need to source quantitative data or qualitative data. Quantitative

data can be measured. Sources include reports for decision making, performance
reports, data capture forms, and numeric results from surveys and statistical

Page | 3
research. Quantitative data can be analysed using mathematical equations and
computation. Care needs to be taken to ensure that quantitative data is current
and reliable - you may want to investigate the method of data capture and
processing.

Qualitative data is a record of thoughts, observations, opinions or words.

Qualitative data often comes from asking open-ended questions to which the
answers are not limited by a set of choices or a scale. Qualitative data is
important to capture; it may be in the form of memos, procedure manuals, survey
responses, workshop results or policy guidelines. Care needs to be taken when
analysing qualitative data to ensure that the information or data has not been
authored in a way to bias or politically motivate receivers of information.

Internal vs. external data

The information you gather may come from internal or external sources. Internal
sources are those found within the organisation; for example, annual reports,
sales figures and employees.

External sources are sources outside the organisation such as statistical

information, standards documentation, or research conducted by external
organisations.

The project in which you are involved will influence the balance of the internal or
external information gathering effort. For example,

 A website design and development project may require you to gather and
define internal requirements of a business. However, a significant effort
should be put into external scanning. This may involve identifying 'best
practice' associated with competitors or organisations with similar
business models.

 A database design requires a significant proportion of internal data

gathering, but as with website design, you should not exclude current
trends and future expectations which may be evident through external
scanning.

Page | 4
Documents vs. people

A review of the organisation's documents provides a good background and is often

the starting point to understanding the organisation and how internal systems
work.

Documents form a good base for further investigation. There are often a lot of
documents available, which means the analyst must read extensively to gain
limited information.

On the other hand, people are also a source of information. An individual is a

wonderful source of information that can respond dynamically to questions and
stimuli. This unique characteristic of the human race enables fast and focused
exchange of information through many communication mediums.

The advantages of gathering information through interviews, workshops and

questionnaires must also be balanced with a degree of scepticism. When you
gather information from an individual, you gather an individual's opinion. It’s
important to remember that this opinion may (and probably will) differ from the
opinions of others.

Sampling
When determining requirements, it is likely that you will have to collect
information from a number of people. If the organisation is small, you may choose
to collect information from all people - this is called a census. Alternatively, you
may choose to collect information from only nominated specialists. This is known
as judgement sampling or convenience sampling. Not all organisations are
small and localised: consider determining requirements for an organisation with
over 2000 computer users spread across 4 continents. In this situation, it is
prudent to survey a sample of users. Two commonly used sampling techniques
are randomisation and systematic sampling.

 Randomisation is a sampling technique characterised as having no

predetermined pattern or plan for selecting sample data.

 Systematic sampling is a technique that attempts to reduce the variance

of the estimates by spreading out the sampling. One example would be
choosing documents or records by formula which avoids very high or low
estimates.

Page | 5
The use of sampling is much more time efficient, and that is why sampling is so
commonly used. Unfortunately, the improper use of sampling can lead to
methodological disaster.

Review the current organizational documents

Documents and information
An organisation stores a large number of documents such as policy documents,
finance statements, annual reports and mission statements. These documents can
provide valuable information when analysing user requirements. For example,
mission statements may provide information regarding organisational goals. You
may be required to review these documents to identify the kind of information
they contain. The contents may be useful in the business requirements analysis.

Sources of information
When conducting a business user-requirements analysis, it is important to identify
the sources of information. You will need to select different sources of information
in order to gather complete and accurate information.

The following list provides some examples of information sources.

Table 1: Information sources

Repository/source Information required

Management To establish objectives, boundaries, constraints, policies,

information requirements, involvement in the project,
potential problems.

Clerical/operational staff To establish actual procedures carried out, documents

used, volume of work, job satisfaction, morale.

Statements of company These will provide information on overall objectives and

policy including likely changes.

Organisation charts Identify reporting responsibilities and staff

names/positions.

Administrative procedure QA documents, instruction and procedure manuals which

manuals provide a statement of the way in which tasks are
supposed to be performed.

Document blanks or data These are forms that are filled in and passed between
entry forms departments or stored for reference. This gives the
analyst an indication of the formal data flows and data
stores.

Completed documents or These are forms that have been filled in and passed
data entry forms between departments or stored for reference. These give
the analyst an indication of the 'actual' data that is
currently required.

Training manuals To identify processes and procedures.

Page | 6
 Sales and promotional To identify products; company image; marketing style;
literature target market.

Job descriptions and These should define the responsibilities of personnel.

specifications

Reports for decision Reports may include: sales; inventory; production;

making costing.

Performance reports Identify gaps between actual performance and intended

performance.

Intranet and website Examine for metaphors, design features (such as colour).
The intranet will be a valuable resource that can be
searched for electronic copies of documents.

Memos and letters May provide background for your problem statement and
ultimate solution.

Organisational documents provide invaluable sources of information for analysing

business needs. When gathering data for business needs, it is common to review
organisational documents and categorise them according to the type of
information they provide.

Assess methods

Data gathering methods and budget constraints

There are a variety of different data gathering methods, and each have their own
advantages and disadvantages. You will need to research the advantages and
disadvantages of these methods. While you are undertaking your research, take
notice of the relative costs associated with each method.

Your research should highlight that questionnaires are an effective method of

capturing data from a large group of people at a relatively low cost; however, if
the sample group is small, sometimes the questionnaire development costs
outweigh the benefits. In the past, questionnaires have often been paper-based. A
cost associated with paper-based surveys is the coding and transcribing of the
responses into a computer for analysis. Using computer-based questionnaires
reduces costs associated with coding and transcribing data.

You may find through your research that some authors refer to workshops as
activities that last several days, involve high-level management and are
conducted at remote locations using high-tech equipment. But this need not be
the case. Given this insight, workshops are sometimes classified as an expensive
method. This is due to costs associated with the venue, computing infrastructure,
facilitator and management wages. However, if done correctly, workshops can
return significant results in a short period of time because issues can be explored

Page | 7
from a variety of perspectives, and resolutions can be arranged from a team
perspective.

When determining requirements, the most common method of gathering data is

the interview. The interview is usually a cost-effective method of gathering goal-
focused information associated with the business requirements.

Reviewing documents

Reviewing documents is the process of searching, finding and extracting

information from documents which have been created by authors. A listing of
documents can be found in Table 1: Information sources.

If you are developing a website with e-commerce facilities, it may be worthwhile

reviewing customer order forms and documents identifying sales processes and
procedures. If you are interested in identifying the number of items per order or
the number of incorrect orders received from customers, you may need to sample
records kept by the organisation.

Interviews
An interview is a planned meeting during which you obtain information from another
person. The personal interview is often the preferred information gathering technique when
developing business and user requirements.

The interviewer can contextualise the response by observing body language. Body language
is all of the non-verbal information being communicated by an individual. Part of body
language is facial disclosure. Facial disclosure can sometimes enable you to understand
how people feel by watching the expressions on their faces. Many common emotions have
easily recognizable facial expressions.

Now let’s look at the most common steps that take place during the interviewing process.

1. Determining the people to interview

You need to determine the people that can best satisfy the answers to your questions.
Organisational charts and job specifications can help to identify appropriate people to
interview. Table 1: Information sources, provides a list of information sources that may be
useful in determining the right people with which to speak.

2. Establishing objectives for the interview

Page | 8
You need to be clear about what your objectives are for the interview. To do this, you
should determine the general areas to be discussed, then list the facts that you want to
gather. The objectives of the interview will depend on the role of the person being
interviewed. Upper management provides a "big picture" or overview which will help you
understand the system as a whole. Specific details about operations and business
processes are best learned from people who actually work with the system on a daily basis.
Examples of goals can be found in the topic “Gather data through formal processes.”

3. Developing the interview questions

Creating a list of questions helps you keep on track during the interview. It is appropriate
to include open and closed questions during the body of the interview. Extended discussion
on questions can be found in the topic “Gather data through formal processes.”

4. Preparing for the interview

Preparation is the key to a successful interview. It is often easy to detect an unprepared

interviewer. The interviewee is providing their valuable time, so you, as the interviewer,
must be prepared. The interviewer should book and confirm their appointment times and
venue. In addition, the goals or subject matter of the interview should be communicated to
the interviewee.

5. Conducting the interview

An interview can be characterised as having three phases: the opening, the body and the
conclusion.

During the interview opening, the interviewer should explain the reason for the interview,
what the interviewer expects to get out of the interview, and motivate the interviewee to
contribute to the interview.

The interview body represents the most time-consuming phase where you obtain the
interviewee's responses to your questions and focus on your well-defined objectives.

Most interviewees will expect or at least permit you to take notes. Some interviewers use
audio note-takers. While this can capture the entire interview, some interviewees may be
hesitant to express their opinions if they know that they have been recorded on tape.
Typing on laptop computers can also be distracting during the interview process.

The interview conclusion allows you to summarise your understanding of the data
gathered during the interview. You should express your appreciation for the interviewee's
valuable time and instil a sense of value for the interviewee. You may need to follow-up

Page | 9
with more questions, so the conclusion is an important time to develop rapport and trust
with the interviewee.

6. Documenting the interview

It is important that you transcribe your notes into a format that allows you to understand
the information gained at the interview. Sometimes, inexperienced interviewers do not
capture the interview in writing until some time after the interview. In these cases, the
interviewer may lose many of the valuable facts gained in the interview. Some interviewees
request copies of the interview transcript. This can be helpful in prompting the interviewee
to volunteer information inadvertently omitted in the interview.

7. Evaluating the interview

It is important to review your notes and transcript to identify any areas of problem, bias or
errors. The review may prompt further questions that need to be answered.

Questionnaires

Questionnaires are sometimes called surveys. A questionnaire involves questions written

onto a form. The respondent provides their response in the form.

Two common formats for questionnaires are free-format and fixed-format. A single
questionnaire often includes both formats.

 Free-format questionnaires offer the respondent greater latitude in their

answer. A question is asked, and the respondent records the answer in the
space provided after the question.

 Fixed-format questionnaires contain questions that require the selection of

predefined responses from individuals.

A typical questionnaire starts with a heading or title. This is usually followed by a brief
statement of purpose and contact details for the person distributing the questionnaire.
Often an introductory paragraph includes the deadline date for completion, as well as how
and where to return the form. Instructions should be provided to give clear guidance on
how to complete the form. Headings can be used to separate sections of the questionnaire.
Your questionnaire may request the name and/or job role of the respondent; however, it
has been found that anonymous responses often provide better information.

Questionnaires do not have to be paper-based. You may choose to distribute electronic

questionnaires via e-mail, or you may request that respondents access a website and
complete a questionnaire online.

Page | 10
Observation
Observation is a technique that enables the analyst to view how processes and activities
are being done in the context of the business. This additional perspective can give a better
understanding of system procedures. It is sometimes worthwhile to read procedure
manuals to find out how things should be done. Then interview people to find out how they
believe it is being done. Finally, observe processes to find out how it is actually being
done.

Brainstorming
Brainstorming is a workshop or meeting where ideas are expressed and captured for later
consideration. The three common rules of brainstorming are:

 Be spontaneous. Call out ideas as they occur.

 No criticism, analysis, or evaluation is permitted while the ideas are being

generated. Any idea may be useful, if only to generate another idea.

 Focus on the quantity of ideas, rather than the quality of the ideas.

Summary
In this resource you have identified the difference between data, information and
knowledge. You are aware that there are different sources of information. These include
internal or external, documents or people and the data you collect may be qualitative or
quantitative data. When selecting samples, you may choose a census, a judgment
sample/convenience sample, randomised sample or a systematic sample. From each of the
nominated information sources you can expect to get a variety of information.

Self Check

1. According to your readings, qualitative data can be defined as follows:

“Qualitative data is a record of thoughts, observations, opinions or
words.”
A. True B. False
2. Collecting information from only nominated specialists is called:
A. convenience sampling
B. judgement sampling
C. all of the above.
3. What of the following is NOT usually regarded as a step of the interview
process?
A. determine the people to interview
B. develop interview questions
C. close the interview

Page | 11
 D. conduct the interview
4. What is NOT true about ‘Quantitative data’?
A. it is subjective
B. it can be measured
C. it can be analysed through mathematical equations
D. all of the above

Page | 12
LO2: Gather data through formal processes

Overview
You should already know about identifying key information sources. This resource will help
you gather data through formal processes within an information technology environment.

In this topic you will learn how to:

 conduct information gathering workshops and interviews to gather data

 review reports and other data sources for relevant business information

 confirm business-critical factors relating to current and future directions of the

organisation with stakeholders

 analyse group and individual responses to clearly define business priorities

Contents
 Defining the problem/opportunity
 Bias, Sensitivity and Plasticity
 Implement questions
 Functional requirements
 Non–Functional requirements
 Summary

Regardless of whether you are implementing an interview, questionnaire or structured

workshop, you need to consider carefully how you develop questions for stakeholders.
Developing appropriate questions will determine the quality of the information you gather.

Every time you are asked a question, you have to engage thinking skills in order to answer
the question. Sometimes you know the answer – it will be obvious to you! For other
questions, you will need to think deeply about the answer. In this section, we will be
exploring questions that can be answered easily and questions that require significant
thinking. We will be looking at types of questions and classifying questions as open or
closed questions.

In the activities, you will be required to convert open questions to closed questions and
closed questions to open questions.

Defining the problem/opportunity

The very first stage in requirements determination is the identification of the problem or
opportunity. Once this is established, you will need to gather information to understand the

Page | 13
problem and any constraints that may limit the solution. The next section briefly discusses
problems or opportunities within the context of system development.

Problem / Opportunity statements

In order to implement data–gathering techniques, you will need to identify one of the
following:

 the problem that has to be solved

 the opportunity that has to be realised

Once the problem or opportunity has been identified, it should be documented. This can
then be included in a Business Requirements Report under the heading ‘Problem
Statement’ or ‘Opportunity Statement’.

 Problem Statements may use key words like cannot, will not and unable to.

 Opportunity Statements may use key words like would like to, leverage and
evolve toward.

Both problem and opportunity statements should include the organisation’s name and a
brief outline of the problem / opportunity.

The following is an example of a Problem Statement:

Eg. The XXX Company cannot efficiently update records to their database.

The following is an example of an Opportunity Statement:

Eg. The XXX Company would like to increase sales through an e–commerce website.

The problem or opportunity statement is usually ascertained from business owners or

project sponsors. It is a high–level statement that concisely captures the problem or
opportunity. Details associated with the problem or opportunities are documented in the
functional requirements. These are sometimes called the business requirements.

Goal setting
Questions should be used to achieve well–defined goals. Without goals, an analyst may lose
focus and waste time. Without goals, incomplete data may be gathered.

The first task in developing questions is to determine what facts and/or opinions must be
collected and from whom you should collect them. Your objectives should be based on the
stated or perceived problems or opportunities for the business. Problem and Opportunity
Statements have already been discussed above. Examples of questioning goals include the
following:

 identifying the processes associated with completing a sale

 identifying the computing resources of an organisation

 identifying questions most often asked by customers (FAQs)

Page | 14
  Identifying the client’s expectation for a system (eg. what is the reason for
developing a website?)

 identifying current process that may be automated with a new system

Before commencing an interview, workshop or developing a questionnaire, you must define

the goals that you want to achieve.

Open and Closed Questions

In addition to asking questions at various levels of the taxonomy, an analyst might consider
whether they are asking closed or open questions. There is some debate over what
defines an open or closed question.

Generally a closed question is one in which there are a limited number of answers, most of
which will usually be categorised by the analyst. In addition, the answers to closed
questions are usually one word or a short phrase. In its simplest form the answer to a
closed question may be limited to “yes” or “no”.

An example of a closed question might be the following:

“Do you put a job number on the work request form”

An interviewer who uses this method of questioning will only get their own opinion
confirmed and may not get any new or relevant information at all. Such a style of
questioning may also be very frustrating for the interviewee, who may never get the
chance to elaborate on what they think is important.

An open question is one to which there are many answers, most of which will not be
anticipated by the analyst. An example of an open question might be the following:

“Tell me what happens when the work request form comes in?” or even better

“Tell me what you do about work requests.”

It could well be that the work request form described might represent only a fraction of the
processing done or might be completely out of date, superseded by new procedures
devised by the workers to tackle problems.

It is always advisable, at some point - often near the end of an interview - to simply ask
the ultimate open question:

“Now, have we missed anything?” or “Is there anything else you would like to say?”

There are also some disadvantages to open questions, which could include the following:

Page | 15
  trying to summarise the data into a concise form may be difficult

 it takes a lot longer to collect information

 ambiguities need to be recognised and expanded upon

 open questions require more psychological effort on behalf of the respondent, and
the respondent may answer in a haphazard manner.

Functional requirements
The very first stage in requirements determination is the identification of the problem or
opportunity. Once this is established, you will need to gather information to understand the
problem and any constraints that exist that may limit the solution.

Once the problem has been identified, the next step is to do the following:

 Understand the problem, including the cause and effect

 Understand any constraints that may limit the solution.

Defining the functional requirements requires a significant proportion of information

gathering, then an analysis of the information gathered. Whitten, Bentley & Dittman (2001)
define functional requirements as:

“A functional requirement is a function or feature that must be included in an information

system in order to satisfy the business need and be acceptable to the users.”

Functional Requirements are actions; therefore a verb(s) should be included in the

statement. In addition, functional requirements can be either mandatory or desirable. The
use of Must or May will identify the strength of the requirement. Functional requirements
may become the Acceptance Criteria at the end of the project - that is, your project
success is measured on the attainment of the Functional Requirements.

Functional Requirements (and possibly non–functional requirements or constraints) should

be included in a Business Requirements Report under an appropriate heading.

Here are some examples of possible mandatory and desirable functional requirements.
Note the use of must or may in each statement!

 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 may track the completion status of customer special orders.

 The system must provide a users’ guide for products.

 The system must capture customer details online.

Page | 16
  The system may have password protection for a members’ only section.

In the above functional requirements the word “system” can be replaced by a more
meaningful descriptive word. Here are some examples:

 The website may have password protection for a members only section.

 The database must retain customer details.

Non–Functional requirements
“A non–functional requirement is a description of the features, characteristics, and
attributes of the system as well as any constraints that may limit the boundaries of the
proposed solution”

Some authors use the term “constraints” to identify non–functional requirements.

Note: Non–functional requirements are less important to the Business

Requirements report – but highly important to the Technical Requirement report. It is

important to understand the difference between functional and non–functional
requirements.

Non–functional requirements are often associated with the technical requirements of a

system – therefore the non–functional requirements may be part of the Technical
Requirements Report rather than the Business Requirements Report. Your organisation or
client will often specify the format and content of the required report.

In this section, you have looked at functional requirements which should appear in the
Business Requirements Report. Functional requirements are sometimes known as business
requirements, and non–functional requirements are sometimes known as constraints.
Constraints may limit the project or solution.

Summary
In this Topic you have identified that a problem statement or opportunity statement needs
to be defined at the beginning of the project. You then use data–gathering techniques to
understand the problem, including the cause and effects, as well as identifying constraints
that may limit the project or solution. Problem/opportunity statements and functional
requirements should all appear in the Business Requirements Report.

Self Check

……………………………………………………………………………………

1. Problem statements usually do NOT include which of the following key words?

Page | 17
 A. cannot
B. will not
C. would like
D. all of the above

2. What type of question is this: “Do I need to write my name in this box on this
form?”

A. open
B. closed
C. neither

3. What type of question is this: “Tell me about your holiday.”

A. open
B. closed
C. neither

Page | 18
LO3: Ensure Analysis is Accurate and Complete

You should already know about identifying key information sources and gathering data
through formal processes. This resource will help you to ensure analysis is accurate and
complete within an information technology environment.

In this topic you will learn how to:

 analyse and evaluate information gathered for accuracy and consistency

 document conflicts in information gathered

 resolve conflicts in information or points of view with stakeholders

Contents
 When to Analyse
 Prioritising requirements
 Capability analysis
 Summarising business requirements
 Summary

When to Analyse
Broadly speaking, you will analyse data as you collect it and/or once it has been collected.

Analysing when collecting data

During an interview or workshop you may be collecting and analysing data at the same
time. Often you ask a question that prompts a second or third question. In this situation,
you are attempting to clarify or classify the initial response received. The follow-up
questions are usually either probing questions or classification questions.

Workshops typically involve data collection and analysis in real time.

Analysing data already collected

Data collected from several interviews and/or data collected from questionnaires need to be
aggregated and collated into meaningful information. The analysis technique involves
identifying similarities and disparities between data.

Organising and Summarising

Once you have classified data into meaningful categories, it should be documented in
tables and summarised in a paragraph. Often data in tables can be visually represented
through the use of charts. You need to carefully select the type of chart to match your
data.

Page | 19
Prioritising requirements
Once you have classified data into categories, you have completed the first stage of
analysis. We are interested in business requirements; therefore, the output from the first
stage of analysis should be a list of business requirements (or functional requirements).
The next stage is to rank the importance of each requirement. Consider a website, for
example. Are each of the requirements below equal in importance?

The system must

 conduct transactions over the Internet

 display products on screen

 provide an animation of the production process

 display a privacy policy

 link Internet sales to the inventory system

 display a returns policy

 enable a "contact us" facility

 enable customers to check delivery and production status

 provide "about us" information

 display customer satisfaction testimonies

 provide a user's guide for products

 capture customer details online

 have password protection for a "members only" section

 display correct pricing - especially for customers with discounts

 describe products

 accept multiple payment methods.

You may have noticed that some requirements are dependent on others. For example, as
soon as you capture customer details of any kind, you must have a privacy policy - this is a
requirement under Australian law (with a few exceptions). You cannot display delivery and
production status unless you enable customers to key their details into the system.

Given the dependencies within the requirements list, you should order the list for
importance. But your ranking is just that - your ranking! You also need to establish the
organisation's ranking of importance. The easiest way to receive feedback on the
importance of business requirements is to present the key stakeholders with a list of
requirements and ask them to rank the list by importance.

A little caution needs to be taken when collating and analysing the results of the ranked
list. You need to consider who responded to the request and their importance within the
organisation. For example, if the distribution list included five from sales and marketing yet

Page | 20
only one from finance, the results may skew toward sales. As another example, the
business owner may want their response to be weighted three times the strength of their
management team. The examples above could be extreme, but it is prudent to discuss the
distribution list and respondents' relative weighting with the project sponsor.

The absolute ranking is important, but relative ranking is also important. To use the
example above, where there are 16 items listed, it should not be inferred that the item on
the top of the list is 16 times more important than the item on the bottom of the list.
Perhaps the item on the bottom of the list is only 50% less important. For this reason, a
relative importance should be allocated to the requirement. A scale of 5-10 is frequently
used when allocating the relevant importance of a business requirement. The reason for a
relative scale becomes apparent in the next section: "Capability Analysis".

Considering available resources

Once you have ranked and rated the requirements by importance, you have
completed the second analysis stage. By now you should have a list of business
requirements (functional requirements), and you should know how important they are to
the organisation.

Question:

Should we implement all of them?

Answer:

"All things are possible given enough time and money."

The answer to these questions requires the application of the third stage of analysis:
Capability Analysis.

Capability analysis
In order to estimate the ease of realisation, you need to know the following:

 your capability

 the capability of your client

 the capability of your organisation

 the capability of any other organisations that you may incorporate into the project

 the capability of the tools that will be used to develop the solution for the client

Often a specialist or project manager who has experience in the field will rate the ease of
realisation for a given business requirement.

Page | 21
A simple method of applying capability to business requirements is to simply rate the ease
of realisation between 5 and 10, where 10 is the easiest and 5 is the hardest. Once you
have the ease of implementation, multiply it by the relative importance of the requirement.

Summarising business requirements

By now, you should have a list of requirements that has been ordered by importance and
ease of realisation. The final stage is to estimate how many of the requirements can be
implemented given the available time and money. Again, there are various techniques to
establish the boundaries, but put simply, you need to draw a line through the requirements
list and identify what you can achieve and what you cannot achieve.

The requirements that you can achieve become mandatory functional requirements
and retain the verb "MUST". The requirements that you cannot achieve become optional
or desirable functional requirements and the verb "must" changes to "MAY".

For example:

 The system must display products on screen.

 The system may enable customers to check delivery and production status.

Summary
Proposed website business requirements (functional requirements):

The issue that faces you now is: how easy is it to implement (or realise) each of the
requirements? In other words, how many of the requirements can you implement in a
given time frame and within a given budget?

For example:

This resource has shown that you may analyse data as you collect it or once the data has
been collected. When you begin your analysis, you need to classify and categorise data
based on similarities and disparities within the data. You need to write a brief paragraph
supporting your findings, and you may choose to use graphs to illustrate the results.

At the conclusion of the first stage of analysis, you should have a list of business
requirements, and you may be able to identify dependencies between requirements.

The second stage of analysis involves distributing the list back to key stakeholders so
that they can rank the business requirements in order of importance. Importance may be
absolute or relative.

The third stage of analysis involves identifying capabilities and applying an "ease of
realisation" rating to the requirement.

Page | 22
The final stage involves estimating how many requirements can be achieved given a
specified budget and time frame. Requirements that can be achieved become mandatory
functional requirements and the requirements which cannot be achieved become
desirable or optional functional requirements.

Self Check

……………………………………………….

1. A workshop typically involves data collation and analysis after the workshop has been
completed.
A. True B. False

2. What is the output from the first stage of analysis?

A. a list of business requirements

B. a list of key stakeholders
C. an opportunity or problem statement
D. a list of technical requirements

3. The business requirements that you CAN achieve and which are described using
the word “must” are called:

A. optional functional requirements

B. desirable functional requirements
C. mandatory functional requirements
D. all of the above

Page | 23
LO4: Submit Analysis and Gain Agreement

Overview
You should already know about identifying key information sources, gathering data through
formal processes, and ensuring that the analysis is accurate and complete. This resource
will help you to submit an analysis and gain agreement within an information technology
environment.

In this topic you will learn how to:

 prepare detailed documents according to documentation standards and

organisational templates

 write documents in a style that is succinct and appropriate to the audience

 communicate data gathered to the client to gain consensus and agreement on

business requirements

Contents
 Report findings
 The requirements report
 Summary

Report findings
The contents and degree of detail for a Requirements Report will vary depending on the
size and scope of a project, but a Requirements 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. The next section describes the purpose of the different sections of the
report.

The requirements report

There are many templates available for writing a Requirements Report. This section looks
at one possible report layout. Here are some examples of alternative report layouts:

Note: This resource discusses gathering data for business requirements only. The
report template described here covers a wider context than just business
requirements.

The following headings may be used in a Requirements Report:

Page | 24
  Introduction

 System description

 Functional requirements

 Non-functional requirements

 Information domain

 Project costs

 Benefits

 Other project specific topics

Table 1: The table below summarises what each heading contains.

Requirements definition report elements

Introduction Purpose

Scope

Definitions

Overview of document

Systems description Overall system

Sub systems

Operating environment

Functional requirements Logical view

Physical view

Non-functional requirements Performance

Quality

Business rules

Information domain Data definitions

Structure

Project costs Analysis

Software development

Hardware and network

Benefits Tangible

Intangible

These headings are described in detail below.

Introduction

The introduction defines the purpose of the document with a summary of the entire
document.

The introduction should describe the scope of the system—i.e. what functions the system
will implement.

Page | 25
System Description

This describes 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 the main functions to the client.

Functional Requirements

The functional requirements define the services that the system provides. Examples of
mandatory (“must”) and desirable (“may”) functional requirements might be:

 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

Case diagrams, Data Flow diagrams and State chart diagrams are common
techniques used to describe the system’s functions.

Summary
Once you have gathered information through interviews, workshops, etc. you need to
report these findings in a clear, concise and systematic fashion. The purpose of the report
is to gain agreement from the client on the objectives of the proposed system.

There are a variety of different report formats. Your organisation or client may require a
specific report format.

Self check

…………………………………
1. What is the purpose of the Requirements Report?

A. to communicate the requirements

B. to confirm the requirements
C. to gain agreement from the client
D. all of the above
E. none of the above

Page | 26
 2. Non-functional requirements define any _________ within which the current
system operates.

3. The functional requirements define the services that the system provides.

A. True B. False
4. What is considered a common technique used to describe the system’s
functions?
A. case diagrams
B. data flow diagrams
C. statechart diagrams
D. all of the above
E. none of the above

5. Benefits that are measurable in money are known as _______ benefits.

Page | 27