Department: Information and Telecommunication Technology Sector_

TVET –Program Title: Database Administration _ Level:III Year: 2

Course /Module Title: Gathering Data to Identify Business Requirements

Ac. Year: 2013 E.C

Nominal Duration: 30 hrs Hours: Periods / Week: Semester:

Course / Module Code: EIS DBA3 M04 0517 Program: (Reg/Ext) Regular

Name of the Trainer:

Course / Module Description

This module defines the competency required to identify, analyse and document business requirements.

Leaning Outcomes (Objectives):

At the end of the course / Module, the trainee will able to:

LO1. Identify key information sources

LO2. Gather data through formal and informal processes
LO3. Ensure analysis is accurate and complete
LO4. Submit analysis and gain agreement

Duty (Chapter)
I.
1.
2.
II
1.
2.
Course / Module Assessment Methods:
References:
1. www.google.com
2.

Gathering Data to Identify Business Requirements

LO1: Identify Key Information Sources
1.1 Overview: Introduction to the module
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
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".
1.2 Identifying Information Repository
1.2.1 Sources of information
When conducting a business user-requirements analysis, it is important to identify the 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
To establish objectives, boundaries, constraints,
Management policies, information requirements, involvement in the
project, potential problems.
To establish actual procedures carried out, documents
Clerical/operational staff
used, volume of work, job satisfaction, morale.
Statements of company policy including These will provide information on overall objectives
mission statements and likely changes.
Identify reporting responsibilities and staff
Organisation charts
names/positions.
E.g. QA documents, instruction and procedure
Administrative procedure manuals manuals which provide a statement of the way in
which tasks are supposed to be performed.
These are forms that are filled in and passed between
departments or stored for reference. This gives the
Document blanks or data entry forms
analyst an indication of the formal data flows and data
stores.
These are forms that have been filled in and passed
Completed documents or data entry
between departments or stored for reference. These
forms
give the analyst an indication of the 'actual' data that

Gathering Data to Identify Business Requirements Page | 1

 is currently required.
Training manuals To identify processes and procedures.
To identify products; company image; marketing
Sales and promotional literature
style; target market.
Job descriptions and specifications These should define the responsibilities of personnel.
Reports may include: sales; inventory; production;
Reports for decision making
costing.
Identify gaps between actual performance and
Performance reports
intended performance.
Examine for metaphors, design features (such as
Intranet and website colour). The intranet will be a valuable resource that
can be searched for electronic copies of documents.
May provide background for your problem statement
Memos and letters
and ultimate solution.
1.2.2 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 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

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
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
 A database design requires with website design,

Gathering Data to Identify Business Requirements Page | 2

 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, to gain limited information. On the other hand, people are
also a source of information.
1.3 Reviewing Current Organization Document
1.3.1. Review Documents
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.
1.4 Ensuring Information Gathering Techniques
1.4.1. Assess Methods
Your task is to research different methods of information gathering. You will need to identify
the advantages and disadvantages of the different techniques as well as specific features of
some techniques. The techniques that we are interested in are:
Research(reviewing/sampling Questionnaires (surveys)
documents) Observation
Interviews Workshops
a) Research:
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.
Statistics and Sampling documents
Statistics is a method of representing numerical data.
Sampling documents is the process of collecting representative samples of forms, records and
other documents in order to ascertain an implied consistency for the total population. Two
commonly used sampling techniques are randomisation and stratification.
Randomisation is a sampling technique characterised as having no predetermined
pattern or plan for selecting sample documents.
Stratification is a systematic sampling technique that attempts to reduce the variance of
estimates by equally dispersing the sample selection within a given population - that is,
choosing documents or records by formula.
Table 2: In the following student enrolment example, the stratification is based on the course in
which the student is enrolled.
Student population = 3000
sample size 5% = 150 student enrolments
Course Student enrolments Sample size

Gathering Data to Identify Business Requirements Page | 3

 Law and Justice 200 10
Management Studies 800 40
IT Studies 1500 75
Engineering 500 25
Totals 3000 150
If you wanted to know what proportion of students requested a web-based email account, you
may need to select a representative sample of the university population. In the example above, a
selection of 150 records would give you a representative sample of the 3000 students.
b) 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. 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.
2. Establishing objectives for the interview
You should determine the general areas to be discussed, then list the facts that you want to
gather.
3. Developing the interview questions
Creating a list of questions include open and closed questions, helps you keep on track during
the interview.
4. Preparing for the interview
Preparation is the key to a successful interview of goals or subject matters.
5. Conducting the interview
An interview can be characterised as having three phases: the opening, the body and the
conclusion.
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.
Body: represents the most time-consuming phase where you obtain the interviewee's responses.
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.
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.

Gathering Data to Identify Business Requirements Page | 2

 7. Evaluating the interview
It is important to review your notes and transcript to identify any areas of problem, bias or
errors.
c) 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.
d) Observation
Observation is a technique that enables the analyst to view how processes and activities are
being done in the context of the business observes processes to find out how it is actually being
done.
e) Workshops
There are two main types of workshops that we are interested in as information gatherers: Joint
Application Design (JAD) - or Joint Requirements Planning (JRP) - and Brainstorming.
JAD
Joint Application Design (JAD) was developed by IBM in the late 1970s. It is a requirements
determination method that brings together business and IT professionals in a structured
workshop to determine and discuss system requirements.
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.
 Focus on the quantity of ideas, rather than the quality of the ideas.

Gathering Data to Identify Business Requirements Page | 3

1.4.2. Information and Data gathering methods and budget constraints
There are a variety of cost associated different data gathering methods, and each has their own
advantages and disadvantages.

When determining requirements, the most common method of gathering data is the interview.
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.

In order to collect the right information, you may need to read many documents and interview
many people.

Self Check LO1 Written Test

Name: _______________________________ Date: _________________

Instruction: Answer all the questions listed below, if you have some clarifications- feel
free to ask your teacher.

1. In your own words define the terms: data, information, Knowledge and statistics.
2. List the organizational documents that provide sources of information.
3. Describe the different methods of information gathering.
4. What is ‘Joint Application Development’ (JAD) Methodology?
5. Describe the meaning of the following terms:
a) Quantitative data c) External sources
b) Qualitative data d) Internal sources
Answer True or False:
6. Qualitative data is a record of thoughts, observations, opinions or words.
Answer the Letters:
7. What of the following is NOT usually regarded as a step of the interview process?
A. determine the people to interview C. close the interview
B. develop interview questions D. conduct the interview
8. What does JAD stand for?
A. joint application development C. junior application designer
B. joint application design D. all of the above.
9. What is NOT true about ‘Quantitative data’?
A. it can be analysed through C. it can be measured
mathematical equations D. all of the above
B. it is subjective

Gathering Data to Identify Business Requirements Page | 4

LO2 Gather data through formal processes
2.1. Overview
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
2.2. Gathering Data:
Designing questions is an important aspect of gathering data - you may not get the information
you need if you don't ask the right questions! This resource looks at the implementation of
gathering data - for example developing appropriate questions or conducting workshops.
2.2.1. Develop Questions
Regardless of whether you are implementing an interview, questionnaire or structured
workshop, you need to consider carefully how you develop questions for stakeholders. it is
important to consider what questions might be critical to unearthing key information
stakeholders have which you need to gather
Developing appropriate questions will determine the quality of the information you gather.
a) 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
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:
The XXX Company cannot efficiently update records to their database.
The following is an example of an Opportunity Statement:
The XXX Company would like to increase sales through an e–commerce website.

Gathering Data to Identify Business Requirements Page | 2

Details associated with the problem or opportunity is documented in the functional
requirements. These are sometimes called the business requirements.
Implementing questionnaires
One method of gathering information to identify functional requirements and constraints is by
implementing a questionnaire.
There are many software programs and techniques that can be used to create questionnaires.
Paper questionnaires
While these are being used less frequently you may choose to use paper in some cases, e.g.
where you want feedback from people quickly or where they do not have access to a computer.
MS Word questionnaire
Microsoft Office provides features that enable you to create questionnaires.
Online questionnaires
More commonly now people are choosing to have questionnaires delivered online, frequently a
link to a questionnaire is sent to the participants via email. One example of a free site that
enables the creation of questionnaires is
https://www.surveymonkey.com/
b) 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. 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
 identifying the client‘s expectation for a system (e.g. what is the reason for developing a
website?)
 identifying current process that may be automated with a new system.
Questionaries:
Low and high–level questions
The purpose of questioning is to elicit data or information that enables you to understand a
problem, requirement or possible solution from the respondent‘s point of view. The response
may be a fact, or it may be an opinion. An analyst may ask questions which require the
respondents to use thinking skills. Benjamin Bloom (1956) developed a system for organising
and categorising thinking skills in a hierarchical order from lower to higher level, with the
higher levels including all of the cognitive skills from the lower levels. The categorisation is
often referred to as ‗Bloom‘s Taxonomy‘.
Listed below are the levels of the taxonomy (categories):

Gathering Data to Identify Business Requirements Page | 3

Figure 1: levels of the taxonomy
Bloom‘s Taxonomy has its foundation in educational assessment; however, the concepts are
relevant for eliciting information for business requirements and system designs. If you are
conducting a workshop, for example, it would be appropriate to use the higher level questions
of Analysis, Synthesis, and Evaluation.

Open and Closed Questions

In addition, an analyst might consider whether they are asking closed or open questions.
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, may be limited to “yes” or “no”.
Example: “Do you put a job number on the work request form”
An open question is one to which there are many answers, most of which will not be
anticipated by the analyst.
Example: “Tell me what happens when the work request form comes in?”
or even better
“Tell me what you do about work requests.”
There are also some disadvantages to open questions,
 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.
Interviews
An interview is a planned meeting during which you obtain information from another person.
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?”

Note: Both open and closed questions may be used at any level of the taxonomy.

Gathering Data to Identify Business Requirements Page | 4

Bias, Sensitivity and Plasticity
Bias: From time to time, lobby groups bias questions in order to achieve a desired
result. An example of an intentionally biased question may be the following:
“Are you in favour of educational institutions requiring that all lecturers join a union,
thus raising educational costs?”
In this theoretical question, the information gatherer is not interested in getting an unbiased
opinion; the question is loaded with non–neutral wording.
Sensitivity (condition of being sensitive): The wording in a question may unduly
influence responses. In the following questions, it is clear that political sensitivity can
influence the results!
Table 1: Political sensitivity
‗Do you think the US was right or wrong in sending Wrong 36%
American troops to stop the Communist Invasion of Right 55%
South Korea?‘ (Opinion Research Centre, January 1951) Don‘t Know 9%
‗Do you think the US made a mistake in deciding to Mistake 49%
defend Korea, or not?‘ (Gallup, January 1951) Not a Mistake 38%
Don‘t Know 13%
Plasticity: Plasticity is the degree to which questions may be affected by the context
and by previous questions asked. Many questions will be answered very differently by
the same person according to the context of the questions, including where they are
placed amongst other questions.
Table 2: Schuman and Presser‘s questions
Order Question Result 1 Result 2
A Do you think a Communist country like 82% Yes 64% Yes
Russia should let American newspaper
reporters come in and send back to
America the news as they see it?
B Do you think the United States should let 75% Yes 55% Yes
Communist newspaper reporters from
other countries come in and send back to
their papers the news as they see it?
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 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.

Gathering Data to Identify Business Requirements Page | 5

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. Examples:
 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.
 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 member‘s only section.
 The database must retain customer details.
Non–Functional Requirements
Whitten et. al. also define 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 Requirements report.
Table 3: Non–functional requirements can be classified by their requirement type as in the
following table
Requirement type Explanation
Performance Performance requirements represent the performance the system is
required to exhibit to meet the needs of users.
What is the maximum download time for web pages?
What is the acceptable throughput rate?
What is the required response time?
Information Information requirements represent the information that is pertinent to the
users in terms of content, timeliness, accuracy and format.
What are the necessary inputs and outputs? When must they happen?
Where is the required data to be stored?
How current must the information be?

Gathering Data to Identify Business Requirements Page | 6

 What are the interfaces to the external systems?
Economy Economy requirements represent the need for the system to reduce costs
or increase profits.
What are the areas of the system where costs may be reduced?
How much cost should be reduced or profits should be increased?
What are the budgetary limits?
What is the timetable for development?
Control (and Control requirements represent the environment in which the system must
Security) operate, as well as the type and degree of security that must be provided.
Must access to the system or information be controlled?
What are the privacy requirements?
Does the criticality of the data necessitate the need for special handling
(backups, off–site storage, etc) of the data?
Efficiency Efficiency requirements represent the system‘s ability to produce outputs
with minimal waste.
Are there duplicate steps in the process that must be eliminated?
Are there ways to reduce waste in the way the system uses its resources?
Service Service requirements represent needs in order for the system to be
reliable, flexible and expandable.
Who will use the system and where are they located?
Will there be different types of users?
What are the appropriate human factors?
What training devices and training materials are to be included in the
system?
What training devices and training materials are to be developed and
maintained separately from the system, such as stand–alone computer–
based training (CBT) programs or databases?
What are the reliability/availability requirements?
How should the system be packaged and distributed?
What documentation is required?
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.

Gathering Data to Identify Business Requirements Page | 7

Self Check LO2 Written Test

Name: _______________________________ Date: _________________

Instruction: Answer all the questions listed below, if you have some clarifications- feel
free to ask your teacher.
1. In your own words define the terms: bias, sensitivity and plasticity.
2. What is the difference between open and closed questions? Give example for each
question types.
3. Discuss the types of questions that you should develop and use to elicit relevant
and required information that enables you to understand a problem or
requirement from the respondent's point of view.
Answer the Letters:
4. Bloom’s Taxonomy includes which of the following levels:
A. evaluation, synthesis, application, knowledge, comprehension, conception
B. evaluation, fusion, application, knowledge, comprehension, conception
C. assessment, synthesis, application, knowledge, conception, understanding,
thought
D. evaluation, synthesis, analysis, application, comprehension, knowledge
5. Problem statements usually do NOT include which of the following key words?
A. Cannot B. will not C. would like D. all of the above
6. 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
7. 4. What type of question is this: ‚Tell me about your holiday?‛
A. Open B. Closed C. Neither
8. Non–functional requirements are often associated with:
A. Technical requirement B. Business requirement
C. Functional requirement

Gathering Data to Identify Business Requirements Page | 8

LO3 Ensure Analysis is Accurate and Complete
3.1. Overview
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.
Analyse Responses: 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.
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.
Example: In this example, the survey data from Opinion Research Centre and Gallup has been
classified and collated in an attempt to better represent the opinions of US citizens.
Table 1: Political sensitivity
‗Do you think the US was right or wrong in sending American Wrong 36%
troops to stop the Communist Invasion of South Korea?‘ Right 55%
(Opinion Research Centre, January 1951) Don‘t Know 9%
‗Do you think the US made a mistake in deciding to defend Mistake 49%
Korea, or not?‘ (Gallup, January 1951) Not a Mistake 38%
Don‘t Know 13%
The figures presented are the average of the two surveys.

Generally, 42.5% of the population believe that it was wrong

or a mistake to defend Korea. 46.5% of the population believe
it was right or not a mistake to defend Korea. And 11% of the
population did not know if it was right or wrong to defend
Korea.
The results can be supported with a pie chart.

Gathering Data to Identify Business Requirements Page | 9

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. Is each of the
requirements below equal in importance?
The system must
 conduct transactions over the Internet  display customer satisfaction
 display products on screen testimonies
 provide an animation of the production  provide a user's guide for products
process  capture customer details online
 display a privacy policy  have password protection for a
 link Internet sales to the inventory "members only" section
system  display correct pricing - especially for
 display a returns policy customers with discounts
 enable a "contact us" facility  describe products
 enable customers to check delivery and
production status
 provide "about us" information
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.
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

Gathering Data to Identify Business Requirements Page | 10

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.

Self Check LO3 Written Test

Name: _______________________________ Date: _________________

Instruction: Answer all the questions listed below, if you have some clarifications- feel
free to ask your teacher.

1. A workshop typically involves data collation and analysis after the workshop has
been completed. (True/False)
2. What is the output from the first stage of analysis?
A. a list of business requirements C. an opportunity or problem statement
B. a list of key stakeholders 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 C. mandatory functional requirements
B. desirable functional requirements D. All of the above.
Answer Question:
4. List and discuss the four stages analysis of data.

Gathering Data to Identify Business Requirements Page | 2

LO4: Submit Analysis and Gain Agreement
4.1. Overview
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
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 Requirements Report
There are many templates available for writing a Requirements Report. The following headings
may be used in a Requirements Report:
 Introduction  Information domain
 System description  Project costs
 Functional requirements  Benefits
 Non-functional requirements  Other project specific topics
Table 1: The table below summarises what each heading contains.
Requirements definition report elements
Introduction Purpose, Scope, Definitions and 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.
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.

Gathering Data to Identify Business Requirements Page | 2

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 Statechart diagrams are common techniques used
to describe the system‘s functions.
Storyboards
A common technique for providing functional information for websites to the client is to
provide a storyboard. Storyboards are a visual representation of what a website interface is
supposed to look like. They can consist of a site map and a detailed representation of some or
all of the pages in the site.
Here is an example of a site map:

Figure 1: Sample site map

Here is an example of a mock up of a website page:

Figure 2: Sample mock up of a website page

Gathering Data to Identify Business Requirements Page | 2

Storyboards are most appropriate for use with website design.
Non-Functional Requirements
Non-functional requirements define any constraints within which the current system
operates. Examples of this include database size, response times and web page download times.
Information Domain
Information domain defines the data requirements of the system. ER diagrams, Class
diagrams and Data Dictionaries are common techniques used to describe a system‘s data. For
websites, the storyboard information should be expanded to show what information (web
pages) will be included.
Project Costs
Project costs define estimated costs of the project in terms of development and running costs.
Benefits
Benefits define the areas that the new system will improve. This includes benefits measurable
in dollars (tangible benefits), and those that cannot be measured in dollars (intangible benefits)
but are important nonetheless.
Other project specific topics
Other project specific topics define any other topics that may have an impact on the project.
These may include such things as methodology, legal implications or employee acceptance etc.

Gathering Data to Identify Business Requirements Page | 3

Self Check LO4 Written Test

Name: _______________________________ Date: _________________

Instruction: Answer all the questions listed below, if you have some clarifications- feel
free to ask your teacher.

1. What is the purpose of the Requirements Report?

A. to communicate the requirements D. all of the above
B. to confirm the requirements E. none of the above
C. to gain agreement from the client
2. Non-functional requirements define any constraints within which the current
system operates. (True/False)
3. The functional requirements define the services that the system provides.
(True/False)
4. What is considered a common technique used to describe the system’s functions?
A. case diagrams D. all of the above
B. data flow diagrams E. none of the above
C. statechart diagrams
5. Benefits that are measurable in dollars are known as tangible benefits. (True/False)

Gathering Data to Identify Business Requirements Page | 4