Software Requirement Engineering
Types of Requirements
Types of Requirements
• What kinds of types are there in the
requirements and what are they called in each?
• What is the meaning of each requirement type to
the software product and what the differences
are among them?
2
Level and Types of Requirements
What-example: Gas Pump
• Business Requirements – allow the customer to pay
for gas at the pump
• User Requirements
UR 1: Swipe credit or debit card
UR 2: Enter a security PIN number
UR 3: Request a receipt at the pump
• Functional Requirements for UR 1
– Prompt the customer to put the card into the reader
– Detect that the card has been swiped
– Determine if the card was incorrectly read and prompt the
customer to swipe the card again
– Parse the information from the magnetic strip on the card
• Business Rules
– The specific policies, standards, practices,
regulations that define how users do business
– Software product must adhere to these rules in order
to function appropriately within the user’s domain
• User-level Quality Attributes
– Nonfunctional characteristics that define the software
product’s quality such as reliability, availability,
security, safety, maintainability, portability, usability
etc.
– May translate into product-level functional
requirements for the software that specify what
functionality must exist to meet the nonfunctional
attribute
• Ex) an ease of learning requirement might translate into the
functional requirement of having the system display pop-up
help when the user hovers the cursor over an icon
• User-level Quality Attributes
– A quality attribute may also translate into product-
level nonfunctional requirements that specify the
characteristics the software must process in order to
meet that attribute
• Ex) an ease-of-use requirement might translate into
nonfunctional requirements for response time to user
commands or report requests
• External interface Requirements
– Define the requirements for the information flow across
shared interfaces to hardware, users, and other
software applications outside the boundaries of the
software product being developed
• Constraints
– Define any restrictions imposed on the choices that the
supplier can make when designing and developing the
software
• Ex) the completed software use no more than 50% of
available system memory or disk space in order to ensure the
ability for future enhancement
• Data Requirements
– Define the specific data items or data structures that
must be included as part of the software product
• Ex) a payroll system would have requirements for current
and year-to-date payroll data
Requirements Types
• Hardware requirements:
– Performance requirements
– Constraints
• Interface requirements
• Specialty engineering requirements
• Environmental requirements
• Software requirements:
– Functional requirements - an action that a system
must be able to perform
– Nonfunctional requirements - system properties, such as
reliability and safety (“ilities and specialty engineering
requirements”)
8
Another view of requirements types
• The requirements are mutually consistent;
• The requirements are prioritized (there is never enough time and
money to do everything).
9
Total requirements
taxonomy
development requirements,
design-to requirements
product requirements, build-
to requirements
• Development or
Performance specifications -
design and qualification
• Product or Detail
Specifications - acceptance
10
Another view of Requirements
• Electronic Industries Association (EIA) Standard
632, Section 4, (“Requirements”)
• IEEE Standard 12207, Section 5.3.2 (“System
Requirements Analysis”) and Section 5.3.4
(“Software Requirements Analysis”)
• Zachman Framework (ZF)
• CMMI categories of customer, product, and
product component requirements
– Compatible with the ZF
– Treat requirements analysis as a continuing progression from
customer needs and expectations to system specifications.
– The progression is useful in understanding what an RA does.
11
An RA’s View of Requirements Types
• Customer needs and expectations are:
– Business requirements;
– User requirements;
– Product requirements;
– Environmental requirements;
– Unknowable requirements.
• Requirements analyzed and described in different ways are:
– High-level (or system-level) requirements;
– Functional requirements (what the system must do);
– Nonfunctional requirements: System properties (e.g., safety); The “ilities/specialty engineering
requirements.”
– Derived requirements and design constraints;
– Performance requirements (e.g., how fast?);
– Interface requirements (relationships between system elements);
• The system requirements are allocated into
– Subsystems (logical groupings of functions)
– Components of the system (hardware, software, training, documentation).
• Checks are done to ensure the system does what it is supposed to do, incorporating:
– Verified requirements;
– Validated requirements;
– Qualification requirements.
12
Business Requirements
• The reason for developing systems and software in the first place.
• The essential activities of an enterprise.
• Derived from business goals (the objectives of the enterprise
or organization).
• Business scenarios may be used as a technique for understanding.
• A key factor in the success of a system is the extent to which
the system supports the business requirements and facilitates an
organization in achieving them.
• The reason for being the systems and software
• Businesses exist to make money for stockholders; organizations exist to
meet the needs of their members.
• It’s vital that we consider our systems and software development
work totally within the context of business and organizational
objectives
13
Stated Requirements vs Real Requirements
• Stated requirements - provided by a customer at the
beginning of a system or software development effort.
• Real requirements - reflect the verified needs for
a particular system or capability.
– Some real requirements may be omitted in the customer and
users’ stated requirements
– Identifying omitted requirements is a key task of the RA
14
User Requirements
• Users are the individuals or groups that use
a system or software in its environment.
• User requirements are their verified needs for
the system or software.
15
High-Level or System-Level Requirements
• To enable comprehending a needed system, we refer to
the high-level or system-level requirements.
• This term relates to those requirements that are foremost
in importance, capture the vision of the customer, enable
defining the scope of the system, and allow estimating the
cost and schedule required to build the system.
• It’s recommended that a workable number of
requirements (on the order of 50 to 200) system-level
requirements be identified for a large system.
• A set of business drivers that may be considered high-
level customer requirements, which often are not
expressed.
16
Business Rules
• Business rules provide the basis for creating
the functional requirements as follows:
– The policies, conditions, and constraints of the
business activities supported by the system;
– The decision processes, guidelines, and controls
behind the functional requirements (e.g., procedures);
– Definitions used by the business;
– Relationships and workflows in the business;
– Knowledge needed to perform actions.
17
Functional Requirements
• An important category of the real requirements.
• Describe what the system or software must do.
• Sometimes called behavioral or operational requirements
– They specify the inputs (stimuli) to the system, the outputs
(responses) from the system, and behavioral relationships
between them.
• The document used to communicate the requirements to
customers, system, and software engineers is referred to
as a functional document (FD) or specification.
– This refers to a comprehensive collection of the characteristics of
a system and the capabilities it will make available to the users.
– It provides a detailed analysis of the data the system will be
expected to manipulate.
– It may include a detailed definition of the user interfaces of
the system.
18
Examples of functional requirements
Eg1) The user shall be able to search either all of the
initial set of databases or select a subset from it.
Eg2) The system shall provide appropriate viewers
for the user to read documents in the document
store.
Eg3) Every order shall be allocated a unique
identifier (ORDER_ID) which the user shall be able
to copy to the account’s permanent storage area.
Non-functional requirements
• 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 CASE system, programming language or
development method.
• May be more critical than functional
requirements. If these are not met, the system is
useless.
Classifications of Non-functional Requirement
• Product requirements
– Requirements which specify that the delivered product must behave in
a particular way e.g. execution speed, reliability, etc.
– Ex) The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
• Organisational requirements
– Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements,
etc.
– Ex) The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo-SP-STAN-95.
• External requirements
– Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative
requirements, etc.
– Ex) The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the system.
Non-functional requirement types
Non-functional
requirements
Product
requirements Organizational External
requirements requirements
Efficiency
requirements Reliability Portability Interoperability Ethical
requirements requirements requirements requirements
Usability Delivery Implementatio Standard Legislative
requirements requirements n requirements requirements requirements
Performance Space Privacy Safety
requirements requirements requirements requirements
Derived Requirements
• A derived requirement is one that is further
refined from a higher-level requirement or a
requirement that results from choosing a specific
implementation or system element.
23
Design Requirements and Design
Constraints
Design requirements/constraints appear right at the beginning of the
system formulation
• New systems are often installed in environments that already have
other systems. The other systems usually constrain the design of
the new system.
– For example, a requirement (design constraint) may be that the system to be
developed must obtain its information from an existing database.
• For large systems, some architectural design is often necessary
to identify subsystems and relationships.
– Identifying subsystems means that the requirements engineering process for
each subsystem can go on in parallel.
• For reasons of budget, schedule, or quality, an organization may wish
to reuse some or all existing software systems in the implementation
of a new system.
• If a system has to be approved by an external regulator (e.g., systems
in civil aircraft), it may be necessary to use standard certified design
that has been tested in other systems.
24
Performance Requirements
• One of the most difficult challenges in system
development is defining and meeting the
performance requirements (sometimes referred
to as dependability requirements).
– The performance requirements define how well the
functional requirements must perform.
– Dependability requirements correspond to system-
level needs for availability, security, performance,
reliability, and safety
25
The “ilities” and Specialty Engineering
Requirements
• References to the “ilities” of a system,
sometimes called quality attributes, such as the
following:
– Designability; Efficiency; Human engineering;
Modifiability; Portability; Reliability; Testability;
Understandability; Capacity; Degradation of service;
Maintainability; Memory size; Timing constraints;
Modifiability; Usability.
• These are the nonfunctional or nonbehavioral
requirements of a system or the software.
• Non-functional requirements may be very difficult
to state precisely and imprecise requirements
may be difficult to verify.
26
Goals and requirements
• Goal
– A general intention of the user such as ease of use.
– Ex) The system should be easy to use by experienced
controllers and should be organised in such a way that user
errors are minimised.
• Verifiable non-functional requirement
– A statement using some measure that can be objectively tested.
– Ex) Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this training,
the average number of errors made by experienced users shall
not exceed two per day.
• Goals are helpful to developers as they convey the
intentions of the system users.
Requirements measures
Property Measure
Processed transactions/second
Speed User/Event response time
Screen refresh time
M Bytes
Size Number of ROM chips
Training time
Ease of use Number of help frames
Mean time to failure
Probability of unavailability
Reliability Rate of failure occurrence
Availability
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Portability Number of target systems
Requirements interaction
• Conflicts between different non-functional
requirements are common in complex
systems.
• Spacecraft system
– To minimise weight, the number of separate chips in
the system should be minimised.
– To minimise power consumption, lower power
chips should be used.
– However, using low power chips may mean that
more chips have to be used. Which is the most
critical requirement?
Domain requirements
• Derived from the application domain and
describe system characteristics and features that
reflect the domain.
• Domain requirements be new functional
requirements, constraints on existing
requirements or define specific computations.
• If domain requirements are not satisfied,
the system may be unworkable.
Library system domain requirements
• There shall be a standard user interface to all
databases which shall be based on the Z39.50
standard.
• Because of copyright restrictions, some documents
must be deleted immediately on arrival. Depending
on the user’s requirements, these documents will
either be printed locally on the system server for
manually forwarding to the user or routed to a
network printer.
Domain requirements problems
• Understandability
– Requirements are expressed in the language of
the application domain;
– This is often not understood by software engineers
developing the system.
• Implicitness
– Domain specialists understand the area so well that they
do not think of making the domain requirements explicit.
Requirements readers
Client managers
User Requirements System end-users
Client engineers
Contractor managers
System architects
System end-users
System Requirements
Client engineers
System architects
System developers
Client engineers
Requirements Specification System architects
System developers
The Criteria of a Good Requirement
Criteria Descriptions
Necessary If the system can meet prioritized real needs without the requirement, it is not necessary
Feasible The requirement is doable and can be accomplished within available cost and schedule
Correct The facts related to the requirement are accurate and it is technically and legally possible
Concise The requirement is stated simply
Unambiguous The requirement can be interpreted in only one way
Complete All conditions under which the requirement applies are stated, and the requirement expresses a whole
idea or statement
Consistent The requirement is not in conflict with other requirements
Verifiable Implementation of the requirement in the system can be proved
Traceable The requirement can be traced to its source, and it can be tracked throughout the system (e.g., to the
design, code, test, and documentation)
Allocated The requirement is assigned to a component of the designed system.
Design independent The requirement does not pose a specific implementation solution
Non-redundant The requirement is not a duplicate requirement
Stated using a The requirement is stated as an imperative using the word shall
standard construct
Associated with a Each requirement has a unique identifying number
unique identifier
Devoid of escape Requirements do not use if, when, but, except, unless, and although and do not include speculative or
Clauses general terms such as usually, generally, often, normally, and typically
