Systems investigation

and Requirements
Engineering
System Analysis And Design- Session 02
Aim…
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements documentation
• Requirements management
• Prototyping
• Characteristics of Good Information
Requirements engineering

IEEE Definition of a requirement (standard glossary,

610.12-1990)
• A condition or capability needed by a user to solve a
problem or achieve an objective
• A condition or capability that must be met by a
system or system component to satisfy a contract,
standard, specification or other formally imposed
Requirement document
• A documented representation of a condition or
defined capability

BCS ‘business analysis’ glossary definition

• A feature that the business users need the new
system to provide

Sommerville & Sawyer

… a specification of what should be implemented.
Requirements engineering

A process of
What is meant requirements:
• Elicitation
by requirements • Analysis
engineering? • Validation
• Documentation
• Management
Requirements engineering activities

Requirements Requirements Requirements

elicitation analysis validation

Requirements documentation

Requirements management

5
Sources of requirements

The Stakeholders
Where do • Sponsors
• Managers
requirements • End users
come from? • SME
• The project team
• Legacy applications
• Documents
• Competition
Requirement gathering techniques

Elicitation techniques

Requirements • Workshops
• Interviews
gathering • Observation
techniques • Questionnaires
• Scenarios
• Prototyping
• Document analysis
Workshops
• A structured meeting in which a group of appropriately
knowledgeable and motivated people are moderated by
an impartial facilitator to achieve an agreed objective
• Advantages
• Fast (?)
• Stakeholders involved and committed – feel ownership
• Developers and stakeholders understand each other
• Simple method of resolving issues/options
• More creative solutions are produced
• Disadvantages
• Hard to schedule
• Group dynamics need careful managing
• Hidden agendas

8
Interviews

• A structured discussion between the analyst and a stakeholder

to elicit facts and information about the business situation and
their role in it
• Usually a one-to-one interactive interview, which requires skill
in planning, conducting and following up
• Advantages
• Builds relationship with stakeholder
• Can elicit detailed information
• Confidential
• Disadvantages
• Only one viewpoint
• May get opinions or solutions, not facts
• Take lots of time

9
Observation

• Watch what people do either by formal agreement or

informally by just ‘wandering about’

• Advantages:
• We can get a good understanding of the processes,
problems, politics etc.
• Helps devise workable, acceptable solutions
• Disadvantages:
• Can feel like ‘Big Brother’ – unsettles the observed
• Your presence may impact the process

10
Types of observation

• Formal observation
• Watching specified tasks
• Staff are prepared
• May see only what they want you to see
• Informal observation
• No staff preparation
• May not see all required tasks being performed
• Shadowing
• Following a user for period of time
• May include protocol analysis
• Good for uncovering tacit knowledge

11
Questionnaires
• Good way to get information from a wide range of viewpoints

• Advantages
• Can reach a large audience, even if geographically separated
• Can uncover common problems
• Can determine attitudes
• Disadvantages
• People don’t like questionnaires
• They must be kept small and focused
• It takes skill to formulate the questions
Scenarios

• Telling the story of the task, including:

• All steps from business trigger to outcome
• Pre-conditions
• Must be true for the scenario to begin
• Post-conditions
• Must be true following conclusion
• Alternative paths
• Exception situations
• Advantages
• Aids visualisation and discussion of real
life situations
• Can be used to build test scenarios
• Disadvantages
• Can become complex, especially
where many alternative paths

13
Document analysis

• Reviewing and analysing source documentation such as forms,

screen layouts and reports
• Advantages
• Can yield good information on
• Organisation
• Process
• System
• Disadvantages
• Don’t get differing viewpoints
• Dry and tedious

14
Prototyping

• Creating a ‘demonstration system’ to help clarify vague

requirements

• Advantages
• Helps the user to really determine the requirements
• Especially user interface, performance, navigation paths
• Validates requirements
• Reduces risk of “getting it wrong”
• Disadvantages
• Can run out of control
• Can raise unrealistic expectations
• Can lead user to overestimate progress

15
Requirements engineering activities: Analysis

Requirements Requirements Requirements

elicitation analysis validation

Requirements documentation

Requirements management

16
Analysis in context

• Ensure that requirements gathered so far are

• Clear
• Organised
• Documented
• Analysis will raise additional questions
• Analyst will revisit elicitation stage
• Elicitation and analysis are done iteratively

17
Types of requirements

Requirements

Business Solution

General Functional

Non-
Technical
functional

18
Business: general requirements

Business constraints Business policies Legal

• Budget, timescale, • Standards, business • Legislative and
resources etc. rules regulatory constraints

Branding Cultural Language

• Image, style guide • Vision, approach, • If operating across
management style etc. international
boundaries

Business continuity
• Coping with disaster

19
Business: technical requirements

Hardware Software
• IT and other hardware • Operating systems, package
applications, networking,
communications etc.

Interoperability Internet
• Standards for communicating • Policies on Internet use and
between systems and devices web services

20
 Requirement Redefined
• A specification of want or need that an eventual application solution
should satisfy.
• Functional requirements (FR):
• Specify what the product must do,
• What actions it must take, in order to satisfy the product’s goals, as
defined by the stakeholders
• They relate to some form of data/information manipulation

• Non-functional requirements (NF):

• Specify how the product must be
• What characteristics it must have
• Specify the way the functionality is to be delivered (form)
• Constraints on the way the functionality operates
Separate Functional and Non-functional Requirements1

W
Non-functional Solutions?
Requirements?

How many
HA
How fast
Who
WhenT Functional
Requirements?
Solution: functional requirements

• Expressions of stakeholder needs of a system to achieve particular

goals
• They are WHAT the system must do or facilities it must offer
• Often relate to data capture, manipulation or reporting
• Functional requirements must be implementable and testable

• Example: the system will:

• Hold details of all customers including name, address, credit limit, date
of first order
• Allow changes to be made to customer details
• Report on all orders placed in the last week

23
Solution: functional requirements

Data entry Data maintenance

• Gathering and recording • Changes to data, including
data data deletion

Procedural Retrieval requirements

• Implementation of • Reporting, responding to
business rules enquiries

24
Solution: non-functional requirements
• Define HOW WELL the functional requirements will be provided
• Must be implementable and testable
• Major factors in the cost of the product

• The system must be able to respond to 10,000 enquiries per day

• This is a capacity requirement

• Reprint the report on demand

• This is an availability requirement

• Respond to an enquiry on available customer credit within 5 seconds

• This is a performance requirement

25
Solution: non-functional requirements
Performance Security Access
• Speed of processing • Security levels for • Permissions, who has
transactions protection of data access to which
functionality and how

Backup & Archiving & Robustness

recovery retention • Reliability, data
integrity, user error
• Protection against • Duration, methods,
loss of data eventual deletion

Availability Usability Capacity

• Timeframe for • Ease of learning, ease • Data volumes,
availability of of use transaction volumes,
functionality user volumes

26
FURPS
FURPS is an acronym representing a model for classifying software quality
attributes (functional and non-functional requirements):
• Functionality - Capability (Size & Generality of Feature Set), Reusability
(Compatibility, Interoperability, Portability), Security (Safety &
Exploitability)
• Usability (UX) - Human Factors, Aesthetics, Consistency, Documentation,
Responsiveness
• Reliability - Availability (Failure Frequency
(Robustness/Durability/Resilience), Failure Extent & Time-Length
(Recoverability/Survivability)), Predictability (Stability), Accuracy
(Frequency/Severity of Error)
• Performance - Speed, Efficiency, Resource Consumption (power, ram,
cache, etc.), Throughput, Capacity, Scalability
• Supportability (Serviceability, Maintainability, Sustainability, Repair
Speed) - Testability, Flexibility (Modifiability, Configurability, Adaptability,
Extensibility, Modularity), Installability, Localizability

27
Requirements Hierarchies
• Requirements are often associated hierarchically
• A functional requirement (FR) may have non-functional requirements
(NFR) specific to it
• E.g. Reprint the report on demand
• A non-functional requirement could lead to the need for functionality
• E.g. Access control leads to functionality for
• Identification of the user
• Authentication of the user
Prioritising requirements (MoSCoW)
• It is important to prioritise requirements:
• It allows the staging of requirement implementation
• It enables the management of user expectations

• Mandatory in the first increment; cannot meet

M – must have objectives without it

• Mandatory but may wait until second increment;

S – should have the system will have short-term value without it

• Beneficial if time or funds allow, but not central

C – could have to project objectives

W – want to have • Will not be met in this delivery; may be upgraded

(won’t have this time) in a future delivery

29
Requirements engineering activities: Validation

Requirements Requirements Requirements

elicitation analysis validation

Requirements documentation

Requirements management

• Validation is concerned with proving that the ‘final’ draft is as

free from defects as possible and complies with standards.
30
Requirements validation

• The majority of errors are made in the analysis stage of the project
• After the requirements catalogue has been analysed and negotiated, it
MUST be validated and signed off by the senior stakeholders
• A forum for requirements validation is a formal review
• A peer group or stakeholder group review for the purposes of finding
deficiencies in the requirements

31
Review responsibilities
• Requirements engineer (the author):
• Liaise with the moderator prior to the review
• Provide necessary documentation for distribution
• Walkthrough the requirements
• Moderator:
• Is independent of the requirements engineering process
• Selects time and place acceptable to all
• Ensures that reviewers can/will attend
• Distributes the documentation
• Enforces the rules
• Ensures that the review runs smoothly and efficiently
• Reviewers:
• Work hard to ensure defects are found

32
Role of moderator in the review

• Introduction – set the scene

• Control the agenda
• Spot ‘ego’ problems
• Spot re-design
• Stop dead-end arguments
• Ensure scribe keeping pace
• Watch time
• Get scribe to read out action list
• Get agreement on what next

33
 What we covered …
Requirements Engineering activities

• Techniques for requirements elicitation

• Types of requirements
• Analysing, prioritising and validating requirements
• Agile Model
• Prototyping
 TO DO…

Exercises