SOFTWARE

ENGINEERING
REQUIREMENTS ANALYSIS AND
SPECIFICATION
 Topics to be covered Today
● Software Requirements: Functional and Non-Functional
● User requirements, System requirements
● Software Requirements Document
● Requirement Engineering Process: Feasibility Studies
● Requirements elicitation and analysis, requirements validation
● Requirements management
● Classical analysis: Structured system Analysis
● Petri Nets
● Data Dictionary.
 Requirements engineering
● Requirements Engineering consist of 2 main functions : Understanding
the Requirements + Documenting the Requirements.
● What is Requirement ?
○ It is a feature of the system or a description of something the system
is capable of doing in order to fulfill the system purpose.
○ WHAT to do and not HOW to do it?
● Work Product : RE produces large document written in natural Language
containing a description of WHAT a system will do. - SRS Document
● INPUT to RE: Problem statement prepared by customer - Overview of
the existing system + New or additional functionality to be added.
 Cont..
● Importance : Without well written Requirements
○ Developers will not know what to do?
○ Customers may not be consistent about Requirements.
○ It becomes difficult for the customer to validate/ accept the software
● Types of Requirements
○ Functional and Nonfunctional Requirements.
○ User and System Requirements
○ Interface Specifications
 Cont..
● Stakeholders : It refers to anyone who may have direct or indirect
influence on System Requirements.
○ End-Users who will interact with the system.
○ Any one except the user who will be affected by the software that is
developed.
● Examples of Stakeholders
○ Investors ,Creditors,Employees ,Customers
○ Suppliers ,Government and Taxation Department
○ Community
 Functional and non-
functional requirements
● Software system requirements are often classified as functional requirements or
non-functional requirements:
○ Functional requirements These are statements of services the system
should provide, how the system should react to particular inputs, and how
the system should behave in particular situations.
■ In some cases, the functional requirements may also explicitly state
what the system should not do
○ Non-functional requirements These are constraints on the services or
functions offered by the system.
■ They include timing constraints, constraints on the development
process, and constraints imposed by standards.
■ Non-functional requirements often apply to the system as a whole,
rather than individual system features or services
 Functional requirements
● The functional requirements for a system describe what the system should
do.
● These requirements depend on the type of software being developed, the
expected users of the software, and the general approach taken by the
organization when writing requirements.
● When expressed as user requirements, functional requirements are usually
described in an abstract way that can be understood by system users.
● However, more specific functional system requirements describe the system
functions, its inputs and outputs, exceptions in detail.
● Functional system requirements vary from general requirements covering
what the system should do to very specific requirements reflecting local
ways of working or an organization’s existing systems.
 Cont..
● Examples of functional requirements for the Mentcare system, used to maintain
information about patients receiving treatment for mental health problems:
■ A user shall be able to search the appointments lists for all clinics.
■ The system shall generate each day, for each clinic, a list of patients
who are expected to attend appointments that day.
■ Each staff member using the system shall be uniquely identified by his
or her eight-digit employee number.
● These functional user requirements define specific facilities to be provided by the
system.
● These have been taken from the user requirements document and they show
that functional requirements may be written at different levels of detail
 Cont..
● Imprecision in the requirements specification is the cause of many software
engineering problems.
● It is natural for a system developer to interpret an ambiguous requirement in
a way that simplifies its implementation.
● Often, however, this is not what the customer wants.
● New requirements have to be established and changes made to the system.
● Of course, this delays system delivery and increases costs.
● In principle, the functional requirements specification of a system should be
both complete and consistent.
● Completeness means that all services required by the user should be defined.
● Consistency means that requirements should not have contradictory
definitions.
 Cont..
● In practice, for large, complex systems, it is practically impossible to achieve
requirements consistency and completeness.

● One reason for this is that it is easy to make mistakes and omissions when
writing specifications for complex systems.

● Another reason is that there are many stakeholders in a large system.

● Stakeholders have different— and often inconsistent—needs.

● These inconsistencies may not be obvious when the requirements are first
specified, so inconsistent requirements are included in the specification.
 Cont..
● A functional requirement for an everyday object like a cup would be: “ability
to contain tea or coffee without leaking”.
System
Input Output
Behaviour

● Basically functional requirements can be divided into 4 groups :

● Business requirements: They contain the ultimate goal, such as an order
system, an online catalogue, or a physical product. It can also include things
like approval workflows and authorization levels. Example :

○ a process they must complete

○ a piece of data they need to use for that process
○ a business rule that governs that process and that data
 Cont..
● Administrative functions: They are the routine things the system will do,
such as reporting.
● User requirements: They are what the user of the system can do, such as
place an order or browse the online catalogue.
● System requirements: These are things like software and hardware
specifications, system responses, or system actions.
● User Requirements : 1. The Mentcare System shall generate monthly
management reports showing the cost of drugs prescribed by each clinic during
that month.
● System Requirements:
○ 1.1 On the last working day of each month, a summary of the drugs prescribed,
their cost, and the prescribing clinics shall be generated.
○ 1.2 The system shall automatically generate the report for printing after 17.30
on the last working day of the month.
○ 1.3 A report shall be created for each clinic and shall list the individual drug
names, the total number of prescriptions, the number of doses prescribed, and
the total cost of the prescribed drugs.
○ 1.4 If drugs are available in different dose units (e.g., 10 mg, 20 mg) separate
reports shall be created for each dose unit.
○ 1.5 Access to all cost reports shall be restricted to authorized users listed on a
management access control list
Examples
Player Requirements
Start Screen
●The user shall be able to select Begin Journey to launch the game.
●The user shall be able to type ALT-F4 or click the exit button to exit the game.

Game Scene
●The user shall be able to use the arrow keys to move the player up, down, left, or right.
●The user shall be able to type CTRL or press left mouse-click to attack enemies.
●The user shall be able to advance to the next generated map if they make contact
with the staircase sprite.
●The user shall be transferred to the start screen again if their character dies.

Game Over Scene

●The user shall be able to type ALT-F4 or click the exit button to exit the game.
Thank You !!!
Any Doubts ??
 Non-functional requirements
● Non-functional requirements, as the name suggests, are requirements that are
not directly concerned with the specific services delivered by the system to its
users.
● They may relate to emergent system properties such as reliability, response time,
and store occupancy
● Alternatively, they may define constraints on the system implementation such as
the capabilities of I/O devices or the data representations used in interfaces with
other systems
● Non-functional requirements, such as performance, security, or availability,
usually specify or constrain characteristics of the system as a whole.
● Non-functional requirements are often more critical than individual functional
requirements.
● System users can usually find ways to work around a system function that doesn’t
really meet their needs.
 Cont..
● However, failing to meet a non-functional requirement can mean that the whole
system is unusable.
● For example, if an aircraft system does not meet its reliability requirements, it will
not be certified as safe for operation; if an embedded control system fails to meet
its performance requirements, the control functions will not operate correctly.
● The implementation of these requirements may be diffused throughout the
system. There are two reasons for this:
■ 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 new
system services that are required. In addition, it may also generate
requirements that restrict existing requirements.
Types of Non-functional
requirement
 Cont..
● The non-functional requirements may come from required characteristics of the
software (product requirements), the organization developing the software
(organizational requirements), or from external sources:
● Product requirements These requirements specify or constrain the behavior of
the software. Examples include performance requirements on how fast the
system must execute and how much memory it requires, reliability requirements
that set out the acceptable failure rate, security requirements, and usability
requirements.
● Organizational requirements These requirements are broad system requirements
derived from policies and procedures in the customer’s and developer’s
organization.Examples include operational process requirements that define how
the system will be used, development process requirements that specify the
programming language, the development environment or process standards to be
used, and environmental requirements that specify the operating environment of
the system
 Cont..
● External requirements This broad heading covers all requirements that are
derived from factors external to the system and its development process. These
may include regulatory requirements that set out what must be done for the
system to be approved for use by a regulator, such as a central bank; legislative
requirements that must be followed to ensure that the system operates within
the law; and ethical requirements that ensure that the system will be acceptable
to its users and the general public
● The organizational requirement specifies how users authenticate themselves to
the system.
● You can measure these characteristics when the system is being tested to check
whether or not the system has met its nonfunctional requirements.
Metrics for specifying non-functional requirements