Classifications of Software

Requirements
And Writing Excellent
Requirements

1
Types of Requirement
 According to the level of details, requirements can be classified
as:
 User Requirements.
 System Requirements.
 Software Requirements Specification.

These requirements can also be classifies into:

 Functional requirements
 Non-functional requirements (Extra-Functional)
 Domain requirements
 Inverse requirements
 Design and implementation constraint

2
User Requirements
 Statements in natural language plus diagrams of the
services that the systems provides and its operational
constraints.

 Written for customers. (Stakeholder Requests

Document)

 The user requirements for a system should describe

the functional and nonfunctional requirements so that
they are understandable by system users without
detailed technical knowledge.

3
 System Requirements
 A structured document setting out detailed descriptions of
the system services.

 Written as a contract between client and contractor. (SRD:

System Requirements Document)

 System requirements add detail and explain how the user

requirements should be provided by the system.

 Ideally, the system requirements should simply describe the

external behavior of the system and its operational
constraints. They should not be concerned with how the
system should be designed or implemented.

4
Software Requirements Specification

 A detailed software description which can serve

as a basis for a design or implementation.

 Written for developers.

 The software requirements specification (SRS)

represents a complete description of the behavior
of the software to be developed.

5
User and system requirements

6
 Functional Requirements
 Describe functionality or system service, Services the system (or subsystem)
should provide.

 Statements of services the system should provide, how the system should
react to particular inputs, and how the system should behave in particular
situations.
 Express how the system behaves
 Inputs, outputs, and functions it provides to its users (e.g. Calculations,
technical details, data manipulation and processing)
 Captured in use cases

7
Functional Requirements, Cont.,

8
Functional requirements for
the MHC-PMS (examples)
1. A user shall be able to search the appointments lists for
all clinics.
2. The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
that day.
3. Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.

9
Requirements imprecision (ambiguity)
 Problems arise when requirements are not precisely
stated.
 Ambiguous requirements may be interpreted in different
ways by developers and users.
 Consider the term ‘search’ in requirement 1
 User intention – search for a patient name across all
appointments in all clinics;
 Developer interpretation – search for a patient name in an
individual clinic. User chooses clinic then search.

10
Requirements completeness and consistency
 In principle, requirements should be both complete and
consistent.
 Complete
 They should include descriptions of all facilities required.
 Consistent
 There should be no conflicts or contradictions in the descriptions
of the system facilities.
 In practice, it is impossible to produce a complete and
consistent requirements document.

11
Non-Functional Requirements
 Define system properties e.g. reliability,
response time and storage requirements.
 Typically relate to the system as a whole
rather than the individual system features.
 Are often called qualities of a system.
 Other terms: Extra-Functional Requirements,
quality attributes, quality goals, quality of
service requirements and non-behavioral
requirements.
 Sometimes called “ilities” from attributes like
stability, portability.
12
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.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.

13
Nonfunctional Requirements- page 163

 Usability
 Reliability (availability, correctness)
 Performance (efficiency)
 Supportability (flexibility, maintainability, robustness,
testability)
 Safety
 Security (integrity, privacy)
 Others (adaptability, interoperability, portability,
reusability)

14
Non-functional Requirements Classifications
 Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability,
etc.

 Organizational requirements
 Requirements which are a consequence of organizational
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.

15
 Non-Functional requirements classifications:

Non-Functional Requirements

Product requirements External requirements

• Efficiency • Interoperability
• Reliability • Ethics
• Portability Organizational requirements • Legislative
• Usability • Delivery • Privacy
• Performance • Implementation • Safety
• Standards

16
16
17
Examples of nonfunctional requirements in
the MHC-PMS

Product requirement
The MHC-PMS shall be available to all clinics during normal
working hours (Mon–Fri, 0830–17.30). Downtime within normal
working hours shall not exceed five seconds in any one day.

Organizational requirement
Users of the MHC-PMS system shall authenticate themselves
using their health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out
in HStan-03-2006-priv.

18
Goals and requirements
 Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to
verify.
 Goal
 A general intention of the user such as ease of use.
 Verifiable non-functional requirement
 A statement using some measure that can be objectively tested.
 Goals are helpful to developers as they convey the
intentions of the system users.

19
Metrics for specifying nonfunctional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
20
Usability requirements
 The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized. (Goal)
 Medical staff shall be able to use all the system functions
after four hours of training. After this training, the
average number of errors made by experienced users
shall not exceed two per hour of system use. (Testable
non-functional requirement)

21
Nonfunctional Requirements
 Usability – ease of use
 Specify the required training time for a use to become minimally
productive
 Specify measurable task time for typical tasks or transactions
 Time to place a typical order
 Compare usability to another commonly known system
 “The system shall be judged by 90% of the users to be at least as
usable as the existing XYZ system”
 Specify required features of online help systems, tool tips,
context-sensitive help, etc.
 Follow conventions and standards that have been developed for
human-to-machine interface
 IBM’s Common User Access (CUA) standards

22
Usability Requirements
 Usability requirements may include such sub-categories
as:
 human factors,
 aesthetics,
 consistency in the user interface,
 online and context-sensitive help,
 wizards and agents,
 user documentation,
 training materials.

23
Usability Requirements examples
  A typical usability requirement might state:
 The system should allow novice users to install and
operate it with little or no training.
 The end user shall be able to place an order within thirty
seconds.
 The end user shall be able to access any page within
four seconds.

24
Nonfunctional Requirements
 Reliability
 Availability – System must be available X.XXX% between hours
of 7am and midnight.
 Mean time between failures (MTFB) – usually specified in hours
 Mean time to repair (MTTR) – how long system can be out of
operation after a failure (recoverability)
 Accuracy – what precision is required in numerical outputs
 Maximum bugs, or defect rate – bugs/KLOC
 Bugs per type – usually categorized in terms of minor,
significant, and critical

25
Reliability Requirement Examples
 For example:
 The mean time to failure shall be at least four months.

26
Nonfunctional Requirements
 Performance
 Response time for a transaction
 Throughput: transactions per second
 Capacity: number of customers or transactions the system can
handle
 Degradation modes: the acceptable mode of operations when
the system has been degraded
 resource usage (bandwidth, memory, disk, cpu,…)

27
Performance Requirement Example
 For example:
 All Web pages must download within three seconds
during an average load, and five seconds during a peak
load.
 While executing a search, the system must be able to
display 500 search results per page.

28
Nonfunctional Requirements
 Supportability
  refers to the software's ability to be easily modified or
maintained to accommodate typical usage or change scenarios.
 Could stipulate response time of the maintenance group from
simple enhancements, moderate enhancements, and complex
enhancements
 Where a system is known to have future modifications…how
fast these modification can be made
 This could get into design constraints and start to require a
DBMS or programming styles and standards like run-time
binding

29
Supportability Requirement
 Supportability requirements may include:
 testability,
 extensibility,
 adaptability,
 maintainability,
 compatibility,
 configurability,
 serviceability,
 installability,
 or localizability (internationalization).

30
Supportability Requirement Example
 Here are some examples of supportability requirements:
 The system shall allow users to create new workflows
without the need for additional programming.
 The system shall allow the system administrator to
create and populate tax tables for the upcoming tax year.

31
 Nonfunctional Requirements
 Security 
 refers to the ability to prevent and/or forbid access to the system by
unauthorized parties.
 Some examples of security requirements are:
 User authentication shall be via the corporate Single Signon system.
 Only authorized payroll administrators shall be permitted to access employee
pay information.

32
Domain Requirements
 Requirements that come from the application domain of the system
 They do not come from the user needs.
 They describe system characteristics and features of that domain
 They reflect the environment in which the system operates so, when
we talk about an application domain we mean environments such as
train operation, medical records, e-commerce etc.
 They usually include specialized domain terminology or reference to
domain concepts. But sometimes domain-specific terminology can
cause confusion since software engineers often find it difficult to
understand how they are related to other system requirements.

33
Domain requirements
 The system’s operational domain imposes requirements
on the system.
 For example, a train control system has to take into account the
braking characteristics in different weather conditions.
 Domain requirements can be
1. new functional or non-functional requirements,
2. constraints on existing requirements or
3. define specific computations.
 If domain requirements are not satisfied, the system may
be unworkable.

34
Domain Requirements, Cont.,
 For example, the requirements for the insulin pump system that
delivers insulin on demand include the following domain
requirement:
 The system safety shall be assured according to standard IEC 60601-
1:Medical Electrical Equipment – Part 1:General Requirements for
Basic Safety and Essential Performance.
 Example for a library system: There shall be a standard user
interface to all databases which shall be based on the Z39.50
standard.
 This requirement means that the developers must be familiar with
that standard to ensure that they do not violate it. It constrains both
the design of the device and the development process. Other
requirements have to be checked against this standard.

35
Train protection system
 This is a domain requirement for a train protection
system:
 The deceleration of the train shall be computed as:
 Dtrain = Dcontrol + Dgradient

 where Dgradient is 9.81ms2 * compensated gradient/alpha and

where the values of 9.81ms2 /alpha are known for different
types of train.
 It is difficult for a non-specialist to understand the
implications of this and how it interacts with other
requirements.

36
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
 Sometimes they are not explicitly mentioned
 Domain experts may leave information out of a requirement
simply because it is so obvious to them. However, it may not be
obvious to the developers of the system and they may therefore
implement the requirement in the wrong way.
 Domain specialists understand the area so well that they do not
think of making the domain requirements explicit.

37
Inverse Requirements

38
Design and Implementation Constraints

 Restrictions on the design of a system, or the process by which a system

is developed (implementation), that do not affect the external behavior of
the system but that must be fulfilled to meet technical, business, or
contractual obligations.
 They are development guidelines within which the designer must work.
 Can seriously limit design and implementation options.
 Can have impact on human resources.

39
Design and Implementation Constraints,
Cont.,

40
Design Constraints
 Three sources
 Restriction of design options
 Conditions imposed on the development process
 Regulations and imposed standards

41
Restriction of Design Options
 Most requirements allow for more that one design
possibility.
 When requirements do not allow for a choice to be made
(e.g., use Oracle DBMS) the design has been
constrained.
 This reduces design flexibility and development freedom
has been lost.

42
Conditions Imposed on the Development
Process
 Compatibility with existing systems: “The application
must run on both our new and old platforms.”
 Application standards: “Use the class library from
Developer’s Library 99-724 on the corporate IT server.”
 Corporate best practices and standards: “Compatibility
with the legacy database must be maintained.”

43
Regulations and Imposed Standards

 Constraints may be imposed by government regulations:

 Food and Drug Administration (FDA)
 Federal Communications Commission (FCC)
 Department of Defense (DOD)
 International Organization for Standardization (ISO)
 Underwriters Laboratory (UL)
 International standards such as the German Industrial
Standard (DIN)
 It is usually sufficient to include design constraints by
reference but be specific.

44
Handling Design Constraints
 Distinguish them from other requirements.
 Include all design constraints in a special section of your
requirements document.
 Identify the source of each design constraint.
 Document the rationale for each design constraint.

45
Are Design Constraints True Requirements?
 Although it can be argued that design constraints are not
true requirements, they are necessary to satisfy the
obligations of development.
 It is probably best to treat them in the same way as other
requirements.
 attempt to have as few design constraints as possible.

46
Identifying Other Requirements
 Physical artifacts (CDs and so on) that are deliverables
of the system. (A physical requirement specifies a
physical characteristic that a system must possess; for
example, material, shape, size, and weight.)
 Target system configuration and preparation
requirements.
 Support or training requirements.
 Internationalization and localization requirements.

47
Writing Excellent Requirements- page 6
 Good requirements should have the following
characteristics:

48
Unambiguous
 There should be only one way to interpret the
requirement. Sometimes ambiguity is introduced by
undefined acronyms:
 REQ1 The system shall be implemented using ASP.
 Does ASP mean Active Server Pages or Application
Service Provider?
 To fix this, we can mention a full name and provide an
acronym in parentheses:
 REQ1 The system shall be implemented using Active
Server Pages (ASP).

49
Unambiguous, Cont.,
 REQ1 The system shall not accept passwords longer
than 15 characters.
 It is not clear what the system is supposed to do:

• The system shall not let the user enter more than 15
characters.
• The system shall truncate the entered string to 15
characters.
• The system shall display an error message if the user
enters more than 15 characters

50
Unambiguous, Cont.,
 The corrected requirement reflects the clarification:
 REQ1 The system shall not accept passwords longer
than 15 characters. If the user enters more than 15
characters while choosing the password, an error
message shall ask the user to correct it.

51
Unambiguous, Cont.,
 Some ambiguity may be introduced through the
placement of a certain word:
 REQ1 On the “Stored Flight” screen, the user can only
view one record.
 Does this mean that the user can “only view,” not delete
or update, or does it mean that the user can view only
one record, not two or three?
 One way to fix the problem is to rewrite the requirement
from the system’s point of view:
 REQ1 On the “Stored Flight” screen, the system shall
display only one flight.

52
Testable (Verifiable)
 Testers should be able to verify whether the requirement is
implemented correctly.
 The test should either pass or fail.
 To be testable, requirements should be clear, precise, and
unambiguous.
 Some words can make a requirement untestable [LUD05]:

• Some adjectives: robust, safe, accurate, effective, efficient,

expandable, flexible, maintainable, reliable, user-friendly, adequate
• Some adverbs and adverbial phrases: quickly, safely, in a timely
manner
• Nonspecific words or acronyms: etc., and/or, TBD

53
Testable, Cont.,
 Such a requirement might look something like this:
 REQ1 The search facility should allow the user to find a
reservation based on Last Name, Date, etc.
 In this requirement, all search criteria should be explicitly
listed.
 The designer and developer cannot guess what the user
means by “etc.”

54
Testable, Cont.,
 Other problems can be introduced by ambiguous words
or phrasing:
• Modifying phrases: as appropriate, as required, if
necessary, shall be considered
• Vague words: manage, handle
• Passive voice: the subject of the sentence receives the
action of the verb rather than performing it

55
Testable, Cont.,
 REQ1 The airport code shall be entered by the user.
 REQ2 The airport code shall be entered
 The first example shows a classic example of passive voice. In
active voice it would read
 “The user shall enter the airport code.”
 As the second example shows, another result of the use of passive
voice is that the agent performing the action is sometimes omitted.
Who should enter this code—the system or the user?

56
Testable, Cont.,
• Indefinite pronouns: few, many, most, much, several, any,
anybody, anything, some, somebody, someone, etc.
REQ1 The system shall resist concurrent usage by many
users.
What number should be considered “many”—10, 100,
1,000?

57
Clear (Concise, Terse, Simple, Precise)
 Requirements should not contain unnecessary verbiage
or information. They should be stated clearly and simply:
 REQ1 Sometimes the user will enter Airport Code, which
the system will understand, but sometimes the closest
city may replace it, so the user does not need to know
what the airport code is, and it will still be understood by
the system.
 This sentence may be replaced by a simpler one:
 REQ1 The system shall identify the airport based on
either an Airport Code or a City Name.

58
Correct
 If a requirement contains facts, these facts should be
true:
 REQ1 Car rental prices shall show all applicable taxes
(including 6% state tax).
 The tax depends on the state, so the provided 6% figure
is incorrect.

59
Understandable
 Requirements should be grammatically correct and
written in a consistent style.
 Standard conventions should be used.
 The word “shall” should be used instead of “will,” “must,”
or “may.”

60
Feasible (Realistic, Possible)
 The requirement should be doable within existing
constraints such as time, money, and available
resources:
 REQ1 The system shall have a natural language
interface that will understand commands given in English
language.
 This requirement may be not feasible within a short span
of development time.

61
Independent
 To understand the requirement, there should not be a
need to know any other requirement:
 REQ1 The list of available flights shall include flight
numbers, departure time, and arrival time for every leg of
a flight.
 REQ2 It should be sorted by price.
 The word “It” in the second sentence refers to the
previous requirement.
 However, if the order of the requirements changes, this
requirement will not be understandable.

62
Atomic
 The requirement should contain a single traceable
element:
 REQ1 The system shall provide the opportunity to book
the flight, purchase a ticket, reserve a hotel room,
reserve a car, and provide information about attractions.
 This requirement combines five atomic requirements,
which makes traceability very difficult.
 Sentences including the words “and” or “but” should be
reviewed to see if they can be broken into atomic
requirements.

63
Necessary
 A requirement is unnecessary if
• None of the stakeholders needs the requirement.
or
• Removing the requirement will not affect the system.
 An example of a requirement that is not needed by a
stakeholder is a requirement that is added by developers
and designers because they assume that users or
customers want it.
 For example, the fact that a developer thinks that users
would like a feature that displays a map of the airport and
he knows how to implement it is not a valid reason to add
this requirement.

64
Necessary, Cont.,
 An example of a requirement that can be removed
because it does not provide any new information might
look like the following:
 REQ1 All requirements specified in the Vision document
shall be implemented and tested.

65
Implementation-free (Abstract)
 Requirements should not contain unnecessary design
and implementation information:
 REQ1 Content information shall be stored in a text file.
 How the information is stored is transparent to the user
and should be the designer’s or architect’s decision.

66
Consistent
 There should not be any conflicts between the
requirements.
 Conflicts may be direct or indirect.
 Direct conflicts occur when, in the same situation, different
behavior is expected:
 REQ1 Dates shall be displayed in the mm/dd/yyyy format.
 REQ2 Dates shall be displayed in the dd/mm/yyyy format.
 Sometimes it is possible to resolve the conflict by
analyzing the conditions under which the requirement
takes place.

67
Consistent , Cont.,
 For example, if REQ1 was submitted by an American
user and REQ2 by a French user, the preceding
requirements may be rewritten as follows:
 REQ1 For users in the U.S., dates shall be displayed in
the mm/dd/yyyy format.
 REQ2 For users in France, dates shall be displayed in
the dd/mm/yyyy format.
 This can eventually lead to the following requirement:
 REQ3 Dates shall be displayed based on the format
defined in the user’s web browser.

68
Consistent , Cont.,
 Another example of a direct conflict can be seen in these two
requirements:
 REQ1 Payment by PayPal shall be available.
 REQ2 Only credit card payments shall be accepted.
 In this case the conflict cannot be resolved by adding
conditions, so one of the requirements should be changed or
removed.
 Indirect conflict occurs when requirements do not describe
the same functionality, but it is not possible to fulfill both
requirements at the same time:
 REQ1 System should have a natural language interface.
 REQ2 System shall be developed in three months.

69
Consistent , Cont.,
 Some requirements do not conflict, but they use
inconsistent terminology:
 REQ1 For outbound and inbound flights, the user shall
be able to compare flight prices from other, nearby
airports.
 REQ2 The outbound and return flights shall be sorted by
the smallest number of stops.
 To describe the same concept, in the first requirement
the term “inbound flights” is used, and in the second
requirement the term “return flights” is used. The usage
should be consistent.

70
Nonredundant
 Each requirement should be expressed only once and
should not overlap with another requirement:
 REQ1 A calendar shall be available to help with entering
the flight date.
 REQ2 The system shall display a pop-up calendar when
entering any date.
 The first requirement (related to only the flight date) is a
subset of the second one (related to any date entered by
the user).

71
Complete
 A requirement should be specified for all conditions that
can occur:
 REQ1 A destination country does not need to be
displayed for flights within the U.S.
 REQ2 For overseas flights, the system shall display a
destination country.
 What about flights to Canada and Mexico? They are
neither “within the U.S.” nor “overseas.”

72
Complete, Cont.,
 All applicable requirements should be specified. This is the toughest
condition to be checked.
 There is really no way to be sure that all the requirements are
captured and that one week before the production date one of the
stakeholders won’t say, “I forgot to mention that I need one more
feature in the application.”
 A good requirement should have more criteria. However, they
usually can be expressed as a combination of the criteria we have
just discussed:
• Modifiable: If it is atomic and nonredundant, it is usually modifiable.
• Traceable: If it is atomic and has a unique ID, it is usually traceable.

73
 More Examples can be found on page 102

74