Second lecture of the Utrecht University course software product management on requirements management and identification

1. Software Product Management
Requirements management
and identification
Lecture 2
Sjaak Brinkkemper
Garm Lucassen
8 september 2015

2. Agenda
• Introduction & definitions
– Traditional RM
– Agile RM
• Requirements identification
– Functional requirements, quality requirements & constraints
– Market requirements and product requirements

3. Managing requirements is complex
• Product managers encounter large volumes of requirements
that have to be handled
• Complex dependencies between the requirements
• Involvement of multiple, diverse stakeholders
• Product managers need to have extensive domain
knowledge of the (industrial) applications of the product.

4. Examples of requirements
“Consignment stocks of new parts are managed by DOC
and consists of parts with and without serial numbers.
Quantitative mgmt. must be performed by SOCHATA.
Mgmt. of government owned stock with associated
documents. Querying, access, inventory”
ID SC.203.A1
Source Dave Johnson
Date 04-05-2010
Description It shall be possible for all necessary communication
between the APSE and the user to be expressed in the
standard Ada character set.

5. Customer-driven RM
• Usually developed for one customer
• Platform-specific
• Phased engineering
• Large cost pressure
• Based on the requirements, the necessary resources
and the time are estimated
• Synonyms for tailor-made software:
– bespoke software
– custom-made software

6. Market-driven RM
• Developed for many customers
• Usually platform-independent
• Engineering takes place concurrently
• Big time-to-market pressure
• Only those requirements that fit within the available
resources and time are being implemented in the product

7. Requirements management:
3 key tasks
1. Communicating
– What shall we do with the requirement of that customer?
– Can you explain the content of the next release?
2. Decision making
– Are we going to implement the new requirements on security?
– Is this requirement standard or customer specific?
3. Domain knowledge transfer
– What is this requirement all about?
– How is this functionality used in the usage environment of the
customer?

8. What is a requirement?
• Wish for a future product feature
• Robertson & Robertson: A requirement is a statement on an
action that the product is requested to do, or a quality that
the product is requested to have.
• IEEE 610.12-1990: A requirement is:
– 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 or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
– A documented representation of a condition or capability as in
(1) or (2).
Definition of the
Robertsons is
leading

9. Requirements management
• Recall from the first lecture:
Requirements management concerns “dealing with the
content and administrative data of each individual
requirement”
• Some researchers use the term Market-Driven
Requirements Engineering (MDRE), e.g. Regnell &
Brinkkemper (2005) ). However, this is a more specific term
than requirements management, as it deals with large
volumes of requirements for software products.

10. Design
Purpose
The purpose of Requirements Management is
a. to manage the requirements of the project's products
and product components;
b. and to maintain the consistency between those
requirements and the project's plans and work
products (SEI, 2003)
RDB
Release
Plan Code
a
b

11. SPM Competence Model

12. SPM Competence Model

13. Requirements Management
How does RM relate to Development for planning releases in
software production
Two types of requirements management processes
A. Traditional
– Derived from methods for tailor-made software
B. Agile
– In context of Scrum process

14. Release
initiation
Release
definition
Functional
design
Technical
design
Conceptual
solution
Requirements
management
Release
planning
Deve-
lopment
Requirements
Database (RDB)
Market
requirements
Product
requirements
Software
component
* *
Release
initiation
Release
definition
Functional
design
Technical
design
Conceptual
solution
Requirements
management
Release
planning
Deve-
lopment
Requirements
Database (RDB)
Market
requirements
Product
requirements
Software
component
A. Traditional RM in relation to
release planning and development
Market requirements
originate from customers,
the field, analysts etc.
Data repository of market and
product requirements
(all development groups)
Product requirements translate
market requirement(s)
into generic solutions
Based on strategic
directives and product
roadmap
Product requirements
selected for the release
Softw. Req.
Specification
Release independent
clarification and descriptions
of product requirements

15. Release
initiation
Release
definition
Functional
design
Technical
design
Conceptual
solution
Requirements
management
Release
planning
Deve-
lopment
Requirements
Database (RDB)
Market
requirements
Product
requirements
Software
component
* *
RM in relation to release planning
and development
15
Softw. Req.
Specification

16. Software Requirements
Specification
• A Software Requirements Specification (SRS) is a document that
describes a sketch of a solution for (a set of) product
requirements.
• ISO/IEC/IEEE 29148: Template and instruction ISO (83 pp.)
• Should contain enough information to:
– make the solution understandable to all stakeholders
– create a functional design by software engineers
• For internal AND external communication
– be careful with explicit statements on current products

17. SRS contents (1)
• This solution could cover several releases
– so an indication is to be given in which release various aspects
are provisionally planned
• Essentially a free format document, with
– references to which requirements are covered (to the
requirements database),
– an indication of involved components,
– and indications of required integration with other components.
• SRS is also called:
– Use case document
– Conceptual Solution (CS)

18. SRS contents (2)
• A SRS typically consists of:
– free format text describing business solutions
– examples of business processes or Use-Cases
– high-level Class diagram or Process flow
– samples of data, e.g. reports, tables, screens
– indication of involved components of the product
Tag execution
Extra checkbox
for Tag
execution
√

19. Intermezzo: what is Agile?
• Who works in an Agile environment?
19

20. Agile Manifesto
20

21. SCRUM
• “a flexible, holistic product development strategy where a
development team works as a unit to reach a common goal”
21

22. Release
initiation
Release
definition
User Stories
Requirements
management
Release
planning
Deve-
lopment
Requirements
Database (RDB)
Market
requirements
Product
requirements
Software
component
* *
B. RM in Agile to release planning
and development
22

28. Agenda
• Introduction & definitions
– Traditional RM
– Agile RM
• Requirements identification
– Functional requirements, quality requirements & constraints
– Market requirements and product requirements

29. Three types of requirements
• Functional requirements, which describe what the product
should do.
• Quality requirements, which describe a quality that a
product should have.
• Constraints, which are global requirements that restrict how
the product is developed.
• Based on the work of Sommerville (2007), Pohl (2010),
Robertson & Robertson (2006), and Wiegers (2003)

30. Functional requirement
• Definition:
A functional requirement is a statement of
– a service the product should provide,
– how the product should react to particular inputs,
– and how the product should behave in particular
situations.
• Examples:
– “Deletion of an order will automatically delete all the lines of
the order”
– “The image viewer must display enlarged images.”

31. Quality requirement
• Definition:
A quality requirement defines a quality property of the
entire product or of a product component, service, or
function.
• Examples:
– “The system functions in a 7x24 mode and must have less
than 1 hour downtime per month.”
– “The response time of the home page must not exceed five
seconds.”
• Quality requirements are sometime referred to as non-
functional requirements.

32. Quality requirements taxonomy
Quality requirements
Important primarily Important primarily
to users to developers
• Availability
• Efficiency
• Flexibility
• Integrity
• Interoperability
• Reliability
• Robustness
• Usability
• Maintainability
• Portability
• Reusability
• Testability

33. Software Product Quality

34. Quality requirements (users)
• Availability, concerning the percentage of time that a product is available
for use and fully operational.
• Efficiency, referring to how efficient the product is in using resources as
processor time, memory, or communication band with.
• Flexibility, which indicates how easily a product can be extended with new
functionalities.
• Integrity, concerning protection against unauthorized access, data privacy,
information loss, and infections through maleficent software.
• Interoperability, referring to how easily the product van exchange data or
services with other systems.
• Reliability, indicating how long a product can be used without failure.
Note the difference between availabilty and reliability:
the % of uptime vs. the probability a product functions
without failures in a certain time period

35. Quality requirements (users) - 2
• Robustness, which is the degree to which the product or product
component continues to operate correctly when confronted with invalid
inputs, defects in connected systems, or unexpected operating conditions
• Usability, which refers to the effort that is needed of the user to prepare
input for, operate, and interpret the output of the product.

36. Quality requirements (developers)
• Maintainability, which indicates the effort it takes to correct a defect or
make a change in the product.
• Portability, indicating how easy it is to migrate a product or product
component from one operating environment to the other.
• Reusability, referring to the extent to which a product component can be
reused in other products.
• Testability, which indicates the effort it takes to test the product
(components) to find defects.

37. Example quality requirements
• Efficiency
“The system must be able to handle 1,000 concurrent web-
users per second”
• Integrity
“The parameter setting of the system can only be entered
and modified by a user with super-user rights”
• Reliability
“The system functions in a 7x24 mode and must have less
than 1 hour downtime per month"

38. Handling quality requirements
• Quality requirements should not be “hidden” in a functional
requirement. They are described:
– Inside a functional requirement in case it is directly related
– A separate requirement in case it is unrelated and requires
significant workload.
• Quality requirements must have a business case, and are
not for the sake of the Development team.
– Example: “To improve maintainability, the architecture of the
Sales module must be refactored.”

39. What about non-functional
requirements?
• Traditionally, many authors and practitioners differentiate
between functional & non-functional requirements
• We do not use that term anymore, since
– It is a weird term (why develop non-functional stuff?)
– Non-functional requirements are often underspecified
functional requirements
– The rest of the non-functional requirements are actually
quality requirements
Non-functional requirements =
Underspecified functional
requirements
Quality requirements
Pohl, 2010

40. Example of an NFR / underspecified
functional requirement
• “The system shall be secure.”
– What does “secure” mean?
– Which properties should it have to be “secure”?
– How can one check wether the system is “secure”?
• Breakdown of the NFR:
– Each user must log in to the system with his user name and password
prior to using the system. (functional requirement)
– The system shall remind the user every four weeks to change the
password (functional requirement)
– When the user creates or changes the password, the system shall
validate the new password is at least eight characters long and contain
alphamumeric characters. (functional requirement)
– The user passwords stored in the system must be protected against
password theft (quality requirement – integrity)

41. Constraint
• Definition:
A constraint is an organizational or technological
requirement that restricts the way in which the system
shall be developed.
– Constraints affecting the system
– Constraints affecting the development process
• Examples:
– “Due to current conditions defined by the insurance company,
only the security technician is allowed to deactivate the control
function of the system.”
– “The product shall operate on a Ipad.”

42. Restricting effect of constraints
Range of realization
alternatives for requirement
without considering
constraints
Range of possible realization
alternatives with the
consideration of constraints
Restricting effect of
constraints on a requirement
R-1
R-2
R-3
R-4
R-5
R-6
R-7
R-8

43. Real example of a constraint effect
• Students were asked to develop a new website website for
Business Informatics. One of the requirements was defined as:
– People without much knowledge of HTML and scripting should be able
to maintain the website.
• The idea was to implement a content management system (CMS),
such as Joomla, in order to satisfy the requirement above.
• In addition to the requirements, we defined the following
constraint:
– The website should run on the ICS department’s servers.
• Soon we found out that the ICS servers do not support MySQL.
Hence, a CMS using MySQL, such as Joomla, was no longer an
option.

44. “If the sensor detects that a glass pane is damaged or
broken, the system shall inform the security company”
Functional
requirement
Quality
requirement
Constraint

45. “The house information system shall generate a monthly
report containing all granted and denied admittances to the
house”
Functional
requirement
Quality
requirement
Constraint

46. “The system must be developed using the Rational Unified
Process.”
Functional
requirement
Quality
requirement
Constraint

47. “The customer must be able to access their account 24
hours a day, seven days a week.”
Functional
requirement
Quality
requirement
Constraint

48. Agenda
• Introduction & definitions
– Traditional RM
– Agile RM
• Requirements identification
– Functional requirements, quality requirements & constraints
– Market requirements and product requirements

49. Requirements examples
“Consignment stocks of new parts are managed by DOC
and consists of parts with and without serial numbers.
Quantitative mgmt. must be performed by SOCHATA.
Mgmt. of government owned stock with associated
documents. Querying, access, inventory”
versus
ID SC.203.A1
Source Dave Johnson
Date 04-05-2010
Descripti
on
It shall be possible for all necessary communication
between the APSE and the user to be expressed in the
standard Ada character set.

50. Market vs. product requirements
• In software product management, it is necessary to
distinguish market requirements from product requirements
Market requirements
• Varying quality, vague
• Varying size: too small,
too large
• Combine several wishes
• Non-standard, customer
specific wishes
• Important input
Product requirements
• Similar style suitable for
internal communication
• Similar workload
• Oriented towards the
standard product

51. Market requirement
• A market requirement is a customer wish related to current
or future markets, defined using the terminology and
context of the customer.
Consignment stocks of new parts
are managed by DOC and
consists of parts with and without
serial numbers. Quantitative
management must be performed
by SOCHATA. Management of
government owned stock with
associated documents. Querying,
access, inventor

52. Product requirement
• A product requirement is a requirement to be covered by
future product releases described in the company’s own
terminology and context.

53. States of Product Requirements
Candidate
Approved
Specified
Planned
Developed
Released
Verified
Discarded
Requirements management (continuous mode)
Release planning (release mode)
Entered in RDB
In product scope
SRS available
Permanently out of scope
Planned in release
All software components developed
Testing successful
Available for customers

54. Attributes of Product requirements
Attribute Value Assigned in State
State C / A / S / P / I / V / R / T -
Name Short unique name Candidate
ID Unique identifier Candidate
Source Who issued it? Candidate
Description Short textual description Candidate
Func Component Affected (sub-)modules C / A / S
Priority Importance category (1, 2, 3) Approved
Motivation Rationale: Why is it important Approved
Specification Links to Use case, SRS Specified
Links Links to other reqs; parent-child rel. Specified
Estimation Effort estimation in hours Specified
Modules Links to modules in architecture Specified
Schedule Selected for this release Planned
Design Links to design documents Developed
Test Links to test documents Verified
Release Ver Released in this version Released

55. Guidelines for writing requirements
• Write complete sentences that are short and direct.
• Use active voice (“The system shall do something”, not
“Something shall happen”)
• Use terms consistently and as defined in the glossary
• State requirements in a consistent fashion (e.g. “the
system shall” + action verb + observable result)
• Identify the specific actor where possible (“The user shall…”,
“The buyer shall…”)
• Use lists, figures, graphs, and tables to present information
visually
• Emphasize the most important bits of information

56. Quality criteria for PRs (1)
• Complete: The product requirement is complete when it adheres
to the rules and guidelines and it does not omit any information
that is relevant for any of the stakeholders.
• Traceable: The source, evolution and impact and use in later
development phases should be registered.
• Correct: The relevant stakeholders should confirm its correctness
and demand that the product must realize the requirements
completely. A requirement is incorrect when it unnecessarily adds
functionality or quality properties.
• Unambiguous: The requirement should be written in such a way
that it permits only one valid interpretation.
• Comprehensible: The requirement is comprehensible if the content
is understood by all relevant stakeholders.
Pohl (2010)

57. Quality criteria for PRs (2)
• Consistent: The statements in the requirement should not
contradict with each other.
• Verifiable: The stakeholders should be able to check whether the
realized product fulfils the documented requirements or not.
Acceptance criteria can be defined to facilitate verifiability.
• Rated: A requirement’s relevance or stability should be
determined and updated.
• Up-to-date: A requirements is up-to-date when it reflects the
current status of the product and product context, such as current
legal regulations.
• Atomic: A requirements should be self-contained, describing a
single coherent functionality.
Pohl (2010)

58. Ambiguous terms to avoid
• Acceptable, adequate (what constitutes acceptability?)
• As much as possible (don’t leave this up to the developers)
• Depends on (describe the nature of the dependency)
• Efficient, fast (quantify)
• Flexible (to what?)
• Ideally (also describe non-ideal behaviour)
• Optionally (define whether this is a system, user or developer
choice)
• Several (how much?)
• Shouldn’t (try to state requirements as positives)
Wiegers (2003)

59. Validation of product requirements
• Requirements validation is done to ensuring that (Bahill &
Henderson, 2005):
1. the set of requirements is correct, complete, and consistent,
2. a model can be created that satisfies the requirements, and
3. a real-world solution can be built and tested to prove that it satisfies
the requirements.
• Validation approaches:
– Inspections: thorough review by stakeholders (Fagan, 1976)
– Reviews: commenting by peers
– User validations: sign-off by customer representatives
– Simulations: fast prototyping

60. Insertion of requirements into the RDB
• Market requirements are usually taken from customers,
prospects, analysts into the RDB on an as-is basis.
• Product requirements are formulated by the product
managers, and:
– are self-contained requirements; no hierarchical dependencies
– can be realized independently
– are of a standard workload (Baan: between 30 and 70
mandays; Exact: around 5 mandays)
• Very small requirements, e.g. ‘extension of field length’, are
entered under one generic PR per area (e.g. Finance
module: Product Improvement

61. Linking MRs to PRs

62. Orthogonal requirements dimensions
Functional requirements
Quality requirements
Constraints
Market
requirements
Product
requirements
* *

63. Assignment
• Deadline company description: Friday 11 Sept at 11:00 AM
– Submit through Ephorus (student.ephorus.nl)
– Submission code: MSPM2014

64. Questions?