UNIT- II

Software Requirements: Functional and non-functional requirements,

User requirements, System requirements, Interface specification, the
software requirements document.

SOFTWARE REQUIREMENTS:
The system requirements are the descriptions that provides
system services and the constraints on its operation. These
requirements reflect the needs of customers for a system that serves a
certain purpose such as placing an order, or finding information. The
process of finding out, analyzing, documenting and checking these
services and constraints is called Requirements Engineering (RE).
If a company wishes to let a contract for a large software
development project, it must define its needs in a sufficiently abstract
way. The requirements must be written so that several contractors can
bid for the contract. Once a contract has been awarded, the contractor
must write a system definition for the client in more detail so that the
client understands and can validate. Both of these documents may be
called the requirements document for the system.
User requirements and system requirements may be defined as
follows:
• User requirements are statements, in a natural language plus
diagrams, of what services the system is expected to provide to system
users and the constraints under which it must operate.
The readers of the user requirements are not usually concerned
with how the system will be implemented and may be managers who
are not interested in the detailed facilities of the system. User
Requirements are objective and testable. For example: Screen A
accepts production information, including Lot, Product Number, and
Date.
• System requirements are more detailed descriptions of the software
system’s functions, services, and operational constraints. The system
requirements document (sometimes called a functional specification)
should define exactly what is to be implemented. It may be part of the
contract between the system buyer and the software developers.
The readers of the system requirements need to know more
precisely what the system will do because they are concerned with how
it will support the business processes.
User Requirement Definition :
• The MHC-PMS (Mental Health Care Patient Management System)
shall generate monthly management reports showing the cost of drugs
prescribed by each clinic during that month.
System Requirements Specification :
• On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
• The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
• 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.
• If drugs are available in different dose units (e.g., 10 mg, 20 mg)
separate reports shall be created for each dose unit.
• Access to all cost reports shall be restricted to authorized users
listed on a management access control list.
FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS :
Software system requirements are often classified as functional
requirements or nonfunctional 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.
Functional requirements are those which are related to the technical
functionality of the system. Functional requirements may involve
calculations, technical details, data manipulation and processing, and
other specific functionality that define what a system is supposed to
accomplish. for example: “Display the name, total size, available
space and format of a flash drive connected to the USB port.” Other
examples are “add customer” and “print invoice”.
• 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 requirement is a requirement that specifies
criteria that can be used to judge the operation of a system in particular
conditions, rather than specific behaviors. A non-functional
requirement defines the quality attribute of a
software system. They represent a set of standards used to judge the
specific operation of a system. For example, attributes such as
performance, maintainability, scalability, security, usability,
compatibility.
A user requirement concerned with security, such as a statement
limiting access to authorized users, may appear to be a nonfunctional
requirement. However, when developed in more detail, this
requirement may generate other requirements that are clearly
functional, such as the need to include user authentication facilities in
the system. This shows that requirements are not independent and
that one requirement often generates or constrains other requirements.
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.
Functional user 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, etc., in detail.
Examples of functional requirements for the MHC-PMS 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.
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.
For example, the first example requirement for the MHC-PMS
states that a user shall be able to search the appointments lists for all
clinics. The rationale for this requirement is that patients with mental
health problems are sometimes confused. They may have an
appointment at one clinic but actually go to a different clinic. If they
have an appointment, they will be recorded as having attended,
irrespective of the clinic.
The medical staff member specifying this may expect ‘search’ to
mean that, given a patient name, the system looks for that name in all
appointments at all clinics. However, this is not explicit in the
requirement. System developers may interpret the requirement in a
different way and may implement a search so that the user has to
choose a clinic then carry out the search. This obviously will involve
more user input and so take longer.
NON-FUNCTIONAL REQUIREMENTS :

System users can usually find ways to work around a system

function that doesn’t really meet their needs. 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 non-functional 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, we 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.
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.
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;
Ethical requirements that ensure that the system will be
acceptable to its users and the general public.

Figure shows metrics that we can use to specify non-functional

system properties. We can measure these characteristics when the
system is being tested to check whether or not the system has met its
non functional requirements.
A number of large organizations, such as the U.S. Department of
Defense and the IEEE, have defined standards for requirements
documents. This standard is most appropriate for systems such as
military command and control systems that have a long lifetime and
are usually developed by a group of organizations.
USER REQUIREMENTS :
When we are writing user requirements, we should not use
software terminology, structured notations or formal notations, or
describe the requirement by describing the system implementation. We
should write user requirements in simple language, with simple
tables and forms and intuitive diagrams.
However, various problems can arise when requirements are written in
natural language sentences in a text document:
• Lack of clarity: It is sometimes difficult to use language in a precise
and unambiguous way without making the document wordy and
difficult to read.
• Requirements confusion: Functional requirements, non-functional
requirements, system goals and design information may not be clearly
distinguished.
• Requirements amalgamation: Several different requirements may
be expressed together as a single requirement.
To minimise misunderstandings when writing user requirements,
follow some simple guidelines:

• Invent a standard format and ensure that all requirement

definitions adhere to that format. Standardising the format makes
omissions less likely and requirements easier to check. We may also
include information on who proposed the requirement (the requirement
source) so that we know whom to consult if the requirement has to be
changed.
• Use language consistently. We should always distinguish between
mandatory and desirable requirements. Mandatory requirements are
requirements that the system must support and are usually written
using 'shall'. Desirable requirements are not essential and are written
using 'should'.
• Use text highlighting (bold, italic or colour) to pick out key parts of
the requirement.
• Avoid, as far as possible, the use of computer terminology.

SYSTEM REQUIREMENTS :
System requirements are expanded versions of the user
requirements that are used by software engineers as the starting
point for the system design. Ideally, the system requirements should
simply describe the external behaviour of the system and its
operational constraints.
Natural language specifications can be confusing and hard to
understand:
• Natural language understanding relies on the specification readers
and writers using the same words for the same concept. This leads to
misunderstandings because of the ambiguity of natural language.
• A natural language requirements specification is over flexible. We
can say the same thing in completely different ways.
• There is no easy way to modularise natural language requirements.
It may be difficult to find all related requirements. To discover the
consequence of a change, we may have to look at every requirement
rather than at just a group of related requirements.
STRUCTURED LANGUAGE SPECIFICATIONS :
Structured natural language is a way of writing system
requirements where the freedom of the requirements writer is limited
and all requirements are written in a standard way. The advantage of
this approach is that it maintains most of the expressiveness and
understandability of natural language but ensures that some degree of
uniformity is imposed on the specification. Structured language
notations limit the terminology and use templates to specify system
requirements.
To use a form-based approach to specifying system requirements, we
must define templates to express the requirements.
Tables are particularly useful when there are a number of
possible alternative situations and we need to describe the actions to be
taken for each of these. Figure 6.13 is a revised description of the
computation of the insulin dose.