Lecture 5

Software Requirements

1
What is requirement
A requirement is a singular documented physical or
functional need that a particular design, product or
process aims to satisfy.

It may range from a high-level abstract statement of a

service or of a system constraint to a detailed
mathematical functional specification.

2
Requirement Engineering
Requirements engineering refers to the process of
defining, specifying, documenting and maintaining
requirements in the engineering design process. It is a
common role in systems engineering and software
engineering.

3
Requirements Engineering Process
1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Requirements Management

4
Inception
◼ Ask a set of questions that establish …
◼ basic understanding of the problem

◼ the people who want a solution

◼ the nature of the solution that is desired, and

◼ the effectiveness of preliminary communication and collaboration

between the customer and the developer
◼ Identify stakeholders
◼ “who else do you think I should talk to?”
◼ Recognize multiple points of view
◼ Work toward collaboration
◼ The first questions
◼ Who is behind the request for this work?
◼ Who will use the solution?
◼ What will be the economic benefit of a successful solution
◼ Is there another source for the solution that you need?

5
Eliciting
Eliciting - Elicit requirements from all stakeholders
◼ Meetings are conducted and attended by both software
engineers and customers.
◼ Rules for preparation and participation are established
◼ an agenda is suggested
◼ a "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
◼ the goal is
◼ to identify the problem
◼ propose elements of the solution
◼ negotiate different approaches, and
◼ specify a preliminary set of solution requirements

6
Elaboration
Elaboration - create an analysis model that identifies data, function
and behavioral requirements

◼ Analysis is performed using analysis model

◼ Usecase diagram

◼ Activity diagram

◼ Class diagram

◼ State diagram

◼ Dataflow diagram

◼ …..

7
Negotiating
Negotiation - agree on a deliverable system that is realistic for
developers and customers
◼ Identify the key stakeholders
◼ These are the people who will be involved in the
negotiation
◼ Determine each of the stakeholders “win conditions”
◼ Win conditions are not always obvious
◼ Negotiate
◼ Work toward a set of requirements that lead to “win-win”

8
Specification
◼ Specification—can be any one (or more) of the following:
◼ A written document

◼ A set of models

◼ A formal mathematical

◼ A collection of user scenarios (use-cases)

◼ A prototype

9
Validation- I
◼ Errors: errors in content or interpretation

◼ Clarification: areas where clarification may be required

◼ Consistent: Is each requirement consistent with the overall objective for the
system/product?

◼ Unambiguous: Is each requirement bounded and unambiguous?

◼ Conflict: Do any requirements conflict with other requirements?

◼ Achievable: conflicting or unrealistic (unachievable) requirements? Is each

requirement achievable in the technical environment that will house the system or
product?

◼ Testable: Is each requirement testable, once implemented?

◼ Completeness: missing information? Does the requirements model properly reflect

the information, function and behavior of the system to be built.

10
Validation- II
◼ Patterns: Have requirements patterns been used to simplify the requirements
model. Have all patterns been properly validated? Are all patterns consistent with
customer requirements?

◼ Proper Abstraction: Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of technical detail that
is inappropriate at this stage?

◼ Extra Features: Is the requirement really necessary or does it represent an add-

on feature that may not be essential to the objective of the system?

◼ Attribution: Does each requirement have attribution? That is, is a source

(generally, a specific individual) noted for each requirement?

11
Requirement Management
◼ Requirements management - is the process of documenting,
analyzing, tracing, prioritizing and agreeing on requirements and
then controlling change and communicating to relevant
stakeholders and IT Team. It is a continuous process throughout
a project.

12
Requirement Definition
A software requirements definition is an abstract description of the
services which the system should provide and the constraints under
which the system must operate.

There are three types of major problem with requirements definitions

written in natural language :

(1) Lack of clarity

(2) Requirements confusion
(3) Requirements amalgamation

13
Requirement Specification
◼ Requirements specifications add further information to the
requirements definition.
◼ Natural language is often used to write requirements
specifications.
◼ There are various alternatives to the use of natural language
which add structure to the specification and which should
reduce ambiguity.
(1) Structured natural language
(2) Design description language
(3) Requirements specification language
(4) Graphical notations
(5) Mathematical specifications

14
Definition and Specification

15
Types of Requirements
There are two types of requirements
◼ Functional Requirements

◼ Non-Functional Requirements

16
Functional Requirements
◼ Requirements, which are related to functional aspect of
software fall into this category.

◼ They define functions and functionality within and from the

software system.

EXAMPLES
◼ Search option given to user to search from various invoices.

◼ User should be able to mail any report to management.

◼ Users should be able to login into system to access further

features.

17
Non-Functional Requirements
◼ Requirements, which are not related to functional aspect of
software, fall into this category. They are implicit or expected
characteristics of software, which users make assumption of.
◼ Example:
◼ Security
◼ Performance
◼ Cost
◼ Flexibility
◼ Disaster recovery
◼ Accessibility

18
Non-Functional Requirements
Product requirements
◼ Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
◼ Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.
External requirements
◼ Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.

19
Non-Functional Requirements
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

20
Requirement Categorization
Requirements are categorized logically as
◼ Must Have : Software cannot be said operational without them.
◼ Should have : Enhancing the functionality of software.
◼ Could have : Software can still properly function with these
requirements.
◼ Wish list : These requirements do not map to any objectives of
software.

While developing software, ‘Must have’ must be implemented,

‘Should have’ is a matter of debate with stakeholders and
negation, whereas ‘could have’ and ‘wish list’ can be kept for
software updates.

21
User & System Requirements
◼ User requirements talk about the problem domain, the world
of the user. They describe what effects need to be achieved.
These effects are the combined responsibility of the software,
the hardware, and the users.
◼ System requirements talk about the solution domain, the
world of the software logic. They describe what the software
must do (as opposed to the effects in the user's world that this
may or may not achieve).

22
User & System Requirements Example
For instance for a bookkeeping software,

◼ The user requirement is to compute the correct revenue.

◼ The system requirement is only to compute the correct

sum of the partial revenues entered by the user.
If the user enters incorrect partial revenues the software is not
required to magically correct them: The output will be the correct
sum of the inputs, but not the correct overall revenue.

23
User & System Requirements Example
User Requirement:
The MHC-PMS shall generate monthly management reports
showing the cost of drugs prescribed by each clinic during that
month.
System Requirements:
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

24
User Interface Requirements
How system should look like.
UI is an important part of any software or hardware or hybrid
system.
A software is widely accepted if it is -
◼ easy to operate.
◼ quick in response.
◼ effectively handling operational errors.
◼ providing simple yet consistent user interface.

25
Software Requirements Specification
A software requirements specification (SRS) is a description
of a software system to be developed. It lays out functional
and non-functional requirements, and may include a set of
use cases that describe user interactions that the software
must provide.

26