The essential software requirement
This chapter will help you to:
■■ Understand some key terms used in the
software requirements domain.
■■ Distinguish product requirements from
project requirements.
■■ Distinguish requirements development from
requirements management.
■■ Be alert to several requirements-related
problems that can arise.
Taking your requirements pulse
■■ The project’s business objectives, vision, and scope were never clearly
defined.
■■ Customers were too busy to spend time working with analysts or
developers on the requirements.
■■ Your team could not interact directly with representative users to
understand their needs.
■■ Customers claimed that all requirements were critical, so they didn’t
prioritize them.
■■ Developers encountered ambiguities and missing information when coding,
so they had to guess.
■■ Communications between developers and stakeholders focused on user
interface displays or features, not on what users needed to accomplish with the
software.
■■ Your customers never approved the requirements.
■■ Your customers approved the requirements for a release or iteration and
then changed them continually.
Software requirements defined
• When a group of people begin discussing
requirements, they often start with a
terminology problem. Different observers
might describe a single statement as being a
user requirement, software requirement,
business requirement, functional
requirement, system requirement, product
requirement, project requirement, user story,
feature, or constraint. The names they use for
various requirements deliverables also vary.
The pure dictionary “requirement”
• The pure dictionary “requirement”
• Software people do not use “requirement” in the same
sense as a dictionary definition of the word: something
demanded or obligatory, a need or necessity.
• People sometimes question whether they even need to
prioritize requirements, because maybe a low-priority
requirement won’t ever be implemented.
• If it isn’t truly needed, then it isn’t a requirement, they
claim. Perhaps, but then what would you call that
piece of information? If you defer a requirement from
today’s project to an unspecified future release, is it
still considered a requirement? Sure it is.
Product vs. project requirements
So far we have been discussing requirements that describe properties
of a software system to be built.
Let’s call those product requirements. Projects certainly do have other
expectations and deliverables that are not a part of the software the
team implements, but that are necessary to the successful completion
of the project as a whole.
These are project requirements but not product requirements. An SRS
houses the product requirements, but it should not include design or
implementation details (other than known constraints), project plans,
test plans, or similar information.
Separate out such items so that requirements development activities
can focus on understanding what the team intends to build. Project
requirements include:
cont.…
•
•
•
•
•
•
•
•
•
•
Physical resources the development team needs, such as workstations,
special hardware devices, testing labs, testing tools and equipment, team
rooms, and videoconferencing equipment.
■■ Staff training needs.
■■ User documentation, including training materials, tutorials, reference
manuals, and release notes.
■■ Support documentation, such as help desk resources and field
maintenance and service information for hardware devices.
■■ Infrastructure changes needed in the operating environment.
■■ Requirements and procedures for releasing the product, installing it in
the operating environment, configuring it, and testing the installation.
• Product certification and compliance
requirements.
• ■■ Revised policies, processes, organizational
structures, and similar documents.
• ■■ Sourcing, acquisition, and licensing of thirdparty software and hardware components.
• ■■ Beta testing, manufacturing, packaging,
marketing, and distribution requirements.
• ■■ Customer service-level agreements.
Product vs. project requirements
•
•
•
•
•
•
•
Physical resources the development team needs, such as workstations,
special hardware devices, testing labs, testing tools and equipment, team
rooms, and videoconferencing equipment.
■■ Staff training needs.
■■ User documentation, including training materials, tutorials, reference
manuals, and release notes.
■■ Support documentation, such as help desk resources and field
maintenance and service information for hardware devices.
■■ Infrastructure changes needed in the operating environment.
■■ Requirements and procedures for releasing the product, installing it in
the operating environment, configuring it, and testing the installation.
■■ Requirements and procedures for transitioning from an old system to a
new one, such as data migration and conversion requirements, security
setup, production cutover, and training to close skills gaps; these are
sometimes called transition requirements (IIBA 2009).
Cont.
• ■■ Prod acquisition, and licensing ct certification and
compliance requirements.
• ■■ Revised policies, processes, organizational
structures, and similar documents.
• ■■ Sourcing, of third-party software and hardware
components.
• ■■ Beta testing, manufacturing, packaging, marketing,
and distribution requirements.
• ■■ Customer service-level agreements.
• ■■ Requirements for obtaining legal protection
(patents, trademarks, or copyrights) for intellectual
property related to the software.
Gold plating
• Gold plating takes place when a developer adds
functionality that wasn’t in the requirements
specification (or was deemed out of scope) but which
the developer believes “the users are just going to
love.” If users don’t care about this functionality, the
time spent implementing it is wasted.
• Rather than simply inserting new features, developers
and BAs should present stakeholders with creative
ideas for their consideration.
• Developers should strive for leanness and simplicity,
not going beyond what stakeholders request without
their approval.
Benefits from a high-quality requirements process
• Some people mistakenly believe that time
spent discussing requirements simply delays
delivery by the same duration. This assumes
that there’s no return on investment from
requirements activities. In actuality, investing
in good requirements will virtually always
return more than it costs.
What is a Requirement?
• Requirement [Merriam-Webster On-Line
Dictionary]
– a : something wanted or needed : necessity
– b : something essential to the existence or occurrence
of something else : condition
• Software requirement is a condition or capability [IEEESTD-610.12-1990 Software Engineering Glossary]
- Needed by a user to solve a problem or achieve an objective
- Met or possessed by a system to satisfy formally imposed
documents such as specifications or standards
Types of Requirements
Business – business objectives, the “business case”
Business rules – policy, guideline, regulation, algorithm
User – goals and tasks for a class of user; HCI
Quality Attributes – non-functional level of service
System – high level requirements for the system at large
External Interface – interfaces to users and/or other
systems
• Constraints – development choice restrictions
• Functional – behavior the system must exhibit to satisfy
user and business requirements
• Non-functional – System attributes to achieve non-user
goalsIn(performance,
usability,
…)
today’s world … Security,
Ethics …
•
•
•
•
•
•
Goals vs. Requirements?
• System functions and features must address
goals
• Tasks are the means to the end (goals)
• Goals are the motivation for observed
behaviors
• Goals drive usage behavioral patterns
Why Engineer Requirements?
• The most significant contributors to project failure
relate to requirements (Standish Group’s CHAOS
Reports)
– Most failed projects fail due to changing customer
requirements
• Meeting your project’s requirements defines success
• We can engineer a higher probability of success
Why Software Fails
Ø Unrealistic or unarticulated project goals
•
Inaccurate estimates of needed resources
Ø Badly defined system requirements
•
•
Poor reporting of the project's status
Unmanaged risks
Ø Poor communication among customers, developers, and users
•
•
•
•
•
•
Use of immature technology
Inability to handle the project's complexity
Sloppy development practices
Poor project management
Stakeholder politics
Commercial pressures
http://spectrum.ieee.org/computing/software/why-software-fails
A Notable Example of
Requirements(?) Failure
• (CNN) -- NASA lost a $125 million Mars orbiter because a
Lockheed Martin engineering team used English units of
measurement while the agency's team used the more
conventional metric system for a key spacecraft operation,
according to a review finding released Thursday.
• The units mismatch prevented navigation information from
transferring between the Mars Climate Orbiter spacecraft
team in at Lockheed Martin in Denver and the flight team at
NASA's Jet Propulsion Laboratory in Pasadena, California.
How would YOU categorize this
failure? Is it requirements?
Something else?
“The hardest single part of building a software system is deciding
precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements, …
…..
No other part of the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later.”
[Brooks, The Mythical Man-Month 1995]
Requirements Engineering Process
Frameworks
• We will survey techniques from a variety of sources
• We will utilize elements of the Unified Modeling
Language (UML) from the Rational Unified Process
(RUP)
• Even though UML is outdated/ out of favour, it’s
important to know
• It is essential to learn some “systematic, disciplined,
quantifiable approaches” to engineering of software
requirements
– the “classics” like basic arithmetic
• We will look at Use Cases, Stories, System Requirements and so on
…
UML reference – “UML 2 Toolkit” @RIT Libraries 24/7 Books
Vocabulary
•
Domain (application)
– The target area of interest, usually the business context
– E.g., health care, scientific research, a product market, an enterprise sales department
•
Business
– The sponsoring institution – profit, non-profit, commercial (external products and
systems), enterprise (internal products and systems)
•
Problem
– A business issue to be resolved or objective to be accomplished by the solution
•
Solution
– The system or product that addresses the problem requirements
•
System
– The inputs, processing, and outputs comprising the solution
– “System” will be used generally as the abstraction for what is to be built
Vocabulary (cont)
•
Product
– The specific incarnation of the solution – a system, subsystem, application
•
Project
– All of the activities managed by some process necessary to create a finished system or
product solution to satisfy the domain problem
•
User
– The individual (or external system) that interacts with the system features
•
•
Stakeholder
– Individuals (or external systems) that have some vested interest in the success of the
system
– E.g., management, users, customers, developers, service providers, etc.
Customer
– The individual who pays for and receives the completed system or product