See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/242397310

Requirements Engineering Questionnaire

Method · January 2001

CITATIONS READS
8 4,797

2 authors, including:

Massimo Felici
Deloitte Consulting & Advisory
93 PUBLICATIONS   486 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cloud Accountability Project (A4CLOUD) View project

Interdisciplinary Research Collaboration in Dependability (DIRC) View project

All content following this page was uploaded by Massimo Felici on 07 January 2016.

The user has requested enhancement of the downloaded file.

Requirements Engineering
Questionnaire

Version 1.0

Stuart Anderson Massimo Felici

Laboratory for Foundations of Computer Science

Division of Informatics
The University of Edinburgh
James Clerk Maxwell Building
The King’s Buildings
Mayfield Road
Edinburgh EH9 3JZ
Scotland, UK

1


c January 2001 by Stuart Anderson and Massimo Felici

Neither the authors nor The University of Edinburgh accept any responsibility or liability for loss of
damage occasioned to any person or property through using the material, instructions, methods or ideas
contained herein, or acting or refraining from acting as a result of such use. The authors and The
University of Edinburgh expressly disclaim all implied warranties, including merchantability or fitness
for any particular purpose. There will be no duty on the authors or University to correct any errors or
defects in the software.

This document may be used, modified or copied for internal use, provided this copyright is acknowledged.
It may not be sold, or used for commercial gain or other purposes without prior written permission.

Corresponding author:

Massimo Felici

Laboratory for Foundations of Computer Science

Division of Informatics
The University of Edinburgh
James Clerk Maxwell Building
The King’s Buildings
Mayfield Road
Edinburgh EH9 3JZ
Scotland, UK

tel. +44-131-6505899
fax. +44-131-6677209
e-mail. [email protected]

2
1 Preface
How to fill in the questionnaire. Answer all the questions according to your knowledge, skills and
position within your organisation. The questionnaire aims to check up the requirements engineering
practice within your organisation pointing out different viewpoints.
Each question has a multiple-choices answer (tick one of the choices). The lecture-key of the answers is
as follows:

N/A: Not Applicable, if the question does not fit your organisation

UN: Unknown, if you can not answer the question according to your knowledge, skills or position within
your organisation

The other answers consist of five different levels, namely, VL (Very Low), L (Low), A Average, H (High)
and VH (Very High). If you think that the question fits your knowledge, skills or organisation answer the
relative question with one of the above levels selecting that one, which represents most your knowledge,
skills or organisation.

Remark. This questionnaire is NOT to assess people and their work or knowledge. The questionnaire
aims only to assess the requirements engineering practice within organisations.

Acknowledgements. The main references of this questionnaire are [1, 2, 3, 4].

General Information
Fill in the following table with the relative information.

General Information
Name (optional)

Position

Date

3
2 Business Requirements Engineering
Requirements Methodology Compliance
Question N/A UN VL L A H VH
2.1 Have the applicable organisation’s policies and
procedures been identified?
2.2 Do requirements comply with these policies and
procedures?
2.3 Do you document requirements in accordance
with the requirements methodology?
2.4 Is the cost/benefit analysis prepared in accor-
dance with the appropriate procedures?
2.5 Does the requirements phase meet the intent of
the requirements methodology?
2.6 Is the requirements phase staffed according to
procedures?
2.7 Will all the applicable policies, procedures and
requirements be in effect at the time the system goes
in operation?
2.8 Will there be new standards, policies and pro-
cedures in effect at the time the system goes opera-
tional?

Business Tolerance Requirements

Question N/A UN VL L A H VH
2.9 Have the significant financial fields been iden-
tified?
2.10 Has responsibility for the accuracy and com-
pleteness of each financial field been assigned?
2.11 Have the accuracy and completeness risks
been identified?
2.12 Has the individual responsible for each field
stated the required precision for financial accuracy?
2.13 Has the accounting cutoff method been deter-
mined?
2.14 Has a procedure been specified to monitor the
accuracy of financial information?
2.15 Are rules established on handling inaccurate
and incomplete data?

4
 Business Performance Requirements
Question N/A UN VL L A H VH
2.16 Will hardware and software be obtained
through competitive bidding?
2.17 Have cost-effectiveness criteria been defined?
2.18 Do you calculate the cost-effectiveness for an
application system in accordance with the proce-
dures?
2.19 Are the cost-effectiveness procedures applica-
ble to any application?
2.20 Could application characteristics cause the ac-
tual cost to vary significantly from the projections?
2.21 Are there application characteristics that
could cause the benefits to vary significantly from
the projected benefits?
2.22 Is the expected life of projects reasonable?
2.23 Does a design phase schedule exist which iden-
tifies tasks, people, budgets and costs?
2.24 Have you obtained quality certifications (e.g.,
ISO 9001, CMM, Prince2, TQM, etc.) for your pro-
cess?
2.25 If your organisation is certified to some stan-
dards (e.g., ISO 9001, CMM, Prince2, TQM, etc.),
which is the (average) level of compliance with them?

5
3 Process Requirements Engineering
Requirements Elicitation
Question N/A UN VL L A H VH
3.1 Do you carry out a feasibility study before
starting a new project?
3.2 While eliciting requirements are you sensible to
organisational and political factors which influence
requirements sources?
3.3 Do you use business concerns to drive require-
ments elicitation?
3.4 Do you prototype poorly understood require-
ments?
3.5 Do you use scenarios to elicit requirements?
3.6 Do you define operational processes?
3.7 Do you reuse requirements from other systems
which have been developed in the same application
area?

Requirements Analysis and Negotiation

Question N/A UN VL L A H VH
3.8 Do you define system boundaries?
3.9 Do you use checklists for requirements analysis?
3.10 Do you encourage the use of electronic sys-
tems (e.g., e-mail) to support requirements negotia-
tions?
3.11 Do you plan for conflicts and conflict resolu-
tion?
3.12 Do you prioritise requirements?
3.13 Do you classify requirements using a multi-
dimensional approach which identifies specific types
(e.g., hardware-software, changeable-stable, etc.)?
3.14 Do you use interaction matrices to find con-
flicts and overlaps?
3.15 Do you perform any risk analysis on require-
ments?

6
 Requirements Validation
Question N/A UN VL L A H VH
3.16 Do you check that requirements document
meets your standards?
3.17 Do you organise formal requirements inspec-
tions?
3.18 Do you use multi-disciplinary teams to review
requirements?
3.19 Do you involve external (from the project) re-
viewers in the validation process?
3.20 In order to focus the validation process do you
define validation checklists?
3.21 Do you use prototyping to animate / demon-
strate requirements for validation?
3.22 Do you propose requirements test cases?
3.23 Do you allow different stakeholders to partic-
ipate in requirements validation?

Requirements Management
Question N/A UN VL L A H VH
3.24 Do you uniquely identify each requirement?
3.25 Do you have defined policies for requirements
management?
3.26 Do you record requirements traceability from
original sources?
3.27 Do you define traceability policies?
3.28 Do you maintain a traceability manual?
3.29 Do you use a database to manage require-
ments?
3.30 Do you define change management policies?
3.31 Do you identify global system requirements?
3.32 Do you identify volatile requirements?
3.33 Do you record rejected requirements?
3.34 Do you reuse requirements over different
projects?

7
 Requirements Evolution/Maintenance
Question N/A UN VL L A H VH
3.35 Has the expected life of the project been de-
fined?
3.36 Has the expected frequency of change been
defined?
3.37 Has the importance of keeping the system up
to date functionally been defined?
3.38 Has the importance of keeping the system up
to date technologically been defined?
3.39 Has it been decided who will perform mainte-
nance on the project?
3.40 Are the areas of greatest expected change
identified?
3.41 Has the method of introducing change during
development been identified?
3.42 Have provisions been included to properly
document the application for maintenance purposes?

Requirements Process Deliverables

Question N/A UN VL L A H VH
3.43 Are the deliverables of the requirements pro-
cess well identified within your organisation?
3.44 Is the task of each deliverable well defined
within your organisation?
3.45 Are the responsibilities for producing the de-
liverables well defined within your organisation?
3.46 Is the deliverables’ schedule well defined
within your organisation?
3.47 Are the responsibilities for reviewing the de-
liverables well defined within your organisation?
3.48 Are relationships among deliverables well de-
fined within your organisation?
3.49 Are requirements used as the basis for devel-
oping project plans?
3.50 Are requirements used as a basis for design?
3.51 Are requirements used as the basis for testing?
3.52 Are requirements allocated to the software
functions of the product?

8
4 Product Requirements Engineering
Requirements Description
Question N/A UN VL L A H VH
4.1 Do you have standards templates / documents
for describing requirements?
4.2 Do you have a specific lay out for the require-
ments document to improve readability?
4.3 Do you have guidelines how to write require-
ments?
4.4 Do you produce a summary of the require-
ments?
4.5 Do you make a business case for a system?
4.6 Do you have a glossary of specialised terms?
4.7 Is the requirements document easy to change?
4.8 Do you use diagrams appropriately?
4.9 Do you supplement natural language with other
descriptions of requirements?
4.10 Do you specify requirements quantitatively?

System Modelling
Question N/A UN VL L A H VH
4.11 Do you define the system’s operating environ-
ment?
4.12 Do you develop complementary system mod-
els?
4.13 Do you model the system’s environment?
4.14 Do you model the system architecture?
4.15 Do you use structured methods for system
modelling?
4.16 Do you define operational processes to reveal
process requirements and requirements constraints?
4.17 Do you use a data dictionary?
4.18 Do you document the links between stake-
holder requirements and system?
4.19 Do you specify systems using formal specifi-
cations?

9
 Functional Requirements
Question N/A UN VL L A H VH
4.20 Can the data required by the application be
collected with the desired degree of reliability?
4.21 Can the data be collected within the time pe-
riod specified?
4.22 Have the user requirements been defined in
writing?
4.23 Are the requirements stated in measurable
terms?
4.24 Has the project solution addressed the user
requirements?
4.25 Could test data be developed to test the
achievement of the objectives?
4.26 Have procedures been specified to evaluate the
implemented system to ensure the requirements are
achieved?
4.27 Do the measurable objectives apply to both
the manual and automated segments of the applica-
tion system?

Non Functional Requirements

Question N/A UN VL L A H VH
4.28 Do you identify non functional requirements
(e.g., usability, quality, cognitive workload, etc.) for
a system?
4.29 Have the user functions been identified?
4.30 Have the skill levels of the users been identi-
fied?
4.31 Have the expected levels of supervision been
identified?
4.32 Has the time span for user function been de-
fined?
4.33 Will the counsel of an industrial psychologist
be used in designing user functions?
4.34 Have user clerical people been interviewed
during the requirements phase to identify their con-
cerns?
4.35 Have tradeoffs between computer and people
processing been identified?
4.36 Have the defined user responsibility been pre-
sented to the user personnel for comment?

10
 Portability Requirements
Question N/A UN VL L A H VH
4.37 Are significant hardware changes expected
during the life of the project?
4.38 Are significant software changes expected dur-
ing the life of the project?
4.39 Will the application system be run in multiple
locations?
4.40 If an on-line application, will different types
of terminal be used?
4.41 Is the proposed solution dependent on specific
hardware?
4.42 Is the proposed solution dependent on specific
software?
4.43 Will the application be run in other countries?
4.44 Have the portability requirements been docu-
mented?

Systems Interface
Question N/A UN VL L A H VH
4.45 Have data to be received from other applica-
tions been identified?
4.46 Have data going to other applications been
identified?
4.47 Have the reliability of interfaced data been de-
fined?
4.48 Has the timing of transmitting data being de-
fined?
4.49 Has the timing of data being received been
defined?
4.50 Has the method of interfacing been defined?
4.51 Have the interface requirements been docu-
mented?
4.52 Have future needs of interfaced systems been
taken into account?

11
 Requirements Viewpoints
Question N/A UN VL L A H VH
4.53 Do you identify and consult all likely, sources
of requirements, system stakeholders?
4.54 Do you look for domain constraints?
4.55 Do you collect requirements from multiple
viewpoints?
4.56 Do you use language simply, consistently and
concisely for describing requirements?
4.57 Do you record requirements traceability from
original sources?
4.58 Do you record requirements rationale in order
to improve requirements understanding?

Product-Line Requirements
Question N/A UN VL L A H VH
4.59 Do you define safety-critical requirements?
4.60 Do you identify and analyse hazards?
4.61 Do you derive safety (or security, availability,
etc.) requirements from hazard analysis?
4.62 Do you cross-check operational and functional
requirements against safety (or security, availability,
etc.) requirements?
4.63 Do you collect incident experience (e.g., by
incident reports)?
4.64 Do you analyse incident reports?
4.65 Are responsibilities (for system safety) well
identified within your organisation?
4.66 Do you define operational profiles for a sys-
tem?
4.67 Do you develop use cases for a system?

12
 Failure Impact Requirements
Question N/A UN VL L A H VH
4.68 Has the financial loss of an application system
failure been defined?
4.69 Has the financial liss calculation for a failure
been extended to show the loss at different time in-
tervals, such as one hour, eight hours, one day, one
week, etc.?
4.70 Is the proposed system technology reliable and
proven in practice?
4.71 Has a decision been made as to whether it is
necessary to recover this application in the event of
a system failure?
4.72 Are alternative processing procedures needed
in the vent that the system becomes unoperational?
4.73 If alternative processing procedures are
needed, have they been specified?
4.74 Has a procedure been identified for notifying
users in the event of a system failure?
4.75 Has the desired percent of up-time for the sys-
tem been specified?

13
References
[1] William E. Perry. Effective Methods for Software testing. John Wiley & Sons, second edition, 2000.

[2] Suzanne Robertson and James Robertson. Mastering the Requirements Process. Addison-Wesley,
1999.

[3] Ian Sommerville and Pete Sawyer. Requirements Engineering: A Good Practice Guide. John Wiley
& Sons, 1997.

[4] Karl Eugene Wiegers. Software Requirements. Microsoft Press, 1999.

14
 Notes

15

View publication stats