Types of Requirements  Functional Requirements

Types of Requirements
 Functional Requirements
 Descriptions of actions or processes that create or update
information.
 Outlines of reports or on-line queries. These can be user
requested or automatically generated by the system at scheduled
times, or when specified events occur.
 Details of business data to be held and used within the system.
 Non-functional Requirements








Required service levels
Volumes
Transition arrangements
Technical constraints
Usability
Required interfaces with other systems
Security and Access requirements
Project constraints, e.g. system delivery date, cost limits,
company policies
Requirements Catalogue
 A priority for the requirement, such as essential to the
operation of the system or business (E), desirable as it
will deliver significant business benefit (D) or nice to have
(N), i.e. “luxury” features
 Suggested solutions
 The source of the requirement
 The owner or user responsible for agreeing and signing
off the requirement
 Associated non-functional considerations
 Benefits
 Related project documents or products
 Related functional requirements
 Resolution
Requirements Catalogue
Requirements Catalogue
Requirement Id.
Requirement
Name
Description
Priority
Source
Owner
Non-Functional
Considerations
Comments/Sugge
sted Solutions
Benefits
Related
Documents
Related
Requirements
Resolution
114
Overdue Delivery report
Report providing details of overdue deliveries,
including the date the delivery was originally due
on, number of days late, supplier number and name,
purchase order number.
Desirable.
Delivery scheduling workshop – Stock Clerk (M
Patel).
Warehouse Manager – M Portillo.
Required on-line from 8.00 until
Saturday.
Response time should be under 10
required up to 20 times per day,
situation.
Should be provided as an on-line
option to print hard copy.
18.00, Monday to
seconds as
giving the latest
report, with an
Will enable chasing up of late deliveries
monitoring of supplier promptness and help. Target
30% reduction in outstanding late deliveries. This
should reduce incidents where customer orders
cannot be satisfied due to late delivery of stock
from the supplier. Estimated additional sales of
0.1%.
Interview notes No. 3, including suggested layout.
Delivery scheduling workshop notes.
No. 115 Re-schedule delivery.
No. 136 Delivery Details Report - will need to be
able to access these details in order to establish
what items are overdue.
Requirements Summary
Requirements Summary
Id
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
Name
System must support up to 100,000 live products
Record proposed purchase order
Confirm purchase order
Record customer order
Arrange despatch of customer orders
Customer orders to be kept 3 months then archived
Provide delivery to despatch audit trail
Provide supplier performance monitoring facility
Record delivery data including rejections
Schedule deliveries (to nearest half hour)
Overdue delivery report
Re-schedule delivery
Make use of existing PCs in stock office
Delivery due dates to be converted to DD/MM/YYYY
Facilitate alternative product selection
Report on stocks nearing withdrawn from sale date
Provide possible stock-out warnings
Monitor supplier invoices
Produce stock report
Priority
E
E
E
E
E
E
D
D
E
E
D
E
D
E
E
D
N
D
D
Owner
AS
FB
FB
JK
FB
JK
MP
MP
MP
MP
MP
MP
HS
HS
JK
FB
FB
AS
FB
Identifying and Developing Requirements
 Traditional Fact Finding:






Interviews.
Workshops.
Examination of Business Documentation.
Questionnaires.
Observation of Operations.
Brainstorming Sessions.
 Project Sources:





Project input documents.
Previous or related studies.
Current system problem and change logs.
Business Activity Modelling.
Prototyping.
General fact-finding are outside the scope of this module, but
are documented well elsewhere, e.g. Yeates, Shields and
Helmy (1994), Chaffey (1999).
Current Systems
 While the emphasis of Requirements Definition must
always be on the new system, the requirements most
readily highlighted by users often relate to solving
problems associated with the current system support,
such as:





Restrictive operations.
Poor system quality.
Lack of system availability.
Inadequate or complex user interfaces.
Lack of capacity.
Developing Requirements - Tips
 Where requirements are generated from current problems
we must ensure that the future requirement is properly
recorded. For example, if a current issue is that an
enquiry takes 30 seconds, we need to record the required
response time, rather than stating that 30 seconds is too
long.
 In areas where satisfactory support is already provided
by an existing system we will still need to document
requirements.
 We must always attempt to explore the validity of a requirement
with users before recording it formally in the catalogue. We
should also attempt to identify duplicate requirements before
documenting them.
 Despite the danger of wasted effort, our policy should always be
one of “if in doubt, record it”.
 Our aim should be to capture a picture of requirements
that is as accurate and complete as possible.
 The precise number of catalogue entries generated is largely a
matter of individual judgement and style (and an organisation’s
internal standards).