Requirements Engineering

• The requirements for a system are the descriptions of the services

that a system should provide and the constraints on its operation.
• These requirements reflect the needs of customers for a system that
serves a certain purpose such as controlling a device, placing
an order, or finding information.
• The process of finding out, analyzing, documenting and checking
these services and constraints is called requirements engineering
(RE).
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.
 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
• sometimes called a functional specification
• 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.
• should define exactly what is to be implemented.
Readers of different types of requirements
specification
System stakeholders
• Any person or organization who is affected by the system in some
way and so who has a legitimate interest
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders
 Functional and non-functional requirements

• Software system requirements are often classified as functional or

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.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as timing constraints,
constraints on the development process, standards, etc.
• Often apply to the system as a whole rather than individual features or
services.
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.
• Functional system requirements expand the user requirements and are
written for system developers.
• system requirements describe the system functions, its inputs, processing; how it’s
going to react to a particular input, and what’s the expected output.
• They should describe the system functions, their inputs and outputs, and
exceptions in detail
Non-functional requirements
• These define system properties and constraints 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
IDE, programming language or development method.
• The rate of failure (reliability), what are the languages and tools that
will be used (development), what are rules you need to follow to
ensure the system operates within the law of the organization
(legislative)
• Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.
Non-functional requirements
implementation
• Non-functional requirements may affect the overall architecture of a
system rather than the individual components.
• For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.
• A single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that
define system services that are required.
• It may also generate requirements that restrict existing requirements.
Metrics for specifying nonfunctional
requirements
Requirements elicitation
Requirements elicitation
• The aims of the requirements elicitation process are to understand
the work that stakeholders do and how they might use a new system
to help support that work

• Software engineers work with a range of system stakeholders to find

out about the application domain, the services that the system
should provide, the required system performance, hardware
constraints, other systems, etc.
 Problems of requirements elicitation
•Stakeholders don’t know what they really want except in the
most general terms .
•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 may
change.
A process model of the elicitation and
analysis
Requirements discovery
• The process of gathering information about the required and existing
systems and distilling the user and system requirements from this
information.
• Interaction is with system stakeholders from managers to external
regulators.
• Systems normally have a range of stakeholders.

17
Interviewing
• Formal or informal interviews with stakeholders are part of most RE
processes.
• Types of interview
• Closed interviews based on pre-determined list of questions
• Open interviews where various issues are explored with stakeholders.
• Effective interviewing
• Be open-minded, avoid pre-conceived ideas about the requirements and are
willing to listen to stakeholders.
• Prompt the interviewee to get discussions going using a springboard
question, a requirements proposal, or by working together on a prototype
system.
Read
• Ethnography
• Stories and scenarios
Requirements specification
• Requirements specification is the process of writing down the user and
system requirements in a requirements document
• The software requirements specification (SRS) represents a complete
description of the behavior of the software to be developed.
• The SRS includes:
• A set of use cases that describe all of the interactions that the users will have with the software.
• All of the functional requirements necessary to define the internal workings of the software:
calculations, technical details, data manipulation and processing, and other specific functionality
that shows how the use cases are to be satisfied
• Nonfunctional requirements, which impose constraints on the design or implementation (such as
performance requirements, quality standards or design constraints).
 User requirements
• User requirements are almost always written in natural language
supplemented by appropriate diagrams and tables in the requirements
document
• The user requirements for a system should describe the functional and
nonfunctional requirements so that they are understandable by system users who
don’t have detailed technical knowledge.
• System requirements are expanded versions of the user requirements
that software engineers use as the starting point for the system design
• They add detail and explain how the system should provide the user
requirements.
• They may be used as part of the contract for the implementation of the system
and should therefore be a complete and detailed specification of the whole
system.
Natural language specification
• Natural language has been used to write requirements for software
since the 1950s.
• Requirements are written as natural language sentences
supplemented by diagrams and tables
• It is expressive, intuitive, and universal
• This means that the requirements can be understood by users and customers
• It is also potentially vague and ambiguous, and its interpretation
depends on the background of the reader
Problems with natural language
•Lack of clarity
• Precision is difficult without making the document difficult to read.
•Requirements confusion
• Functional and non-functional requirements tend to be mixed-up.
•Requirements amalgamation
• Several different requirements may be expressed together.
 Structured specifications
• Structured natural language is a way of writing system requirements where
requirements are written in a standard way rather than as free-form text.
• This approach maintains most of the expressiveness and understandability of
natural language but ensures that some uniformity is imposed on the
specification
• Structured language notations use templates to specify system requirements
• The specification may use programming language constructs to show alternatives
and iteration, and may highlight key elements using shading or different fonts.
Standard format is used for specifying
functional requirements
• Definition of the function or entity.
• Description of inputs and where they come from.
• Description of outputs and where they go to.
• Information about the information needed for the computation and
other entities used.
• Description of the action to be taken.
• Pre and post conditions (if appropriate).
• The side effects (if any) of the function.
Use cases
• A use case is a methodology used in system analysis to identify, clarify and
organize system requirements.
• A formal way of representing how a business system interacts with its
environment
• The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goa
• Use cases are a way of describing interactions between users and a system using a
graphical model and structured text.
• Illustrates the activities that are performed by the users of the system
• In their simplest form, a use case identifies the actors involved in an interaction
and names the type of interaction
Use case components
 Use Case Analysis
• What is an Actor?
• A user or outside system that interacts with the system being
designed in order to obtain some value from that interaction
• Use Cases describe scenarios that describe the interaction between
users of the system (the actor) and the system itself.
•Use case diagrams describe what a system does from the
standpoint of an external observer. The emphasis is on what a
system does rather than how.
Actors

•An Actor is outside or external the system.

•It can be a:
• Human
• Peripheral device (hardware)
• External system or subsystem
• Time or time-based event
•Represented by stick figure
Use Cases
• Here is a scenario for a medical clinic.

• A patient calls the clinic to make an appointment for a yearly checkup.

The receptionist finds the nearest empty time slot in the appointment
book and schedules the appointment for that time slot. "

• We want to write a use case for this scenario.

Use Cases
• Step 1 Identify the actors
• As we read the scenario, define those people or systems that
are going to interact with the scenario.

• A patient calls the clinic to make an appointment for a yearly checkup. The receptionist
finds the nearest empty time slot in the appointment book and schedules the appointment
for that time slot. "
 Questions for Identifying People Actors

• Who is interested in the scenario/system?

• Where in the organization is the scenario/system be used?
• Who will benefit from the use of the scenario/system?
• Who will supply the scenario/system with this information,
use this information, and remove this information?
• Does one person play several different roles?
• Do several people play the same role?
Use Cases
• A use case is a summary of scenarios for a single
task or goal.

• An actor is who or what initiates the events

involved in the task of the use case. Actors are
simply roles that people or objects play.

• So as we read our scenario, what or who is the

actor????
Use Cases
• So as we read our scenario, what or who is the actor????

• A patient calls the clinic to make an appointment for a yearly checkup. The receptionist
finds the nearest empty time slot in the appointment book and schedules the
appointment for that time slot. "