SPM Lecture 2 - Rrequirements Management and Identification

Software Product Management Requirements management and identification

Lecture 2 Sjaak Brinkkemper Garm Lucassen 5 september 2014

Before I start…

What is a requirement?

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.

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

SPM Competence Model

SPM Competence Model

Releaseinitiation

Release definition

Functional design

Technical design

Conceptual solution

Requirem

ents m

anagement

Release

planningD

eve-

lopm

ent

RequirementsDatabase (RDB)

Market requirements

Product requirements

Softwarecomponent

* *

Releaseinitiation

Release definition

Functional design

Technical design

Conceptual solution

Requirem

ents m

anagement

Release

planningD

eve-

lopm

ent


Market requirements


Softwarecomponent

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

Release independent clarification and descriptions of product requirements

Agenda

•  Introduction & definitions •  Requirements identification

–  Functional requirements, quality requirements & constraints –  Market requirements and product requirements –  Conceptual solution

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.

RM for tailor-made software

•  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

RM for product software

•  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

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?

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

Agenda



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)

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.”

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.

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

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

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.

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.

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"

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.”

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


Pohl, 2010

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)

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.”

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

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.

“If the sensor detects that a glass pane is damaged or broken, the system shall inform the security company”


Quality requirement

Constraint

“The house information system shall generate a monthly report containing all granted and denied admittances to the house”


Quality requirement

Constraint

“The system must be developed using the Rational Unified Process.”


Quality requirement

Constraint

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


Quality requirement

Constraint

Agenda



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 Description

It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.

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

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

Product requirement

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

Product requirements’ states

Candidate

Approved

Specified

Planned

Developed

Released

Verified

Discarded

Requirements management (continuous mode)

Release planning (release mode)

Entered in RDB

In product scope

Conceptual Solution available

Permanently out of scope

Planned in release

All software components developed

Testing successful

Available for customers

Product requirements’ attributes 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, Conc. Solution 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

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

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)

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)

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)

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

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

Linking MRs to PRs

Orthogonal requirements dimensions

Functional requirements


Constraints

Market requirements

Product requirements * *

Agenda



Releaseinitiation

Release definition

Functional design

Technical design

Conceptual solution

Requirem

ents m

anagement

Release

planning

Dev

e-lo

pmen

t


Market requirements


Softwarecomponent

Recall: positioning Conceptual Solution

Release independent clarification and descriptions of product requirements

CS purpose

•  A conceptual solution is a document that describes a sketch of a business solution for (a set of) product requirements.

•  This solution could cover several releases –  so an indication is to be given in which release various aspects

are provisionally planned

•  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

CS contents (1)

•  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.

•  CS is also called: –  Use case document –  Software requirements specification (SRS)

CS contents (2)

•  A conceptual solution 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

√

Assignment

•  Deadline company description: Friday 12 Sept at 11:00 AM

–  Submit through Ephorus (student.ephorus.nl) –  Submission code: MSPM2014

Questions?

SPM Lecture 2 - Rrequirements Management and Identification

Education

global requirements

new requirements

product software

requirements management

quality thatthe product

howthe product

quality requirement

complex product managers