CPSC 462 Software Design Requirement Engineering

Requirement Engineering
Evolutionary Requirements
Requirements are capabilities and conditions to which the system and more broadly, the
project must conform. The UP promotes a set of best practices, one of which is managing the
requirements. I believe that the term "contextual practice" makes far more sense because what is
a "best practice" in some situations proves to be a "worst practice" in others (Scott Ambler).

Contextual Best Practice

1) Stakeholders actively participate:
There are two issues that need to be addressed to enable this practice. The first one is
availability of project stakeholders to provide requirements and the second one is their (and
your) willingness to actively model together. If your project stakeholders are unable or
unwilling to participate then that is a clear indication that your project does not have the
internal support that it needs to succeed, therefore you should either address the problem or
cancel your project to minimize your losses. Project stakeholders and developers are involved
with identifying ideas or suggestions, discussing a potential requirement, and then modeling
and potentially documenting it. Project stakeholders are solely responsible for prioritizing
requirements. Developers are responsible for estimating the effort to implement a requirement.
2) Adopt inclusive models
To make it easier for project stakeholders to be actively involved with requirements modeling
and documentation, to reduce the barriers to entry in business parlance, you want to follow the
practice Use the Simplest. Whenever you bring technology into the requirements modeling
effort, you make it harder for your project stakeholders to participate. By keeping it simply, you
encourage participation and thus increase the chances of effective collaboration.
3) Take a breadth-first approach
4) Model storm details just in time (JIT)
5) Treat requirements like a prioritized stack
6) Prefer executable requirements over static documentation
7) Your goal is to implement requirements, not document them
8) Recognize that you have a wide range of stakeholders
9) Create platform independent requirements to a point
10) Smaller is better
11) Question traceability
12) Explain the techniques and more .
Page 1 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

Finding Requirements
Where do requirements come from?
Your project stakeholders,
Developers can SUGGEST requirements, but stakeholders need to adopt the
suggestions.
In fact it is the responsibility of project stakeholders to provide, clarify, specify, and
prioritize requirements
Furthermore, it is the right of project stakeholders that developers invest the time to
identify and understand those requirements
The RUP welcomes any requirements elicitation method that can add value and increase user
participation.

What are Requirements?

Requirement n. (American Heritage Dictionary)
Something that is required; a necessity
Something obligatory; a prerequisite
IEEE Standard 729 defines a requirement as
a condition or capability needed by a user to solve a problem or achieve an objective
a condition or capability that must be met or possessed by a system to satisfy a
contract, standard, specification, or other formally imposed document

Requirement Categories
There are two basic requirement categories used across the industry
Behavioral
A behavioral requirement describes how a user will interact with a system (user interface
issues), how someone will use a system (usage), or how a system fulfills a business function
(business rules). Often referred to as functional requirements.
Non-behavioral
A non-behavioral requirement describes a technical feature of a system, features typically
pertaining to availability, security, performance, interoperability, dependability, and reliability.
Often referred to as "non-functional" requirements due to a bad naming decision made by the
IEEE. (non-functional implies that it doesn't do anything)
The distinction between behavioral and non-behavioral requirements is fuzzy. A performance
requirement (non-behavioral) describing the expected speed of data access is clearly technical in
nature but will also is reflected in the response time of the user interface, which affects usability
Page 2 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

and potential usage. Access control issues, such as who is allowed to access particular
information, is clearly a behavioral requirement although they are generally considered to be a
security issue which falls into the non-behavioral category. Dont allow yourself to get hung up
on issues such as this. The critical thing is to identify and understand a given requirement, if
you miss-categorize the requirement who really cares?

Why Requirements?
Inadequate, incomplete, erroneous, and ambiguous requirements are an ongoing source of
problems in systems development. Unsatisfactory requirements result in missed schedules,
budget overruns, and systems that are unresponsive to customer needs. Unacceptable results
are attributed to the poorly defined and ill-understood processes used to elicit, specify, analyze,
manage, and validate requirements.

Requirement Skills
RE Skills

Interviewing
Group work
Facilitation
Negotiation
Analytical
Problem solving
Presentation
Modeling

RE Knowledge

Domain knowledge
Experience with management and traceability tools
CASE tools
General modeling techniques

Requirement Engineering Tasks

1.
2.
3.
4.

Inception
Elicitation
Elaboration
Negotiation
Page 3 of 8

Sara Hariri

CPSC 462 Software Design Requirement Engineering

5. Specification
6. Validation
7. Requirement Management

Elicitation Problems
Problems of Scope
You have to define the Scope of your system. You need to know all the boundaries and
what exactly the system aims to do. This is something that you come up with your
customer. If you do not define the boundaries of your system, later on you do not know
how to clarify what technical detail is out of scope. That means you will have problem
with your customer wanting more features, which is not within the scope of your
system.
Problems of Understanding
You need to have full understanding of your system. You will get familiar with the
system more in time. At first, you need to ask more questions and try to have more
detail information about the need of your customer. Not specific in details of the system
and therefore not detail and specific requirements will end up in not exact
understanding of the system and will end up with vague requirements which each side
of the project may have their own understandings of it. Your requirements need to be in
detail.
Problems of volatility
Requirements change during the time. You need to find the related requirements to the
one, which has changed, and correct them.

Purpose of Requirements
Serves as the basis of agreement among developers, customers, and users on the job to be done.
Requirements capture customer objectives, expectations, and constraints and ensures the
customers objectives are mutually understood. Serves as a tool to incorporate quality attributes
such as usability, maintainability, reliability. Requirements also provides contractual acceptance
criteria for acceptance testing of the delivered systems; establishes a baseline from which to
control system evolution. Furnishes a sound basis for resource estimation (cost, personnel,
quantity and skills, equipment, and time).

Page 4 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

Define Expectations and Constraints

Define Customer Expectations

Define Project and Company Constraints
Define External Constraints
Identify and Resolve Conflicts

Key Definitions
Requirement: A statement mandating that something must be accomplished,
transformed, produced, or provided.
Primary Requirement A requirement is primary if it is levied on a contractor/producer
under force of contract.
Derived Requirement A requirement that is further refined from a primary source
requirement or a higher level derived requirement. A derived requirement can also
result from choosing a specific implementation for a system element.
Need The lack of something requisite, desirable, or useful.
Expectation Something considered reasonable, due or necessary.
Constraint A requirement that imposes a restriction or limitation on the design or
implementation of a system, product, or component.
Want The larger set of customer desires from which needs are determined.

Requirements: What - Not How

Requirements can be expressed in many ways

Needs
Missions
Expectations
Qualities
Priorities
Objectives
Capabilities
Goals
Characteristics
Properties

The requirements phase is complete when we have a complete description of the external
behavior of the software to be built. Requirements describe WHAT the system (or software) will
do without describing HOW it will be done.

Page 5 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

Types of Requirements
Functional
Performance
Environmental
Interface
Constraints
Failure
a system failure?
External

what must the system do?

how well must it be done?
in what environments must the system operate and be supported?
what are the relationships with other systems?
what constrains the development, operation or support of the system?
what design attributes must be included to prevent, inhibit, or survive
EPA regulations, state and federal laws.

Specification Wording
Shall - Use whenever a binding specification is expressed
Should or May - Use to express non-mandatory provisions
Will - Use to express simple future or declaration of purpose on the part of the
contracting agency
And/Or, Either/Or Dont use
Could, Might, Possibly Dont use

Use shall Carefully

Verify your specification to ensure you have used the shall to correctly identify requirements.
Watch out for a:

shall statement that is not a requirement

shall statement that is vague, subjective, or unbounded
shall statement that is a lead-in (check the scope of what follows)
shall statement that is a definition
shall statement that is either a task or procedure to be performed by the contractor
non shall statement that should be a requirement (improper use of will)

Weak Phrases in Requirements Specifications

Weak Phrases is the category of phrases that are apt to cause uncertainty and leave room
for multiple interpretations.
Use of phrases such as "adequate" and "as appropriate" indicate that what is required is
either defined elsewhere or, worse, that the requirement is open to subjective
interpretation.
Page 6 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

Phrases including such as, "but not limited to" and "as a minimum" provide a basis for
expanding a requirement or adding future requirements.
The total number of weak phrases found in a document is an indication of the extent
that the specification is ambiguous and incomplete.

Categories and Types

Requirements are categorized according to the FURPS+ model

Functional features, capabilities, security

Usability human factors, help, documentation
Reliability frequency of failure, recoverability, predictability
Performance response times, throughput, accuracy, availability, resource usage
Supportability adaptability, maintainability, Internationalization, configurability

The + refers to

Implementation resource limitations, languages and tools, hardware

Interface constraints imposed by interfacing with external systems
Operations system management in its operational setting
Packaging for example, a physical box
Legal licensing and other laws and constraints

Requirement Documentation
The Agile community doesnt require a specific set of documentation nor a given format
for each suggested types. UP offers several optional requirements artifacts.
Use-Case Model typical user scenarios
Supplementary Specification all requirements not in the use cases
Glossary contains terminology and includes the concept of the data dictionary
Records requirements related to data, such as validation rules, acceptable values etc.
Vision Summarizes high-level requirements that are elaborated in the use-case model
and supplementary specification
Business rules requirements or policies that transcend the project these are required
by the domain or the business

Page 7 of 8
Sara Hariri

CPSC 462 Software Design Requirement Engineering

Software Requirements Specification Template

A complete SRS is not mandatory in all projects. You will have your SRS document of you were
asked. Different templates are available online for SRS template. Some customers have their
own template and may provide you with it.
One example of a compete template is available on this website
www.Processimpact.com/process_assets/srs_template.doc
Table of Contents
Revision History
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. System Features
3.1 System Feature 1
3.2 System Feature 2 (and so on
4. External Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List

Page 8 of 8
Sara Hariri