View
907
Download
1
Category
Preview:
Citation preview
Software Product Management Requirements management and identification
Lecture 2 Sjaak Brinkkemper Garm Lucassen 8 september 2015
Agenda
• Introduction & definitions – Traditional RM – Agile RM
• Requirements identification – Functional requirements, quality requirements & constraints – Market requirements and product requirements
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.
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.
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
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
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
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.
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
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
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
RequirementsDatabase (RDB)
Market requirements
Product requirements
Softwarecomponent
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
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
* *
RM in relation to release planning and development
15
Softw. Req. Specification
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
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)
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
√
Intermezzo: what is Agile?
• Who works in an Agile environment?
19
Agile Manifesto
20
SCRUM
• “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”
21
Releaseinitiation
Release definition
User Stories
Requirem
ents m
anagement
Release
planningD
eve-
lopm
ent
RequirementsDatabase (RDB)
Market requirements
Product requirements
Softwarecomponent
* *
B. RM in Agile to release planning and development
22
Agenda
• Introduction & definitions – Traditional RM – Agile RM
• Requirements identification – Functional requirements, quality requirements & constraints – Market requirements and product requirements
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
Software Product Quality
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
Quality 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”
Functional requirement
Quality requirement
Constraint
“The house information system shall generate a monthly report containing all granted and denied admittances to the house”
Functional requirement
Quality requirement
Constraint
“The system must be developed using the Rational Unified Process.”
Functional requirement
Quality requirement
Constraint
“The customer must be able to access their account 24 hours a day, seven days a week.”
Functional requirement
Quality requirement
Constraint
Agenda
• Introduction & definitions – Traditional RM – Agile RM
• Requirements identification – Functional requirements, quality requirements & constraints – Market requirements and product requirements
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.
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
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
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
Quality requirements
Constraints
Market requirements
Product requirements * *
Assignment
• Deadline company description: Friday 11 Sept at 11:00 AM
– Submit through Ephorus (student.ephorus.nl) – Submission code: MSPM2014
Questions?
Recommended