CHAPTER ONE

Basics of software requirements engineering

College of Computing and Informatics

Department of Software Engineering
Requirements Engineering(RE)

 is the process of establishing the services that the

customer requires from a system and the constraints under
which it operates and is developed

 Is the process of discovering stakeholders (users) needs,

and documenting these in a form that is amenable to
analysis, communication, and subsequent implementation.

 Concerned with the specification of the functions and

constraints of a software system.
 Requirements Engineering(contd)

 RE involves:
 Understanding the difficulties people may have in describing their needs
(cognitive psychology).
 Observing human activities that helps to develop a richer understanding of
how computer systems may help or hinder those activities (anthropology).
 Understanding the political and cultural changes caused by
computerization (sociology).
 Communication skills (Linguistics).
 What is a requirement?

 Requirements are the descriptions of the services provided by a system and

its operational constraints
 Nothing can be said obvious
 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
 It may be as complex as a 500 pages of description
Requirements definition/specification

• Requirements definition
– A statement in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers
• Requirements specification
– A structured document setting out detailed descriptions of
the system services. Written as a contract between client
and contractor
• Software specification
– A detailed software description which can serve as a basis
for a design or implementation. Written for developers
Requirements readers

Client managers
System end-users
Requirements
Client engineers
defi nition
Contractor managers
System architects

System end-users
Requirements Client engineers
specification System architects
Software developers

Client engineers (perhaps)

Software
System architects
specification
Software developers
Wicked problems

 Most large software systems address wicked problems

 Problems which are so complex that they can never be fully understood
and where understanding evolves during the system development
 Therefore, requirements are normally both incomplete and inconsistent

 Reasons for inconsistency

o It is hard to anticipate the effects that the new system will have on the
organization
o Different users have different requirements and priorities. There is a
constantly shifting compromise in the requirements
 Prototyping is often required to clarify requirements
Why do requirements matter?
 Requirements are crucial to every project
 Every project succeeds or fails on the quality of its
requirements.
 Requirements set the scope of all subsequent work and
tell the project team what the users want.
 Without good requirements, projects fail, are late, come
in over budget, or produce systems that are never used..
 Requirement issues should be fixed early, before design.
 requirements errors tend to be deeply embedded in the
design and are difficult to remedy afterwards.
What are requirements for?
 To show what results stakeholders want
o They must be documented, otherwise there might be shifting views of the
project's scope and objectives.
 To give stakeholders a chance to say what they want
o All the stakeholders in a project, whether users or not, have requirements.
o They use them to see what the overall project is for, and where their own
work fits in.
o requirements are often the only chance that users have to tell the world
what they want.
 To represent different viewpoints
o different stakeholders contribute requirements from separate viewpoints.
o Different groups have their own needs, which may sometimes conflict.
o The designer will have to find a way of providing a compromising
solution
What are requirements for?
 To check the design
o Writing down each requirement lets test engineers check that the system
does what it should:
o Developers can tune a design based on the requirement to make it fit the
need better.
 To measure progress
o a clear requirement means that progress can be measured and areas
needing attention can be identified.
 To accept products with precise criteria
o a requirement is both something to be tested, and a source of acceptance
criteria.
o Meeting these criteria provides evidence that a product does what it
should.
 Good, sharp acceptance criteria come naturally from precise and well-
organized requirement statements.
Who are requirements for?
 user:- is someone involved in using a system when it is actually working.
Using does not only mean operating a system;
 Developer:- is someone who is involved in developing a system to satisfy
the user requirements. Developers can be
 systems engineer - someone who specifies and designs a system as a
whole. A programmer is not necessarily a systems engineer;
 system designer - someone who designs a system, not necessarily
software;
 programmer - someone who designs and writes software;
 test engineer - someone who tests a system, including specifying and
designing any test harness that may be necessary.
 requirements engineer:- is someone who helps to formulate the user
requirements through all the stages.
 the requirements engineer is not necessarily a developer.
 Requirements engineer helps to capture user requirements from users.
 Why requirements?
 What are the advantages of a complete set of documented requirements?
 Ensures the user (not the developer) drives system functionalities
 Helps avoiding confusion and arguments
 Helps minimizing the changes
 Changes in requirements are expensive. Changing the requirements costs:
 3 x as much during the design phase
 5-10 x as much during implementation
 10-100 x as much after release [Code Complete, p30]
 2/3 of finished system errors are requirements and design errors [RG]
 A careful requirements process doesn’t mean there will be no changes later
 Average project experiences about 25% changes in the requirements
 This accounts for 70-80% if the rework
 Important to plan for requirements changes
 The case of critical applications
 Reasons for project failure
 the ultimate causes for software projects failure is not getting requirements
right.
 Even if projects do not actually fail, lack of control is felt as budgets and
timescales expand while functionality is lost.
 Reasons for project failure
― Incomplete requirements 13.1 %
― Didn't involve users 12.4%
― Insufficient resources/schedule 10.6%
― Unrealistic expectations 9.9%
― Lack of managerial support 9.3%
― Changing requirements 8.7%
― Poor planning 8.1%
― Didn't need it any longer 7.4%
 Different levels of abstraction
 User requirements
 Usually the first attempt for the description of the requirements
 Services and constraints of the system
 In natural language or diagrams
 Readable by everybody
 Serve business objectives
 System requirements
 Services and constraints of the system in detail
 Useful for the design and development
 Precise and cover all cases
 Structured presentation
Example
 User requirement: The library system should provide a way to allow a

patron to borrow a book from the library.

 System requirement: The library system should provide a withdraw

interaction that allows a patron to withdraw a book given the copy number
of the book to be withdrawn. The interaction fails if: the book is already
withdrawn, the book is not in the library's collection, the patron has
already withdrawn 5 books, the patron owes more than $5, the book is on
hold by someone else. Otherwise…(To be completed)
RE process inputs and outputs
Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
Requirements engineering processes
 The goal of RE Process is to create & maintain a system requirements
documents.

 Includes 4 High level RE Sub-processes:

 Feasibility study : usefulness to the business

 Elicitation and analysis : discovering requirements;

 Specification: conversion of requirement into some standard form;

 Validation : check the requirements which defines the system that the
customer wants;
The requirements engineering process
Feasibility studies

A feasibility study decides whether or not the proposed system is

worthwhile.
A short focused study that checks
 If the system contributes to organizational objectives;
 If the system can be implemented using current technology, within
given cost and schedule constraints;
 If the system can be integrated with other systems that are already in
place.
Feasibility study implementation
 Feasibility study involves information assessment (what is required), information
collection and report writing.
 Questions for people in the organization for information assessment and collection:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
 Feasibility study report should make a recommendation about the development
to continue or not.
 Requirements elicitation and analysis
 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, engineer involved in
maintenance, domain experts, trade unions, etc. These are called
stakeholders.
Eliciting & understanding stakeholder requirement is difficult due
to the following reasons:
Stakeholders don’t know what they really want except in most general.
Stakeholders express requirements in their own terms.
Different stakeholders may have deferent requirements.
Organizational and political factors may influence the system
requirements.
The requirements change during the analysis process. New stakeholders
may
emerge and the business environment change.
 E&A Process activities

 Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
 Requirements classification and organization
 Group related requirements and organizes them into coherent clusters.
 Prioritization and negotiation
 Prioritizing requirements and finding and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of the spiral.
The requirements elicitation & analysis Process
Requirements discovery
 The process of gathering information about the proposed and existing systems and
distilling the user and system requirements from this information.
 Sources of information include documentation, system stakeholders and the
specifications of similar systems.
 Approaches & Techniques of requirements discovery are:
 Viewpoints(approach)
 Interviewing
 Scenario
 Questionnaires
 ethnography
Requirements validation
 Concerned with demonstrating that the requirements define the system that the
customer really wants.
 Requirement can be checked against following condition;
 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 Requirements error costs are high so validation is very important
 Fixing a requirements error after delivery may cost up to 100 times the cost of
fixing an implementation error.
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check requirements.
 Test-case generation
 Developing tests for requirements to check testability.
 If test is difficult or impossible to design for the requirement means it is difficult
to implement that requirement
 Requirements reviews
 Regular reviews should be held while the requirements definition is being
formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve problems at
an early stage.
Requirements checking
 Validity: Does the system provide the functions which best
support the customer’s needs?
 Consistency: Are there any requirements conflicts?
 Completeness: Are all functions required by the customer
included?
 Realism: Can the requirements be implemented given available
budget and technology
 Verifiability: Can the requirements be checked?
Review checks
Verifiability: Is the requirement realistically
testable?
Comprehensibility: Is the requirement properly
understood?
Traceability: Is the origin of the requirement
clearly stated?
Adaptability: Can the requirement be changed
without a large impact on other requirements?
Requirements management
 Requirements management is the process of managing changing requirements
during the requirements engineering process and system development.
 Requirements are inevitably incomplete and inconsistent
 New requirements emerge during the process as business needs change and a
better understanding of the system is developed;
 Different viewpoints have different requirements and these are often
contradictory.
 Requirements change

The priority of requirements from different

viewpoints changes during the development
process.
System customers may specify requirements from a
business perspective that conflict with end-user
requirements.
The business and technical environment of the
system changes during its development.
 The challenge of writing better requirements
 The challenge in writing requirements is mainly to communicate reliably between
groups of people who may never meet, and who have quite different viewpoints.
 Some crossovers
o Gulf between development and marketing in product companies
o Gulf between users and developers
 The requirements writing process
o The requirements writing process within the system life cycle
Cont…
 Identify the stakeholders
o Try to find the person or people to talk to first.
o Then identify names and roles involved in the system.
o Arrange to meet those people with roles , and repeat the identification
process until you have a complete list of stakeholders.
 Gather the requirements
o After having an accurate list of stakeholders, requirements gathering can be
made using
• interviews
• Workshops
• prototypes
• other techniques for working directly with users
• Or you can scan documentary sources to locate possible requirements
cont…
 Organize the requirements
o Requirements as gathered are invariably incomplete. The might contain
mistakes, design choices, and ambiguities.
o Decisions need to be made; context and organization need to be provided.
o You can begin by structuring the requirements into a hierarchy- scenarios.
 Check the requirements
o Formal reviews are immensely important in improving the quality of
requirements, but they are time-consuming.
o informal meetings and discussions can get much of the checking done before a
review.
 Review and baseline the requirements
 working closely with users makes eases the review process.
Requirements classes
Enduring requirements. Stable requirements
derived from the core activity of the customer
organization. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain
models
Volatile requirements. Requirements which
change during development or when the system is
in use. In a hospital, requirements derived from
health-care policy
 END

Q&A