Software Requirement Engineering

Classification of Requirements
&
Documentation Standards
What are Requirements?
Steps of Requirements
Development
• Capture the requirements
• Analyze, distill and record the
requirements
• Model requirements
• Validate the resulting Requirements
Specification
—With the project team for completeness and
understanding
—With the client for accuracy and validity
• Output: Software Requirements
Specification Document
Requirements Types
5
Functional Requirements (WHAT)
Functional requirements
—Statements of services the system should
provide, how the system should react to
particular inputs and how the system should
behave in particular situations.
Statements describing what the system
does
—Functionality of the system
• Statements of services the system should
provide
—Reaction to particular inputs
—Behavior in particular situations
Example of Functional Requirement
{FR1}
Software shall automatically detect the
presence of other computers running the
application that are connected to the network.
7
Functional Requirements Example

University Identification
System:
– {FR1}Users shall authenticate
themselves to the System using their
university account and pre-arranged
password.

– {FR2}Until the user has authenticated

with the System, they shall only be able
to look at lists of available classes and
whether there is still space available in
them.
Non-Functional Requirements NFRs
(How)

Non-functional requirement = system quality

attribute
– For the user: performance, usability, reliability
– For the developer: portability, interoperability,
maintainability
– For the owner: cost, benefit
• Challenge:
— Subjective
— Relative
Write Quantifiable NFRs:
Quantifiable = Testable

• NFRs should be stated in measurable

terms.
• Compare:
—An operator shall not have to wait for the
transaction to complete… (change to
measureable)
—An operator shall not have to wait more than 1s
for a transaction to complete for at least 95% of
the transactions.
Interesting phenomenon: What gets
measured gets done.
Examples of NFRs
1
1 Non-Functional Requirements

• Failure to meet a non-functional system requirement

may make the whole system unusable
— For example, if an aircraft system does not meet reliability
requirements, it will not be certified as ‘safe’
— If a real-time control system fails to meet its performance
requirements, the control functions will not operate
correctly
• Non-functional requirements arise through user
needs,
— because of budget constraints,
— because of organizational policies,
— because of the need of interoperability with other software
and hardware systems, or
— because of external factors such as safety regulations,
privacy legislation, etc.
Design Constraints
Design Constraints

• Design constraints typically originate from one of

three sources:
 Restriction of design options – “Use Oracle DBMS”
 Conditions imposed on the development process
– “Should be compatible with legacy inventory system” or “"The
application must run on both our new and old platforms"
 Regulations and imposed standards - For example, the
development of a medical product in the United States is subject to a
significant number of Food and Drug Administration standards and
regulations or “ISO”
1
4 Inverse Requirements

• They explain what the system shall

not do.
—Many people find it convenient to
describe their needs in this manner
• These requirements indicate the
indecisive nature of customers about
certain aspects of a new software
product
—Example:
– The system shall not use red color in the
user interface, whenever it is asking for
inputs from the end-user
FURPS+ Classification for
requirements other than FR
• Functional
—System-wide functionality which is
architecturally significant
• Non-Functional (NFRs): These requirements can
be grouped in 4 categories
—Usability
– Human factors, help, documentation, etc.
—Reliability
– Frequency of failure, recoverability, availability..
—Performance
– Response time, throughput, capacity…
—Supportability: Supportability is the ability of the software to be
easily modified to accommodate enhancements and repairs
– Maintainability, adaptability, configurability, etc.
FURPS+ Classification Cont.

• + indicates additional constraints such as:

— Design Constraints
– i.e. requiring a relational database
— Interface constraints
– i.e. protocols for interaction with external systems
— Implementation Constraints
– Required standards, platform, implementation language
— Physical constraints
– Shape, size, weight.
 FURPS+ Classification Examples
• "The product will be localized (support multiple human
languages)“. FURPS+ Type?
— “F” architecturally significant functional requirement.

• "The persistence will be handled by a relational database"

FURPS+ Type?
— “+” design constraint.

• "The database will be Oracle 8i" FURPS+ Type?

— “+” implementation constraint.

• "The system will run seven days a week, twenty-four hours

per day" FURPS+ Type?
— “R” reliability requirement.

• "An online help system is required" FURPS+ Type?

— “F” architecturally significant functional requirement.
• Requirements Organization and
Documentation.
—IEEE Std.830
—UP
Requirements Specification
Standards

• IEEE 830-1998 IEEE recommended practice

for software requirements specifications
• Volere Requirements Specification
Template, Edition 13—August 2007 by
James & Suzanne Robertson
Requirements Specification
Standard (Will be practiced in Project)

• Which one to practice?

IEEE 830-1998 IEEE recommended practice

for software requirements specifications
OR
Volere
?
Your choice!
IEEE Std 830-1998

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
IEEE Std 830-1998 (Template A5)

• Section 3.1 External interfaces

• Section 3.2 Functional requirements (system
features)
• Section 3.3 Performance requirements
• Section 3.4 Logical database requirements
• Section 3.5 Design constraints
• Section 3.6 Software system attributes
• Section 3.7 Other requirements
Volere Requirements Specification
Template, Edition 13—August 2007

• Project Drivers
— 1. The Purpose of the Project
— 2. The Client, the Customer, and Other Stakeholders
— 3. Users of the Product
• Project Constraints
— 4. Mandated Constraints
— 5. Naming Conventions and Definitions
— 6. Relevant Facts and Assumptions
• Functional Requirements
— 7. The Scope of the Work
— 8. The Scope of the Product
— 9. Functional and Data Requirements
Volere Requirements Specification
Template, Edition 13—August 2007
• Nonfunctional Requirements
— 10. Look and Feel Requirements
— 11. Usability and Humanity Requirements
— 12. Performance Requirements
— 13. Operational and Environmental Requirements
— 14. Maintainability and Support Requirements
— 15. Security Requirements
— 16. Cultural and Political Requirements
— 17. Legal Requirements
• Project Issues
— 18. Open Issues
— 19. Off-the-Shelf Solutions
— 20. New Problems
— 21. Tasks
— 22. Migration to the New Product
— 23. Risks
— 24. Costs
— 25. User Documentation and Training
— 26. Waiting Room
Use-Case Requirements Artifacts
• Vision
— An executive summary of the project
• Use-Case Model
— A set of typical scenarios of using the system (functional
requirements)
• Supplementary Specification
— Captures and identifies other kinds of requirements such
as non-functional requirements & design constraints.
• Glossary
— Captures terms and definitions; also play the role of a
data dictionary
• Business Rules
— Long-living rules or policies (e.g., tax laws) for this
particular application
UP Main Artifacts

Glossary
Glossary
Vision Document
Vision Document
• The development and management of the Vision
document can play a key role in the success or
failure of a software project, providing the locus
of activity for the many stakeholders, customers,
users, product management team members ,
and marketing staff.
• Often, the executive management of the
company will be involved in the document's
development and review also.
• Keeping the Vision document understandable and
manageable is an important team skill that will
greatly benefit the overall productivity of the
project.
Delta Vision Document
• The Delta Vision document focuses on
only two things: what has changed and
any other information that must be
included for context .
• This latter information is included either
as a reminder to the team of the vision for
the project or because new team
members need the context for
understanding.
Delta Vision Document

= The whole product definition

Supplementary Specification:
content
• Functional requirements not expressed in
use cases
—reports
• Non-functional requirements
—Quality attributes of the system
—Legal, regulatory and documentation
requirements
• Design constraints
• Interfaces
• Business Rules
Organizing Requirements for
Nested Systems
• Develop a product-family
—Vision document showing how the products are
intended to work together
—use cases showing how the users will interact
with various applications running together.
—common software requirements specification
that defines the specific requirements for shared
functionality
—For each product in the family, develop a
Vision document, software requirements specification,
and a use-case model
Requirements Organization for
Nested Systems
Supplementary Specification:
Non-Functional Requirements for Quality

• Usability
—the ease with which the system can be learned
and operated by the intended users. (required
training time, task times for typical tasks,
conformance to usability standards)
• Example:
—The customer will be able to see a large-monitor
Therefore:
– Text should be easily visible from 1 meter.
– Avoid colors associated with common forms of color
blindness.
Supplementary Specification:
Requirements for Quality
• Reliability
—Availability (% of time the system is expected
to be available)
—Allowed Mean time between failures (MTBF),
Mean time to repair (MTTR)
—Definition for defects’ criticality level
—Maximum defect rate allowed per KOLC
• Example (Recoverability)
—If there is failure to use external services
(payment authorizer, accounting system, ...)
try to solve with a local solution (e.g., store
and forward) in order to still complete a sale.
Supplementary Specification:
Requirements for Quality
• Performance
—Average, maximum response time for a
transaction
—number of customers/transactions the system
can accommodate
• Example:
— Buyers want to complete sales processing
very quickly. One bottleneck is external
payment authorization. Our goal:
authorization in less than 1 minute, 90% of
the time.
Supplementary Specification:
Requirements for Quality

• Supportability
— Coding standards
— naming conventions
— Class libraries
—…
• Example:
Adaptability
— Different customers of the NextGen POS have unique
business rule and processing needs while processing
a sale. Therefore, at several defined points in the
scenario (for example, when a new sale is initiated,
when a new line item is added) pluggable business
rule will be enabled.
Supplementary Specification:
Constraints

• Example:
—NextGen leadership insists on a Java
technologies solution, predicting this will
improve long-term porting and
supportability, in addition to ease of
development.
Supplementary Specification:
Interfaces
• Noteworthy Hardware and Interfaces
—Touch screen monitor (this is perceived by
operating systems as a regular monitor, and
the touch gestures as mouse events)
—Barcode laser scanner (these normally attach
to a special keyboard, and the scanned input
is perceived in software as keystrokes)
• Software Interfaces
—For most external collaborating systems (tax
calculator, accounting, inventory, ... ) we need
to be able to plug in varying systems and thus
varying interfaces.
Supplementary Specification:
Business Rules
More on Requirements for Quality:
Exercise

• Which of the following quality attributes:

efficiency, reliability, usability,
maintainability

would be important for the system

computing income taxes, that will be used
by government employees who audit
taxpayers?
 Requirements for Quality: Exercise
• Which attributes of quality efficiency, reliability, usability,
maintainability would be important for the system computing
income taxes, that will be used by government employees who
audit taxpayers?

Answer:
Income tax software is an application domain in which
maintainability will be a big concern since tax
regulations tend to change frequently.
Usability will also be important so the auditors can do
their job efficiently.
Reliability will be of moderate importance (accuracy of
results, however , will be very important) .
Efficiency will be of minimal importance .
Agenda

• Review of the previous lecture

• Requirements Classification
• Requirements Organization and
Documentation
• Quality of RE documents
Desirable Properties of Requirements &
Specifications: IEEE Std.830-1998
 Validating Requirements Artifacts

• Completeness: All possible behavior through the system

are described, including exceptional behavior by the user
or the system
• Correctness: The requirements represent the client’s
needs
• Consistency: There are no functional or nonfunctional
requirements that contradict each other
• Unambiguity: Exactly one system is specified, it is not
possible to interpret the requirements in two or more ways.
• feasability: Requirements can be implemented and
delivered
• Traceability: the ability to find corresponding or related
information in other documents or software
Quality of Requirements:
Correctness

• Each requirement must accurately describe the

functionality to be delivered.
• The reference for correctness is the source of the
requirement, such as an actual customer or a
higher level system requirements specification.
• Only user representatives can determine the
correctness of user requirements.
Quality of Requirements:
Unambiguity

• Unambiguous. The reader of a requirement

statement should be able to draw only one
interpretation of it.
—Natural language is highly prone to ambiguity
— Effective ways to reveal ambiguity include:
– formal inspections of the requirements specifications,
– writing test cases from requirements
– creating user scenarios that illustrate the expected behavior of a
specific portion of the product.
 Quality Requirements Specifications:
Completeness

• Completeness: All possible behavior through the

system are described, including exceptional
behavior by the user or the system
—Graphical analysis models that represent different views of the
requirements can also reveal incompleteness.
—If you know you are lacking certain information, use “TBD”
(“to be determined”) as a standard flag to highlight these gaps.
Quality Requirements Specifications:
Consistency

• Consistent requirements do not conflict with other

software requirements or with higher level (system or
business) requirements.
• Inconsistencies can slip in undetected if you review only
the specific change and not any related requirements.
Quality of Requirements:
Verifiable

• See whether you can devise tests or use other

verification approaches, such as inspection or
formal specification, to determine whether each
requirement is properly implemented in the
product.
• Requirements that are not consistent, feasible, or
unambiguous also are not verifiable.
Quality Requirements Specifications:
Modifiability

• Each requirement be uniquely labeled and expressed

separately from other requirements so you can refer
to it unambiguously.
• Organizing requirements so that related
requirements are grouped together
• Create a table of contents, index, and cross-
reference listing; traceability matrices
Quality Requirements Specifications:
Traceability

• Traceability is the ability to link each software

requirement to its source, which could be a higher-
level system requirement, a use case, or a voice-of-the-
customer statement.
• Traceable requirements are uniquely labeled and are
written in a structured, fine-grained way, as opposed to
large, narrative paragraphs or bullet lists.
Example of a Traceability Matrix

Suppl.
UC 1 UC 2 Req. 1 …
Feature 1 X
Feature 2 X
Feature 3 X
… X
Feature n
Important! Feasibility

• It must be possible to implement each requirement

within the known capabilities and limitations of the
system and its environment.
• To avoid infeasible requirements, have a developer
work with the requirements analysts or marketing
personnel throughout the elicitation process.
Key Points: Role of Requirements
Engineer
Exercise 1

• “The product shall provide status messages at regular

intervals not less than every 60 seconds.”
• Quality Analysis?
Desirable Properties of Requirements &
Specifications: IEEE Std.830-1998
Exercise 1: Improved
Exercise 2

• “The product shall switch between displaying and

hiding non-printing characters instantaneously.”
• Analysis?
Exercise 2: Improved

“The user shall be able to toggle between displaying

and hiding all HTML markup tags in the
document being edited with the activation of a
specific triggering condition.”
Exercise 3
• “Charge numbers should be validated on-line
against the master corporate charge number list, if
possible.”
• Analysis?
Exercise 3: Improved

“The system shall validate the charge number

entered against the online master corporate charge
number list.
If the charge number is not found on the list, an error
message shall be displayed and the order shall not
be accepted.”
Key Points
• Goals of managing and documenting
requirements in SE:
—To fix requirements errors in RE phase
—To ensure that the RE documents describe
THE product the, customer really wants
—To ensure the RE documents are correctly
understood by the customer and the
developers
Root Causes of Requirements
management challenges

• Lack of User Input

• Incomplete requirements &
specifications
• Changing requirements and
specifications
RE IQ Question

• Why developers often fail to write &

manage requirements?
“Even if we’re not really sure of the details of what
we want, it’s better to get started with
implementation now because we’re behind the
schedule and in a hurry. We can pin down the
requirements later”.
—Does it sound familiar? …
RE is a Team Work

• RE work requires well-structured and

well-trained software teams
• Requires Team Skills
—to understand user needs
—to manage the scope of the application
—To build systems that meet those needs
Next?

• Analyzing the Problem (Team Skill 1)