4 REQUIREMENTS DEFINITION
REQUIREMENTS DEFINITION ....................................................................................................................... 2
Requirements Catalogue ....................................................................................................................... 2
Finding the System Requirements ......................................................................................................... 5
Types of Requirement ............................................................................................................................ 6
Requirements Definition Through the Salon Case Study ...................................................................... 6
Relationship of Requirements Definition to Other Techniques ........................................................... 10
The Place of Requirements Definition in the System Development Template ..................................... 11
Afterthought: Data Oriented Functional Requirements...................................................................... 11
Afterthought: Requirements Should Hinge on Objectives................................................................... 11
Afterthought: Influencing Requirements ............................................................................................. 12
Section References .............................................................................................................................. 13
Requirements Definition Exercises ..................................................................................................... 13
6 March, 2016
Short Courses
4 Requirements Definition
...a fleeting episode, a fragment of
landscape or a remark overheard may
provide the only means of understanding
and interpreting areas which would
otherwise remain barren of meaning.
C. Levi-Strauss, Tristes Tropiques
Requirements Definition
Requirements Definition is probably the most important technique in Structured Analysis.
It is the only technique that permeates every step of the method. It also is one of the least
pictorial, making it difficult to describe precisely. In essence, the technique involves
capturing what the users really want and making sure that every subsequent project
activity leads to the best possible transformation of those user needs into system needs
which, when satisfied, will deliver what the users wanted in the first place.
Within a structured development the technique of Requirements Definition passes
through two phases. Initially, the user requirements are identified. This is done while the
main investigation is in progress. As the requirements are identified, two models of the
system are built. The first represents the processing necessary to meet those requirements,
and the second portrays the underlying structure of the data that is needed to support this
processing. For each of these models the distinct techniques of Data Flow Modelling and
Logical Data Modelling are prescribed.
To identify the requirements the systems analyst has to resort to traditional 'factfinding' procedures, such as interviewing, use of questionnaires, collecting of documents,
running workshops, work shadowing, and observation.
As the project progresses, the requirements identified while performing the
Feasibility Study and the Requirements Analysis start taking a clear shape which can be
worked upon. A requirement is well defined only when the Data Flow Model and the
Logical Data Model explain the processing and data support necessitated by that
requirement. The Requirements Analysis module effectively comes to an end when the
requirements that will be satisfied by the new system are chosen and signed off by the
Project Board.
In the second phase, the technique makes sure that every subsequent product can
be traced back to a specific user requirement and that all user requirements are dealt with.
In this manner, the technique becomes the litmus test through which the success of the
project will be judged.
Requirements Catalogue
The main product of Requirements Definition is the Requirements Catalogue which acts
as a repository where everything the user wants from the future database system is logged.
The Requirements Catalogue consists of separate entries such as the one depicted in
figure 4.1. Each entry contains details which help identify the requirement, a description,
relevant comments, and a reference to other analysis and design products which are a
4 Requirements Definition
2
response to the requirement. When complete, the Requirements Catalogue contains all the
requirements identified by the team of a particular project.
The Requirements Catalogue Entry suggested here is filled-in in the following
way:
 Project The name or id of the project or system for which this is a requirement
 Author The name or id of the team member who fills-in the particular requirement
 Date
 Version It is good practise to be able to keep track of entries which are a rephrasing or
an update of earlier requirements
 Page of
 Source This is the first entry for the requirement which is of some substance. It
contains the name of the person or the document through which the requirement was
identified. The document may be an existing document of the business or organisation
or a document created by the team while identifying requirements. Examples of the
latter are 'interview 3 notes with DJ', 'observation by NL at 05/07/94' etc
 Priority An estimate of the importance of a requirement which depends on some
scale accepted by the team. Examples include numeric scales from, say, 1 to 5, or
descriptive scales such as L for Low, M for Medium and H for High. Whatever the
scale, it should be understood by both the team and the users. While difficult to
predetermine in most cases, priority settings placed here may influence whether a
requirement goes on to be designed for or is dropped later on. It should be clear from
the onset of a project who is responsible for assigning priorities
 Owner The person or group who is responsible for deciding what will happen to a
requirement.
 Functional requirement There are two types of requirement. Functional and nonfunctional. Functional requirements are the requirements that are essential for the
running of the system. Those include updates, enquiries, major reports etc. As they
are identified by the team they are logged in on the catalogue. The description of the
requirement is usually in the user's words. As the project proceeds, some
requirements may be found to be in conflict. In this case the owners of these
requirements are responsible for negotiating which requirement will remain.
 Non-functional requirements Non-functional requirements involve issues such as
acceptable service levels, response times, access restrictions, security issues, back-up
considerations, audit and control requirements, general constraints etc. Usually a
functional requirement will contain a few non-functional requirements, but there
could be certain non-functional requirements that apply to the whole system and so
have no specific functional requirement associated with them. Each non-functional
requirement consists of a brief description, a target value, an acceptable range, and
any comments that may be necessary. Target values usually involve times when the
requirement is expected to be available and/or expected response times. The
acceptable range then includes a relaxation of the target value which the users will
tolerate.
Target values are best dealt with in groups to avoid repetition in every entry.
 Benefits A requirement has to be traceable back to some business objective. Its benefit
to the system should thus be measurable in some way. Benefits are usually a mix of
4 Requirements Definition
3
tangible and intangible benefits. A requirement becomes useful
measure
when
a clear
Requirements Catalogue Entry
Project
Author
Date
Source
Priority
Functional Requirement
Version
Owner
Page of
Requirement ID
Business Event:
Description
Non-functional requirements
Target value
Acceptable range
Comments
Benefits
Comments/suggested solutions
Related Documents
Related requirements
Resolution
Figure 4.1 A blank Requirements Catalogue Entry suggestion which closely follows the
recommendation in the SSADM v4 manual. A project team should decide early on on the shape of the
4 Requirements Definition
4
form to be used. As the number of requirements grows, a grouping mechanism to group together
requirements affecting the same functional area of the new system is advisable.




of its benefits can be stated. The entry here requires a statement, in plain English, of
the perceived benefits of satisfying the requirement. Inevitably, some consistency
between the benefits and the priority should exist if the entry is to be in any way
meaningful.
Comments/suggested solutions An informal section to jot ideas that may be useful
later on.
Related documents As the project proceeds, analysis and design products are
developed. Each one of these should justify its existence by managing to pinpoint the
actual (user) requirements it caters for. In order to facilitate cross referencing, relevant
new products should be jotted down here. Initially, original business documents may
be mentioned, specifically if they are also connected with the source of the
requirement.
Related requirements Requirements can usually be grouped together because they
relate to the same functional area. A study of all related requirements clarifies them
and helps avoid conflicts.
Resolution It is important to log what happens to a requirement. With reference to
related documents, this section of the form will have to be filled in by the end of the
project. If a requirement is dropped later on, the reasons for doing so have to be stated
here.
Finding the System Requirements
The identification of system requirements is not straightforward. In fact, it is not always
easy to even identify who the user is, who’s views carry more weight, and who’s make
any computing sense. This is why a good Project Initiation Document should be present,
laying out clearly the objectives of the system to be developed.
The analyst acts as an intermediary trying to understand the way the business or
organisation runs. This understanding is modelled and then successively transformed and
refined until it becomes a set of unambiguous programming specifications with which
programmers can deal without having to resort back to the user. If the transformations are
successful, every end product will be traceable to a requirement which itself will be there
to support a specific business activity. We therefore need first to model the activities
taking place, isolate those that are data oriented and then attach a requirement, with the
users’ consent, to them. This requirement will, by definition, be a computer related
requirement and we will use the DFD to associate a computing process with it. This way
of building the system ensures the users never lose touch with what we are doing, since
now any suggestion of a computer process is traced, via the relevant requirement, to the
activity which it supports.
Since there is a link between a requirement, a computing process and the data that
supports the process, we can utilise our Data Flow Model and our Logical Data Model to
identify requirements. This is possible because the DFM and the LDM have the ability to
help us see things that mere fact finding simply cannot. So, while the DFM represents
data oriented processes that are ‘required’ by the user, many times we identify a
requirement by first discovering a process need through the DFM. For this reason there is
no clear sequence which dictates that requirements are first identified, then the DFM is
4 Requirements Definition
5
set up to represent them and then the LDM which supports the DFM is drawn up. On the
contrary, the three techniques of Requirements Definition, DFM and LDM are done
simultaneously and dynamically feed into each other. Realising this is fundamental and
shows why Requirements Definition is a black art and why DFM and LDM are also
powerful investigation tools.
In a structured systems development we therefore expect the steps of Investigating
and Defining Requirements, Investigating Current Processing, and Investigating Current
Data to simultaneously follow the first step of Establishing the Analysis Framework.
Types of Requirement
While identifying requirements, three types should emerge. Firstly we have those
requirements that simply retain the current environment’s functionality by reproducing
what is already done in the business. These requirements may carry with them a promise
of better working conditions but the analyst should be conscious of not providing
anything new to the business. Statements like “with the new system you will be able to
take appointments more efficiently” mean nothing to a business which simply opens a big
diary and places a customer’s name against a day and time. Caution should also be
exercised to avoid words such as “efficiently” because a good requirements entry should
also explain how this efficiency will be measured. The Business Activity Model is a good
vehicle through which to first identify this type of requirement.
The second type of requirement is one where the same information as currently
will be collected, but this time due to computerisation new opportunities arise in
searching through it. This type of requirement is essentially for an enquiry of sorts. For
example, at the press of a button all the salon’s red headed customers can be identified
for, say, marketing purposes. This type of requirement is what makes the system an
information system. The imagination of the users and the analysts are a good source for
these requirements. If the users also understand the potential of the LDM then the ideas
this model can generate are sometimes spectacular.
The third type of requirement is one which introduces new activities to the
business and really changes work conditions. This type is more difficult to identify and
may lead to conflicts because of the changes it introduces. Sometimes these requirements
are a request to be able to do what a competitor does, or to open up a new area of
business, or to introduce new administration tasks in order to monitor things. These
activities represent new opportunities for a business and should be treated with much
more care. The logicalisation of the Data Flow Model may help here, but Impact Analysis
and Risk Analysis are called for. This third type is what makes the systems analyst’s job
more challenging and more exciting.
Requirements Definition Through the Salon Case Study
The Salon's requirements would normally be picked up through meeting the people who
work in it. The main person would clearly be the proprietor of the business who is the
ultimate owner of each requirement.
In the Salon's case no formal interviews were arranged. Instead, informal
discusions with the proprietor, a receptionist, and a volunteer stylist were used to clarify
points that were picked up by observing the business in operation.
4 Requirements Definition
6
The circumstances of the business were such that the most important discusions
where those with the proprietor, Ms S. Todd, since she was the person who knew the
business inside-out. This was because she had been responsible, at one time or another,
for recruiting staff, ordering stock, deciding on and pricing the services to be provided by
the salon, advertising, taking appointments, and, having trained as a hair stylist herself in
her salad years, physically completing appointments.
The ‘interviews’ with the other members of staff were mainly to make sure that
the details of each person's job were accurately reflected in the system to be designed. No
conflicts of interest were observed.
The objectives of the business were clear from the onset. S. Todd was an
expanding business whose aim was to set up a chain of high profile salons across London.
There were currently two salons in the chain and the administration of both of them had
become a bit cumbersome for the proprietor. In order for the administration costs not to
swamp the real business of the Salon, it seemed that the efficiency provided by
computerisation should be investigated.
While the ‘interviews’ constituted the most formal method for pinpointing the
user's business requirements, the most important information gathering was done through
straight forward observation of the Salon in operation. This entailed simply ‘sitting at a
corner’ of the shop and observing appointments being taken, completed and paid for,
picking up a price list, looking at the manner orders were made and deliveries accepted,
seeing the interactions between managers, staff and managers, customers and staff,
trainees at work etc. Visits to other salons, sometimes masquerading as a customer, were
also very fruitful in this case. Inevitably, the language used within the salon was more
familiar to the female members of the analysis team who played an important part in
explaining the niceties of life in a hairdresser's salon to their male counterparts.
A brief search through the competition suggested that computerisation of the
business procedures was not only viable but imperative. For reasons not entirely clear, an
‘off the shelf’ system was not considered by the proprietor.
It quickly became apparent that there seem to be three subsystems which coexist
inside the Salon. These are a) an Appointments system which is the main business of the
Salon that is visible to its customers, b) a Personnel system which ensures the recruitment
of staff and trainees to perform the salon’s business, and c) a Stock system which ensures
there are sufficient products to use when attending to customer hair and beauty needs. All
three are also responsible for keeping financial records which are made available to the
accountants who visit the premises every third month to ‘keep the books’ and deal with
the VAT.
These three sub-systems are reflected, through the organisation chart, on the
Salon's DFD. It was thus decided fairly early in the project to group the requirements in a
way that would reflect these organisational divisions. It was felt that this would facilitate
the Project Board's decision making later on.
With the help of the Business Activity Model, the following requirements were
identified:
4 Requirements Definition
7
APPOINTMENTS REQUIREMENTS
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
Produce a personal report for customers, containing their treatment history
Produce a report of daily takings
Set up an appointment for a customer
Keep customer records
Keep a record of all the skills attained by trainees during their apprenticeship with
the salon
Arrange for (immediate) payment of appointments
Keep a record of stock usage (for statistical and financial purposes)
Hold a record of allergies and product reactions
Produce a report to show the income generated per employee
Add new treatments to the range of facilities provided by the salon
Warn about employee unavailability and stock shortcomings for imminent
appointments
Sell products through the salon
PERSONNEL REQUIREMENTS
E1.
E2.
E3.
E4.
E5.
Keep updated employee files
Keep record of salary scales
Keep training record of trainees
Arrange for payment of weekly salaries
Produce a weekly employee availability list
STOCK REQUIREMENTS
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
Provide a list of stock in hand
Reconcile supplier invoices with deliveries
Reconcile deliveries with orders
Register purchase orders
Keep a record of inter salon transfers for internal accounts
Keep a record of suppliers and the products they supply
Record invoice payments
Warn about outstanding invoices
Produce a 'year end' invoice report for accounts
Keep a record of all salons in the chain to include name, address etc. for transfer
purposes
The above requirement summaries are very useful as a quick reference to the whole salon
system. They of course lack sufficient detail to be totally unambiguous. A full
Requirements Catalogue Entry is usually necessary to expand on the requirement and
give enough information to trace its origins lest it is still not clear. A complete example is
shown in figure 4.2.
4 Requirements Definition
8
Requirements Catalogue Entry
Project S.Todd
Author NL
Date 7.7.94
Version 1
Page 1 of 1
Source Interview 2 with ST
Priority H
Owner ST
Requirement ID A6
Functional Requirement
Arrange for (immediate) payment of appointments:
Appointments should be paid for upon completion of the appointment. It is important for the stylist
responsible for the appointment to inform reception of all the treatments provided before the customer
leaves the premises. A full list of all the services arranged for during the setting up of the appointment,
plus any services that were provided at the stylist’s suggestion without pre-arrangement should be
available for charging purposes. The method of payment should be recorded and a bill provided for the
customer. A record of the transaction should be kept for tax purposes.
Business Event: Appointment Completed
Non-functional requirements
Description
Target value
Acceptable range
Input services provided immediately through
4 seconds per service
keyboard
print bill
5-10 secs
Comments
under 20 secs
Benefits
No time will be lost calculating the value of each service. A record for tax purposes will reduce
accounting fees considerably. Customers will have a complete breakdown of the treatment they pay for.
Comments/suggested solutions
The LDS will contain entities to trace and charge for all Jobs making up an Appointment.
A direct link to a printer is necessary
Related Documents
Interview and observation notes. Identified through BAM. LDS entities Appointment, Job, Treatment,
Skill, and Treatment Skill. DFD processes 5.1 and 5.2.
Related requirements
A1, and to a lesser extent A3 & A4
Resolution
Accepted by BSO and TSO. Implemented. Function Id:__
Figure 4.2 An example Requirement Catalogue Entry following closely the default recommendation
4 Requirements Definition
9
Relationship of Requirements Definition to Other Techniques
BAM
DFM
LDM
BSO
DD
RD
P
TSO
RDA
FD
PDD
CBM
EBM
LDPD
PPS
The BAM is a good source of User Requirements that retain the business’ current
functionality.
During investigation the DFMs and the LDM are set-up at the same time as the
Requirements Catalogue is produced.
The necessity for an enquiry function need not be shown on the DFM, in which
case the Requirements Catalogue is the only place where it is logged.
The bottom half of the Requirements Catalogue entries is continuously updated to
show the progress of a requirement through the system’s development.
Prototyping and Dialogue Design are influenced by entries, functional or nonfunctional, in the Requirements Catalogue. (If Prototyping is used for investigation it may
become a source of requirements.)
BSOs are based on User Requirements, and can lead to dropping a requirement
altogether.
The TSO has to be chosen to accommodate all requirements, including the nonfunctional.
The two techniques of Physical Design are highly influenced by target values
stated in the Requirements Catalogue.
4 Requirements Definition
10
The Place of Requirements Definition in the System Development Template
The Requirements Catalogue permeates the system’s development. Every product
justifies its inclusion by tracing back to a requirement.
D
e
c
i
s
i
o
n
Investigation
Specification
Conceptual model
S
t
r
u
c
t
u
r
e
U
s
e
r
RD
Internal design
Construction
External design
O
r
g
a
n
i
s
a
s
i
o
n
P
o
l
i
c
i
e
s
a
n
d
P
r
o
c
e
d
u
r
e
s
Afterthought: Data Oriented Functional Requirements
Since the aim of analysis is to identify a computer process that will satisfy a given user
requirement, and since an information system computer process is essentially an
interchange of specific data items, it soon becomes evident that user requirements have to
be expressed in a data oriented sense. Thus the analyst has to intuitively interpret a user
requirement into a form that is computable. Only then can resolutions of the requirement
be meaningful. If the requirement is not dropped by the BSO, then computer function(s)
will be attached to it. These functions will form the basis for the subsequent programming
specifications. It will then be possible to pick-up any programming section and crossreference it back through the function to the requirement for which it was created in the
first place. Documentation becomes complete and meaningful only when this
backtracking from chunks of code to the original requirement is possible.
Non specific requirements such as ‘computerise appointments’ are too vague and
need refinement. In the Salon's case, this refinement has led to requirements A1-A11,
each of which is data specific. Others, such as ‘allow for business expansion’ have to be
seen as non-functional requirements which will have practical usefulness only when
clear-cut measures of the perceived expansion can be pin-pointed.
Afterthought: Requirements Should Hinge on Objectives
All project products hinge on requirements. If a system analysis product cannot be linked
with a user requirement, then that product should not have been produced. This statement
has different repercussions depending on what stage of the development we are in. During
4 Requirements Definition
11
Requirement Analysis, the identification of requirements is done simultaneously with the
building of the process and data models. If a process which does not appear to have been
required is stumbled upon during Data Flow Modelling, then the analyst should enquire
whether the requirement has been missed by the team. In this manner the Data Flow
Model strengthens the analysts’ understanding of the problem by identifying a user
requirement to which the process is duly attached. On the other hand, by the time we
come to Requirements Specification the user requirements have been determined by the
Project Board during BSOs. To continue adding new requirements now defeats the rigour
required by Analysis and is contrary to the notion of ‘hard’ waterfall methods. Discipline
is then needed to identify the functions, and only the functions, that address the
requirements. Any function that cannot trace back to a chosen requirement should be
treated with caution because it either means it should not be there or that the Analysis was
slipshod.
Since every development product justifies its inclusion by pointing to the
requirement to which it is a response, one may wonder what justifies the inclusion of a
requirement in the Requirements Catalogue. The answer to this question is subtle: each
requirement has to hinge on a business objective. These business objectives should be
part of any decent Project Initiation Document. In short, an analyst should continuously
strive to comprehend why a system’s objectives exist, what is their role and what their
purpose. Answers to those questions help determine the, usually not so clear cut, system
boundary and so add to the analysts’ appreciation of the user requirements.
The astute reader will have recognised that statements such as ‘computerise
appointments’ and ‘allow for business expansion’ are more akin to objectives than
requirements.
Afterthought: Influencing Requirements
The job of the analyst is to identify computer requirements for the user with the help of
the user. When working within a waterfall framework, certain assumptions are implicit.
For instance, not much conflict of interest exists, the system to be built is somehow clearcut, a project board which represents the user community has been set up and is
empowered to take decisions, and all involved have the success of the future computer
system at heart. When these conditions are met, our job is to tease out the requirements
and phrase them in a manner that our technical knowledge suggests will prove
constructive. Analysts are not supposed to massage requirements to fit with their own
points of view. Instead they should act as facilitators to the users’ request for a computer
information system.
4 Requirements Definition
12
Your reaction to the last statement above betrays your opinion on how much, if at all, the
analyst should influence requirements. If you had no reaction you are probably an
inexperienced analyst.
The answer you give to the question of whether analysts should be detached
observers of the development or whether they should actively participate in it will define
the kind of analyst you aspire to be. You may consider that your job resembles that of an
engineer. Alternatively you may consider yourself a facilitator or even an emancipator
[Dahlbom and Mathiassen, 1993]. As an engineer you will be “primarily interested in
technology” and you will feel that your task is to “construct the optimal technical solution
to be delivered to your client in response to given requirements”. As a facilitator you will
try and understand more about the environment in which your system will reside. You
will “engage in a dialogue with clients” and probably “take an experimental, evolutionary
approach to develop satisfactory computer solutions”. As an emancipator you may go
further, become more critical and view systems as a vehicle for power. You will then try
to involve yourself “directly in the problematic situation of the client, intervening to
change the existing power structures and to create a more equal distribution of resources
and opportunities”. The choice is yours - maybe.
Section References
Dahlbom, B. and Mathiassen, L. (1993) Computers in Context, the Philosophy and
Practice of Systems Design, NCC Blackwell
Requirements Definition Exercises
1) Study the Business Activity Model and the Requirements of the Salon. Decide which
requirements simply retain what is already going on in the salon, which represent
better use of existing information and which represent actions not currently offered by
the salon.
4 Requirements Definition
13