Requirement Engineering

Lecture 1
 Introduction
• Question of the day
– Can you walk on the water?
• Think and discuss at the end of the lecture
 Background
• Development of failed software since 60s:
– Systems being delivered late over budget
– They don’t really do what user wanted to
– Never been used to their full effectiveness by people
• Reason ?
– No single reason / single solution to the problem
– Major contributory factor – “ Difficulties with system
requirement”
• System requirement
– What the system is required to do and the circumstances
under which it is required to operate
– A requirement is a necessary attribute in a system
 Requirement
• Something required, something wanted or needed
– Webster’s dictionary
• There is a huge difference between wanted and needed and it
should be kept in mind all the time
• Sources of Requirements
– Stakeholders
• People affected in some way by the system
– Documents
– Existing system
– Domain/business area
• What are requirements?
– A statement of a system service or constraint
– Defined early as specification of
• what should be implemented
• Description of how the system should behave, domain
information, constraints on system operation
– So the requirement might describe
• A user level facility - spell checker and correction
• A very general system property - personal information disclosure
• A specific constraint on system - sensor must be polled 10 times
a second
• How to carry out some computation - some formula
• Why are Requirements important?
– They provides the basis for all the development work
that follows
– Once the requirements are set, developers initiate other
technical work:
• System design, development, testing, implementation and
operation
 Requirements Engineering
• The process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed.

• The requirements themselves are the descriptions

of the system services and constraints that are
generated during the requirements engineering
process.
 Requirement Classification
• Requirements are commonly classified as (IEEE
std 830, 1998): (Need to be discussed in next
class)
– Functional:
• A requirement that specifies an action that a system MUST be
able to perform, without considering physical constraints
– A requirement that specifies input/output behavior of the system
– Non-Functional:
• A requirement that specifies system PROPERTIES, such as
environmental and implementation constraints, performance,
dependencies, maintainability, extensibility and reliability.
• Often classified as:
– Performance Requirements
– External interface requirements
– Design constraints
– Quality attributes
 Requirements problems
• Many system engineering problems stem from
problems with the system requirement
• Common problems are:
– The requirements don’t reflect the real needs of the
customer for the system.
– Requirements are inconsistent and/or incomplete.
• The system shall allow users to search for an item by
title, author, or by ISBN? – is the requirement
incomplete
– It is expensive to make changes to requirements after
they have been agreed.
– There are misunderstandings between customers, those
developing the system requirements and software
engineers developing or maintaining the system.
 Identifying Problem

Boundaries • Which problem needs to be solved?

• Where is the problem? Problem Domain
Stakeholder • Whose problem is it?
• Why does it need solving? Stakeholders Goal
Scenarios • How might a software system help?
• When does it need solving? Development Constraints
Feasibility • What might prevent us from solving it?
 Cont…
• Significant Difference – Asking & Accepting
• Often huge difference – stated & real requirement
– Stated Requirement
• Those provided by a customer at the beginning of software
development effort

– Real Requirement
• Those that reflect the verified needs of user for a particular
system
– Identification is interactive and Iterative requirement process

• Analysis of stated requirement helps to determine

– The refine real needs and expectations of the user from
the delivered system
• So many different types of requirement
– Not possible to
• Describe a standard way of writing requirement
• Define best way to specify requirement
– It depends on:
• Who is writing the requirement
• Who is likely to read the requirement
• General practices of the developing organization
• The application domain of the system
 Requirements engineering processes
• The processes used for RE vary widely depending on:
– The application domain,
– The people involved and
– The organisation developing the requirements.
• Requirement Engineering is the process of defining,
documenting and maintaining the requirements. It is a
process of gathering and defining service provided by the
system. Requirements Engineering Process consists of the
following main activities:
– Requirements elicitation
– Requirements specification
– Requirements verification and validation
– Requirements management
 Processes
• A process is an organized set of activities which
transforms inputs to outputs
– Process descriptions encapsulate knowledge and allow
it to be reused
• Examples of process descriptions
– Instruction manual for a dishwasher
– Cookery book
– Procedures manual for a bank
– Quality manual for software development
 RE Process - inputs and outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
 RE Activities
Requirements
Engineering

Requirements Requirements Requirements

Inception Development Management

Elicitation Analysis Specification Verification

 Elicitation and analysis
• Sometimes called requirements elicitation or
requirements discovery.
– Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints.
• May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.
 Requirement Elicitation (Techniques)
• Requirement Elicitation - requirements discovery
– Fact Gathering Techniques
• Interviews
• Questionnaires
• Analyzing documents
• Observation – ethnography (A social scientists spends a
considerable time observing and analysing how people actually
work.
– People do not have to explain or articulate their work.
– Social and organisational factors of importance may be
observed.
–)
 Stakeholders
• Types
– Software engineers responsible for system development
– System end-users who will use the system after it has been
delivered
– Managers of system end-users who are responsible for their
work
– External regulators who check that the system meets its
legal requirements
– Domain experts who give essential background information
about the system application domain
 ATM Stakeholders
– Bank customers
– Representatives of other banks
– Bank managers
– Counter staff
– Database administrators
– Security managers
– Marketing department
– Hardware and software maintenance engineers
– Banking regulators
 Elicitation Techniques
• Interviewing
– In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that they
use and the system to be developed.
– There are two types of interview
• Closed interviews where a pre-defined set of questions are
answered.
• Open interviews where there is no pre-defined agenda and a
range of issues are explored with stakeholders.
 Interviews in practice
• Normally a mix of closed and open-ended
interviewing.
– Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact with
the system.
• Interviews are not good for understanding domain
requirements
– Requirements engineers cannot understand specific
domain terminology;
 Effective interviewers
• Interviewers should be:
– open-minded,
– willing to listen to stakeholders and
– should not have pre-conceived ideas about the
requirements.
• They should prompt the interviewee with a
question or a proposal and should not simply
expect them to respond to a question such as
‘what do you want’.
 Effective interviewers
• Prepare yourself as well as the user. Send them warm-up
materials.
• Depending on their role and availability, meet in a neutral
place.
– Meeting room.
• Reduces distractions for both parties. No email or ringing
phones. Turn off your phone
• Bring:
– tape recorder
– legal pad for both of you
– colored pens
– business cards
• Role play if the user’s explanation is unclear.
– Users cannot express the procedures they follow
– The management says one thing, operational reality is completely
different.
 Elicitation Techniques
• Surveys
– Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
• Questionnaires
– A document with pre-defined set of objective questions
and respective options is handed over to all stakeholders
to answer, which are collected and compiled.
– A shortcoming of this technique is, if an option for some
issue is not mentioned in the questionnaire, the issue
might be left unattended.
 Elicitation Techniques
• Prototyping
– Prototyping is building user interface without adding
detailed functionality for user to interpret the features of
intended software product. It helps giving better idea of
requirements. If there is no software installed at client’s
end for developer’s reference and the client is not aware
of its own requirements, the developer creates a
prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is
noted. The client feedback serves as an input for
requirement gathering.
 Elicitation Techniques
• Domain Analysis
– Every software falls into some domain category. The
expert people in the domain can be a great help to
analyze general and specific requirements.
• Brainstorming
– An informal debate is held among various stakeholders
and all their inputs are recorded for further requirements
analysis.
 Elicitation Techniques
• Observation
– Team of experts visit the client’s organization or
workplace. They observe the actual working of
the existing installed systems. They observe the
workflow at client’s end and how execution
problems are dealt. The team itself draws some
conclusions which aid to form requirements
expected from the software.
Software Requirements Engineering

Lecture 2
 Requirements Analysis
• The aim of requirements analysis
– “To discover problems with the system
requirements, especially incompleteness and
inconsistencies”
• Analysts read the requirements, highlight
problems, and discuss them in requirements
review meetings
– This is a time-consuming and expensive activity
 Requirements Analysis (checks)
• Necessity checking
– The need for the requirement is analyzed.
• In some cases, requirements may be proposed which don’t contribute
to the business goals of the organization or to the specific problem to be
addressed by the system.
• Consistency and completeness checking
– The requirements are cross-checked for consistency and
completeness.
• Consistency means that no requirements should be contradictory
• Completeness means that no services or constraints which are needed
have been missed out.
• Feasibility checking
– The requirements are checked to ensure that:
• They are feasible in the context of the budget and schedule available
for the system development.
 Problems of Requirements Analysis
• Stakeholders don’t know what they really want.
– Stakeholders express requirements in their own terms.
– Different stakeholders may have conflicting
requirements.
• Organisational and political factors may influence
the system requirements.
– The requirements change during the analysis process.
• New stakeholders may emerge and the business environment
change.
 Requirements Negotiation
• Disagreements about requirements are
inevitable when a system has many
stakeholders.
– Conflicts are not ‘failures’ but reflect different
stakeholder needs and priorities
• Requirements negotiation is the process of
discussing requirements conflicts and
reaching a compromise that all stakeholders
can agree to
 Requirements Negotiation Stages
• Requirements discussion
– Requirements which have been highlighted as
problematical are discussed and the stakeholders
involved present their views about the requirements.
• Requirements prioritization
– Disputed requirements are prioritized to identify critical
requirements and to help the decision making process.
• Requirements agreement
– Solutions to the requirements problems are identified
and a compromise set of requirements are agreed.
• Generally, this will involve making changes to some of the
requirements.
 Requirements Specification
• This activity is used to produce formal software
requirement models.
• All the requirements including the functional as well
as the non-functional requirements and the
constraints are specified by these models in
totality.
• During specification, more knowledge about the
problem may be required which can again trigger
the elicitation process.
• The models used at this stage include ER
diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries,
etc.
 Requirements Verification and Validation
Verification: It refers to the set of tasks that ensure that software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensure that the software
that has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirements definitions
would propagate to the successive stages resulting in a lot of modification
and rework.
The main steps for this process include:
• The requirements should be consistent with all the other requirements
i.e no two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
• Reviews, buddy checks, making test cases, etc. are some of the
methods used for this.
 Requirements Management
• The process of managing change to the
requirements for a system
• The principal concerns of requirements
management are:
– Managing changes to agreed requirements
– Managing the relationships between requirements
– Managing the dependencies between the requirements
document and other documents produced in the systems
engineering process
 Requirements Management VS
Requirement Traceability
• Req Management Vs Req Traceability
– Requirements cannot be managed effectively without
requirements traceability
– A requirement is traceable if
• you can discover who suggested the requirement,
• why the requirement exists,
• what requirements are related to it and
• how that requirement relates to other information such as
systems designs, implementations and user documentation
 RE process problems
• Lack of stakeholder involvement
• Business needs not considered
• Lack of requirements management
• Lack of defined responsibilities
• Stakeholder communication problems
• Over-long schedules and poor quality requirements
documents
 RE process problems
• Personality and status of stakeholders
– May be from different department and may not give
quality time to RE
• The personal goals of individuals within an
organization
– May consider their own interest, may not talk about the
goal of other
• The degree of political influence of stakeholders
within an organization
– Seniors Vs junior viewpoint
– Political interest and pressure group
• Walking on water and developing software from a
specification are easy
• if they are frozen