Chapter 3– Requirements

Engineering
Prepared by Brook A

Chapter 3 Requirements engineering 1

 Objectives
• To introduce the concepts of user and system
requirements
• To describe functional and non-functional
requirements
• To explain two techniques for describing system
requirements
• To explain how software requirements may be
organised in a requirements document
• To discuss the role of requirements management in
support of other requirements engineering processes
RE - Software Engineering 2
 Requirements Engineering
• Requirements for a software system set out what the
system should do and define constraints on its
operation and implementation.
• A condition or capability that must be possessed by a system
(IEEE)
• The goal of this stage of the software engineering
process is to help create and maintain a SRS( software
requirements specification).
• The software requirements document is the official
statement of what is required of the system developers.
• Should include both a definition of user requirements
and a specification of the system requirements.
Software Engineering 3
 The software requirements document
• The process of writing down the user and system requirements
in a requirements document.
• User requirements
– Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers.
– User requirements have to be understandable by end-users and
customers who do not have a technical background
• 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
– may include more technical information.

Chapter 3 Requirements engineering 4

Users of requirement document

Chapter 3 Requirements engineering 5

 SRS cont..
• It is NOT a design document. As far as possible,
it should set of WHAT the system should do
rather than HOW it should do it.
• Good SRS reduces the development cost
–SRS errors are expensive to fix later
–Req. changes can cost a lot (up to 40%)
–Good SRS can minimize changes and errors
–Substantial savings; extra effort spent during req.
saves multiple times that effort
–RE Determines the success of the mission.
Chapter 3 Requirements engineering 6
Institute of Electrical and Electronic Engineers
(IEEE) standard for SRS

Chapter 3 Requirements engineering 7

 SRS content
• Introduction: This should describe the need for the
system. It should briefly describe the system’s
functions and explain how it will work with other
systems. It should also describe how the system fits
into the overall business or strategic objectives of the
organization commissioning the software.
• Justification: short description of business need.
• Glossary: This should define the technical terms used
in the document. You should not make assumptions
about the experience or expertise of the reader.
Chapter 3 Requirements engineering 8
 Project Scope Boundary

• What are the boundaries of the project?

• Project Scope describes all the work that needs to be done in
creating deliverables of the project.
• it will have a list of included functions and if necessary It will
have a list of excluded functions.
• Ideally, you need to write it in such a way that your clients
understand it.
• Any deliverables and any work that is not stated in the Project
Scope Statement is out of the current project.
• However, it should not be a detailed contract, as well.
• Problem of scope: The boundary of the system is ill-defined or
unnecessary details are provided.

Chapter 3 Requirements engineering 9

 SRS content, cont
• User characteristic: This section explain about the
users of the system and how they use the system.
• Example for online shopping. Customers and admin.
– Customers are using for viewing and buying the products.
– Customer can also write feedbacks for products and
services
– Administrators can add, edit & delete products, and
provide services to the customer.
– Administrator can see the daily sell; Can also see the
feedback given by the customer.

Chapter 3 Requirements engineering 10

 SRS content, cont..
• Constraints: anything that limits you to deliver the project.
– For example. Budget constraint 20000 birr
– Technology constraint the web should be develop with word press
• Assumptions: Project assumptions are those things you assume to be
true for your project to be successful.
– For example. Resource (people, materials, funds) will be available as
needed.
– The system requires tomcat server,
– A user must have the basic knowledge of English
• System requirements specification: This should describe the
functional and nonfunctional requirements in more detail. If necessary,
further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.

Chapter 3 Requirements engineering 11

 Ways of writing SRS
• Natural language: The requirements are written using
numbered sentences in natural language. Each sentence
should express one requirement.
• Structured natural language: The requirements are
written in natural language on a standard form or
template. Each field provides information about an aspect
of the requirement.
– Example tabular format.
• Graphical notations: Graphical models, supplemented by
text annotations, are used to define the functional
requirements for the system; UML use case and sequence
diagrams are commonly used.
Chapter 3 Requirements engineering 12
Guideline for writing requirement
• Invent a standard format and use it for all
requirements.
• Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
• Use text highlighting to identify key parts of the
requirement.
• Avoid the use of computer jargon.
• Include an explanation (rationale) of why a
requirement is necessary.
Chapter 3 Requirements engineering 13
 Requirements Engineering Processes
• 1. Requirements elicitation;
– What services do the end-users require of the
system?
• 2. Requirements analysis;
– How do we classify, prioritise and negotiate
requirements?
• 3. Requirements validation;
– Does the proposed system do what the users require?
• 4. Requirements management.
– How do we manage the (sometimes inevitable)
changes to the requirements document?

Software Engineering 14
 Example
Patient records system
(Elicitation) 1. Talk to patients, doctors, nurses, receptionists,
managers to find out
Current system practise, legal restrictions DPA, problems with current
system, needs for improvement, security issues, costs
(Elicitation) 2. Develop draft documentation and review what is
most important, what will it cost, what is the timescale, is new
hardware required
(Validation) 3. Send requirements to end users. Present them
with Q&A. Go back to step 1, discuss requirements again
(Management) 4. Have a yearly review of requirements
between all stakeholders. Have a system of reviewing the cost
and feasability of change to system
Software Engineering 15
The Requirements Engineering Process

Requirements
Feasibility
elicitation and
stud y
anal ysis
Requirements
specification

Feasibility Requirements
report validation

System
models

User and system

requirements

Requirements
document

Software Engineering 16
Requirements Engineering
Requirements
specification
System requirements
specification and
modeling

User requirements
specification

Business requirements
specification

System
Feasibility
requirements User
elicitation study
requirements
elicitation
Prototyping

Requirements
elicitation
Reviews Requirements
validation

System requirements
document

Software Engineering 17
 Feasibility Studies
• Feasibility studies: is a short, focused study that should
take place early in the RE process. It should answer three
key questions:
– does the system contribute to the overall objectives of the
organization?
– can the system be implemented within schedule and budget
using current technology? and
– can the system be integrated with other systems that are used?
– Is there a simpler way of doing this (buy in software and
customize)
• If the answer to any of these questions is no, you should
probably not go ahead with the project.
COMP201 - Software Engineering 18
 Types of Feasibility study
• Technological Feasibility
– Carried out to determine whether the company has the capability, in terms
of software, hardware, personnel, and expertise, to handle the completion
of the project .
• Economic Feasibility(cost/benefit analysis)
– Cost analysis: development cost and operation cost
– Time based: This is analysis of the time required to achieve a return on
investment.
• Legal feasibility: checks whether the system conflicts with legal
requirement. data protection acts or, project certificate, license,
copyright etc
• Operational feasibility: how well the proposed system solves the
problem or satisfy the requirement of the client.
– if the system is developed, will it be used? how much easy product will be
to operate and maintenance after deployment.
Chapter 3 Requirements engineering 19
 Stakeholders
• “stakeholder' refers to the people or groups affected by a
software development project.
• Stakeholders exist both within the organization and outside of
it.
• Example - ATM Stakeholders  
– Bank customers
– Representatives of other banks
– Bank managers
– Counter staff
– Database administrators
– Security managers
– Marketing department
– Hardware and software maintenance engineers

COMP201 - Software Engineering 20

 Elicitation and Analysis
• Sometimes called requirements elicitation or
requirements discovery.
• It is process of identifying needs
• 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, etc. These are
called stakeholders.

Software Engineering 21
 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 (Data protection)
• The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.

Software Engineering 22
Basic techniques for eliciting requirements

• Basic techniques for eliciting requirements

• Interviews
• Meetings
• Observation (Ethnography)
• Questionnaires
• Scenarios: real-life examples
• Documentation:charts, manuals, job descriptions, forms,
reports
• And prototyping

Software Engineering 23
 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 are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.
Software Engineering 24
 Ethnography
• In ethnography, a social scientist spends a
considerable amount of 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.
• The problem with ethnography is that it studies
existing practices which may have some historical
basis which is no longer relevant.
Software Engineering 25
 In the real world
• Requirements often come from
– Copying /modifying the requirements of other
systems
– Copying and fixing the requirements of a legacy
system
– Looking at what competitors do and improve on it
• Prototyping
– A lot of requirements are discovered by
prototyping, so the initial requirements are often
very thin
Software Engineering 26
Functional and non functional requirement

• Functional requirements are statements of the services that

the system must provide or; in simple terms it describes
what the SW has to do.
• Non-functional requirements often constrain the system
being developed and the development process being used.
• Non-functional requirements define system behaviour,
features, and general characteristics that affect the user
experience; requirement like availability, reliability,
testability, security, speed…
• They often relate to the emergent properties of the system
and therefore apply to the system as a whole.

Chapter 3 Requirements engineering 27

 Example functional requirement for online
shopping
• A user shall be able to view the categories of items on home
page.
• The website shall provide facility to login into the system.
• The website shall provide registration form for the customers.
• A user shall be able to add items to the cart(temporary storage).
• A user shall be able to search specific item/ category name
• A user shall be able to delete the items in the cart
• A user shall be able to place order of the item.
• The website shall store feedback of the customer.
• The administrator shall be able to add new items to the list of
shopping items.
• The system shall generate each day sales report.
Chapter 3 Requirements engineering 28
 Non functional requirement of online
shopping. Example.
• User interface and human factor: the website shall provide
attractive user interface with various forms.
• Security Issue: The website shall be protected from unauthorized
access to the system and its stored data;
– Customer detail should be kept confidential.
– Access permissions for the particular system information may only be
changed by the system’s data administrator.
• Availability: The system shall be available 24*7. Downtime within
normal working hours shall not exceed five seconds i
• Robustness: In the event of hardware failure system shall not lose
any data.
• Scalability: The website attendancy limit must be scalable enough to
support 200,000 users at a time.
Chapter 3 Requirements engineering 29
 Scenarios
• Scenarios are real-life examples of how a
system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario
finishes.

Chapter 3 Requirements engineering 30

 Use Cases
• Use-Cases are a scenario based technique in the
Unified Modeling Language (UML) which identify
the actors in an interaction and which describe the
interaction itself.
• A set of use-cases should describe all possible
interactions with the system.
• In a use-case diagram, an actor is a user of the
system (i.e. Something external to the system; can
be human or non-human) acting in a particular
role.
Software Engineering 31
 Use Cases
• Use cases. Usually drawn with ovals, use cases represent
different use scenarios that actors might have with the
system (log in, make a purchase, view items, etc.)
• System boundaries.  Boundaries are outlined by the box
that groups various use cases in a system.
• Actors. These are the figures that depict external users
(people or systems) that interact with the system.
• Associations. Associations are drawn with lines showing
different types of relationships between actors and use
cases.

Software Engineering 32
 ATM machine
• Actors
– Customers
– Bank staff
– ATM service engineer
• Use cases
– Withdraw cash
– Check balance
– Add cash to machine
– Check security video recording
Software Engineering 33
Example - ATM Use Case Diagram

Software Engineering 34
 Include Relations
• If several use cases include, as part of their
functionality, another use case, we have a
special way to show this in a use-case diagram
with an <<include>> relation.
 Include and Extend
• Include
– When the other use case is always part of the main use
case
• Extend
– When the other use case, sometime is needed

Software Engineering 36
 Requirements validation
• Concerned with demonstrating that the
requirements define the system that the
customer really wants.
• 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.

Chapter 3 Requirements engineering 37

 Confidentiality requirements
• Usually two main options
– Encryption (hard security)
– Permissions (soft security)
• Data must be kept secure
– In storage (final or intermediary)
– On the wire or wireless link
– For as long as reasonably possible

Software Engineering 38
 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?
– This reduces the potential for disputes between customers and
contractors and a set of tests should be possible.

Software Engineering 39
 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.

Chapter 3 Requirements engineering 40

 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?

Chapter 3 Requirements engineering 41

 Requirements management
• Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
• New requirements emerge as a system is being
developed and after it has gone into use.
• You need to keep track of individual requirements and
maintain links between dependent requirements so
that you can assess the impact of requirements
changes. You need to establish a formal process for
making change proposals and linking these to system
requirements.
Chapter 3 Requirements engineering 42
 Scenarios
• There are effectively test cases running in a given
situation
• So for example:
– Try and withdraw cash with stolen credit card
– Try and withdraw cash but machine has low cash stock
– Withdraw cash with card number 3456123245677
– Etc.
• Scenarios are very important as they
– Show the developer by example what will happen given
certain conditions
– They can be used as a basis to test the software
– Make things very clear and reduce ambiguity
Software Engineering 43
 Lecture Key Points
• The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification and requirements
management.
• You can use a range of techniques for requirements
elicitation including interviews, scenarios, use-cases
• Systems have multiple stakeholders with different
requirements
• Requirements validation is the process of checking the
requirements for validity, consistency, completeness,
realism and verifiability
• Security for most systems is a core service
Software Engineering 44