Requirement Analysis & Specification

 Dr. Saqib Saeed

 PhD Information Systems [University of Siegen, Germany]
 MS Software Technology [Stuttgart University of Applied
Sciences Germany]
 Saqib.saeed@gmail.com
 5 Edited Books
 7 Guest Edited Journal Special Issues
 5 Book Chapters
 12 Journal Articles
 15 Conference Papers
 Research Interests
 Empirical Software Engineering
 Human Centered Computing
Course Objective

 On completion of the course the student will:

 be able to skillfully elicit software requirements
 be able to clearly and unambiguously document software
requirements according to industry standards
 thoroughly understand and be able to describe how to
conduct bespoke requirements engineering in terms of
common processes and techniques
 thoroughly understand and be able to describe the
challenges involved in traditional requirements engineering
 be able to comprehensively assess current requirements
engineering practices in a software project or a software
development company
 be able to suggest relevant improvements on the
requirements engineering processes in a convincing way
Textbook(s)

 Requirements Engineering – A Good Practice Guide

 I. Sommerville & Pete Sawyer
 Software Requirements
 Karl Wiegers
Contents

 Introduction to requirements analysis and specification.

 Market-driven requirements engineering (MDRE) vs.
Bespoke
 Requirements Elicitation
 Requirements Specification
 Quality Assurance
 Requirements Prioritization
 Management
 Buffer time
What is a requirement?

 It may range from a high-level abstract statement of

a service or of a system constraint to a detailed
mathematical functional specification.
 This is inevitable as requirements may serve a dual
function
 May be the basis for a bid for a contract - therefore must be
open to interpretation;
 May be the basis for the contract itself - therefore must be
defined in detail;
 Both these statements may be called requirements.
Requirements abstraction (Davis)

“If a company wishes to let a contract for a large software development project, it
must define its needs in a sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organisation’s needs. Once a
contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will
do. Both of these documents may be called the requirements document for the
system.”
Types of requirement

 User requirements
 Statements in natural language plus diagrams of the
services the system provides and its operational constraints.
Written for customers.
 System requirements
 A structured document setting out detailed descriptions of
the system’s functions, services and operational constraints.
Defines what should be implemented so may be part of a
contract between client and contractor.
Definitions and specifications
User requir ement definition

1. The softw are m ust provide a means of representing and

1. accessing e xternal files crea ted b y other tools.

System requir ements specification

1.1 The user should be pr ovided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associa ted tool w hich ma y be
1.2 applied to the file .
1.3 Each external file type may be repr esented as a specific icon on
1.2 the user’s displa y.
1.4 Facilities should be pr o vided for the icon r epresenting an
1.2 external file type to be defined b y the user.
1.5 When a user selects an icon r epr esenting an e xternal file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Functional and non-functional requirements

 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
 Non-functional requirements
 constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 Domain requirements
 Requirements that come from the application domain of the
system and that reflect characteristics of that domain.
Functional requirements

 Describe functionality or system services.

 Depend on the type of software, expected users and
the type of system where the software is used.
 Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe the
system services in detail.
Examples of functional requirements

 The user shall be able to search either all of the

initial set of databases or select a subset from it.
 The system shall provide appropriate viewers for the
user to read documents in the document store.
 Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to
the account’s permanent storage area.
Requirements inaccuracy

 Problems arise when requirements are not precisely

stated.
 Ambiguous requirements may be interpreted in
different ways by developers and users.
 Consider the term ‘appropriate viewers’
 User intention - special purpose viewer for each different
document type;
 Developer interpretation - Provide a text viewer that shows
the contents of the document.
Requirements completeness and
consistency

 In principle, requirements should be both complete

and consistent.
 Complete
 They should include descriptions of all facilities required.
 Consistent
 There should be no conflicts or contradictions in the
descriptions of the system facilities.
 In practice, it is impossible to produce a complete
and consistent requirements document.
Non-functional requirements

 These define system properties and constraint e.g.

reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
 Process requirements may also be specified
mandating a particular CASE system, programming
language or development method.
 Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless.
Non-functional classifications

 Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability,
etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional requirement types
Non-functional
requir ements

Product Organisational External

requir ements requir ements requir ements

Efficiency Reliability Portability Inter oper a bility Ethical

requir ements requir ements requir ements requir ements requir ements

Usa bility Deli very Implementa tion Standar ds Leg islative

requir ements requir ements requir ements requir ements requir ements

Perfor mance Space Pri vacy Safety

requir ements requir ements requir ements requir ements
Goals and requirements

 Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify.
 Goal
 A general intention of the user such as ease of use.
 Verifiable non-functional requirement
 A statement using some measure that can be objectively
tested.
 Goals are helpful to developers as they convey the
intentions of the system users.
Examples

 A system goal
 The system should be easy to use by experienced controllers
and should be organised in such a way that user errors are
minimised.
 A verifiable non-functional requirement
 Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this
training, the average number of errors made by experienced
users shall not exceed two per day.
Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements interaction

 Conflicts between different non-functional

requirements are common in complex systems.
 Spacecraft system
 To minimise weight, the number of separate chips in the
system should be minimised.
 To minimise power consumption, lower power chips should
be used.
 However, using low power chips may mean that more chips
have to be used. Which is the most critical requirement?
Domain requirements

 Derived from the application domain and describe

system characteristics and features that reflect the
domain.
 Domain requirements be new functional
requirements, constraints on existing requirements or
define specific computations.
 If domain requirements are not satisfied, the system
may be unworkable.
Domain requirements problems

 Understandability
 Requirements are expressed in the language of the
application domain;
 This is often not understood by software engineers
developing the system.
 Implicitness
 Domain specialists understand the area so well that they do
not think of making the domain requirements explicit.
User requirements

 Should describe functional and non-functional

requirements in such a way that they are
understandable by system users who don’t have
detailed technical knowledge.
 User requirements are defined using natural
language, tables and diagrams as these can be
understood by all users.
System requirements

 More detailed specifications of system functions,

services and constraints than user requirements.
 They are intended to be a basis for designing the
system.
 They may be incorporated into the system contract.
 System requirements may be defined or illustrated
using system models discussed in Chapter 8.
Requirement engineering Process

 Requirement Elicitation
 Requirement Analysis & Negotiation
 Requirements Validation
 Requirements Specification
Requirements Elicitation

 “...the process of discovering the requirements for a

system by communication with customers, system
users and other who have a stake in the system
development.” (Ian Sommerville)
 “...the process of discovering the requirements for a
system by communication with stakeholders and
through the observation of them in their domain”
(Tony Gorschek)

28
The first step... sources of information.

 DOMAIN
 Understanding it
 Problem (application) domain
 What’s the problem(s) and who can explain it to you?
 History
 Previous systems / current systems
 Documentation
 Old requirements/design etc.
 Competitors
 Have they solved the problem and how?

29
The first step... sources of information…

 Surrounding environment
 Other systems, processes which the system should support
(and/or processes which the system influences)
 Stakeholders (management, users, future users,
system managers, partners, sub contractors, Law and
Policy, customer’s customers, domain experts,
developers etc)
 Finding them (Stakeholder Identification)
 Getting access to them (Cost, Politics)
 STAKEHOLDER ACCESS ISCRITICAL AND SHOULD BE
STATED AS SUCH, e.g. in contract or other agreement. (true
for other resources also, e.g. documentation etc.)--

30
The information to elicit.

 Domain description (operating environment)

 Business goals pertaining to the system
 Constraints on the system structure and/or behavior by clients
(human or not...)
 Problems that need to be solved – WHAT –
 -- Requirements –
 Attributes, e.g.
 Title, description
 ......but also...
 Rationale
 Source
 Importance
 Benefit
 Etc.
31
Elicitation – the time has come to start.

 To have the Domain and background information is an clear

advantage as you start the elicitation process.
 Know the environment
 Know the vocabulary
 Know the problem as good as possible beforehand
 Read documentation (process descriptions, manuals, mission statements,
specifications, organizational descriptions etc.)
 All this prepares you for the elicitation process
 Stakeholders are the main source for eliciting requirements...
but finding them does not mean you understand them!
 Important to get multiple views on the same issue
 Conflicts
 Many pieces can give a more complete picture

32
Elicitation – triangulation

33
Elicitation techniques – initial part

 Interviews
 Getting to know the present (domain, problems) and ideas for future
systems
 Hard to see the goals and critical issues, subjective
 Group interviews
 Stimulate each other, complete each other
 - Censorship, domination (some people may not get attention)
 Observation
 Look at how people actually perform a task (or a combination of
tasks) – record and review...
 + Map current work, practices, processes
 - Critical issues seldom captured (e.g. you have to be observing
when something goes wrong), usability issues seldom captured, time
consuming
34
Elicitation techniques (Part 2) – mid part

 Task demonstrations
 Ask a user to perform a task and observe and study what is done, ask questions
during.
 + Clarify what is done and how, current work
 - Your presence and questions may influence the user, critical issues seldom captured,
usability problems hard to capture
 Questionnaires
 + Gather information from many users (statistical indications, views, opinions)
 - Difficult to construct good questionnaires, questions often interpreted differently,
hard to classify answers in open questions and closed questions may be to narrow...
 Brainstorming
 Gathering of stakeholders and the exchange/gathering of ideas in an open
atmosphere where no one risks being ridiculed for their ideas and no ideas are
rejected/criticized
 + Many ideas (none are rejected)
 - Many ideas (have to be sorted and prioritized), hard to create a good atmosphere,
hard to get everybody involved, small groups, time consuming

35
Elicitation techniques (Part 3) – late part

 Use cases and Scenarios

 Description of a particular interaction between the (proposed)
system and one or more users (or other terminators, e.g. another
system). A user is walked through the selected operations and the
way in which they would like to interact with the system is recorded.
 + Concentration on the specific (rather than the general) which can
give greater accuracy
 - Solution oriented (rather than problem oriented), can result in a
premature design of the interface between the problem domain and
the solution
 Prototyping
 + Visualization, stimulate ideas, usability centered, (can be
combined with e.g. use cases)
 - Solution oriented (premature design), “is it already done?!”

36
Problems you may encounter.

 Stakeholders can’t express what they need

 (or express/exaggerate too much – risk forgetting important problems)
 Doing it is one thing, explaining it is another...
 Stakeholders express solutions instead of demands
 (e.g. “We want a faster car” when the need is to get to the destination faster – could
be solved with better roads or better route planning)
 Hard to imagine new ways of doing things, as well as consequences thereof...
 Different stakeholders have different (sometimes conflicting) views on the same
thing
 Resistance to change
 Political issues, Status, Culture
 Requirement change over time
 Many requirements
 Stakeholder Access
 Understanding of why RE is done.

37
Further complexity.

 Different kinds of systems – different considerations

 Bespoke (customized)
 Systems (software) designed for a particular customer
 CUSTOMER – DEVELOPER
 This category is often the one thought of in RE literature...
...but there are also...
 Generic products (Market driven)
 E.g. Word processors, databases etc.
 Not designed for a certain customer but a generic one (a group or several different ones)
 Very hard to identify “a customer” – stakeholder ID and stakeholder consultation very
hard...
 Based on market segments etc.
 Semi-generic products (Market driven)
 Products that have to comply to a certain set of rules (e.g. conform to a certain
operating environment and/or interact with other systems) but also be generic in nature.
 E.g. Software for mobile phones.
 Market driven – implies Continuous RE effort.

38
Elicitation – Market driven development
(very short version)

 Stakeholders can consist of complex constellations/ groups

that are not easily accessed or approached...
 Product Champions
 Representatives of a certain group of stakeholders, e.g. a certain user
group
 Often long term (project life cycle)
 A partner of sorts to the req. engineer that elicits and to some extent
analyses the req. that he/she gathers from the PC’s group
 Communicative, “a champion”, cooperative, access
 Focus Groups
 Similar to PC’s but often short term
 More than one person
 Representative for a group of stakeholders
 Work in “workshop” like environment with focus groups (e.g. JAD)
39
Market driven elicitation

 Personas
 Modeling (desc.) of a generic typical customer of a certain
type that can be said to be representative for a group (of
varying size – but homogenous)
 Competitor analysis
 Internally owned sources
 Support DB/Support Dept.
 Application Dept.
 Sales Dept.
 Developers / PMs /Experts
 Management
 Etc.

40
Reality Check !!!

 “the system should be fast enough for our purposes”

 “its important for the users to feel at home with the
system”
 “PCX protocol v.1.3 should be implemented”
 Req. on different abstraction levels
 “Use open standards” vs. “print screen”
 Req. not updated the last six months...
 Test, V&V, change???
 Req. not updated/archived at project completion

41
Bespoke and
MDRE

42
 development context
Single Customer Development Company

User Sales
representativ Buyer Project
e Manager

Users Maintenance
Users Developers
Users Other
stakeholders

• Bespoke development (developer – supplier)

• RE primarily as a start up activity within contractual work (maybe as a pre-study)
constructing a SRS to build, changes require negotiations btw customer and supplier
• Project focus (RE, Analysis, Design, V&V, Release.... etc)
• Domain knowledge largely has to be elicited from customers
• Success is characterized by e.g. contractual fulfillment and customer satisfaction (if yo
want repeat business)

43
development context II

Management
- Documentation, Change
Management, Traceability …

Analysis &
Elicitation Validation
change
Negotiation
Change

Agreed requirements
(requirements Developme
specification) nt

Development
New Project
requirements
Stakeholders (primarily
Customer) and other
sources (internal, external,
third-party etc) 44
 Many Customers Development Company

User
representativ Buyer Sales
e
development context III
Marketing

Maintenance Product
Users Application
Management
Users
Users Other Marketing
stakeholders Developer
s

Many end Customers

etc
Suppliers

Buyer/User Partners

Market-driven development
Many potential customers (e.g. a company and/or end- users)
–No “negotiation” but rather elicitation and evaluation, prediction, innovation
–Domain expertise internal primarily
–Success: Sales volume, ROI, market-share, growth etc. 45
development context IV
Product Management / Release Planning /(MDRE)
Management
- Documentation, Change Management,
Product
Traceability … Roadmap
R R
R
a+
a
Analysis & Validatio
1 n
Elicitation Management
Negotiation n
Repository
Triage
Estimation
Prioritizati
on Chang
Selection e

New
requirements
In-project RE
Agreed
(refinement of
requirements
req./technical
Market Analysis New requirements for release n
analysis)
New
Innovation requirements
(Invention) Developme
Marketing/ Key customers nt
Internal
Sources Sales
Distributors Development (release)
Support Project a
external Development
Market Sources Partners (release) Project
etc a+1
Development
Regulation (release) Project
a+n
Sub- 46
contractors
 background – industry environment
 Multiple influences (trends/hype/fashion, laws/regulations,
standards, other products etc) Multiple stakeholders (end-
customers, partners, sub-contractors, competitors, distributors etc)
 Multiple sources
 Elicited: e.g. market analysis, segment analysis, surveys, focus groups,
personas, competitor analysis
 Other: e.g. support system/dept., installers/app., marketing/sales,
management (unofficial), developers, experts, history (limitations) etc

Management
Sub-
contractors
Gap analysis
Competitor
Project 1
Distributors Requirements Project 2
Partner
Engineers Engineering ….
Project n
Customer
Law &
regulation
Trend
Etc
47
background – industry environment (2)

 Large amount of
information/data/requests/wishes/goals/requirements
coming in all the time…
 Limited only by when we choose to do cut-off
 Multiple levels of abstraction and refinement/contents
 Traceability and access to requirement sources vary largely –
e.g. getting hold of more information regarding req.
 Multiple projects for each product!
 !Multiple products for each company

48
multiple perspectives of requirements and
requirements engineering

49
 multiple perspectives (2)
Project perspective
 Delivered to a project:
 A package of requirements is allocated to a project!
 They are specified, initially analyzed and prioritized!
 Estimations/initial analysis, risk analysis are performed and attached to
the requirements (project planning parameters are based on these
estimations)!
 RE in projects revolves around:
 Manage requirements (V&V, refinement/break-down, update, risk analysis)
 Assure testability
 Assure that the end-result (e.g. software) of the project reflects the
requirements allocated to the project
 Assure requirements: Inspections, reviews
 Dependencies
 Assure end-result is in accordance with requirements (that the req. were
realized inthe right way): System test, acceptance tests, inspections, reviews
 Take care of CRs to requirements

50