spm 4 requirements gathering and organization
Post on 28-Nov-2014
176 Views
Preview:
DESCRIPTION
TRANSCRIPT
Software Product Management Requirements gathering and organization
Lecture 4
Sjaak Brinkkemper
Garm Lucassen
10 September 2014
SPM Competence Model
SPM Competence Model
Agenda
• Requirements sources
• Requirements gathering
• Requirements organization
Gathering from external sources
• Customer: Extension of product features – Specialization: new attributes, process variants
– Completion: covering the whole workflow
– Interoperability: interfacing with other products
• Market: Product positioning – Standard functionality coverage
– Market distinction: unique selling points
• Partners: Product implementation – Voice of customers
– Partner revenue generating features
– E.g. Microsoft Dynamics implementation service partners provide reqs to MS
Gathering from internal sources (1)
• Company board – Long term product vision
– Major product themes
– Influence from portfolio and lifecycle decisions
• Sales – Input from Request for Information (RfI) and Request for Proposals
(RfP)
– Short term vision
• Marketing – Sense of the market; market trends,
– Competitors, market analysis
Gathering from internal sources (2)
• Research & innovation – Functional feature innovation
– Technical platform innovation; prototypes with new devices
• Development – Refactoring of architectural problems
– Process optimization
• Services – Features that facilitate implementation: migration tools, business
modeling tools
– Voice of customer: process alternatives, simplification, UI changes
• Support – Frequently occurring problems
Communication channels
• Stakeholder input channel: Specific process for each channel
• Agenda time allocation per input channel
• Always give a response to every input of a market requirement
• Educate internal stakeholders about process obligations (sales and marketing, board, etc.)
• Do NOT allow bypassing of product management
• Careful with explicit communication of release inclusion, best in case of development completion
Agenda
• Requirements sources
• Requirements gathering
– Inquiry cycle
– Gathering techniques
• Requirements organization
Requirements inquiry cycle (1)
• An informal pattern for improving a set of requirements (or any other document, actually)
• Three phases:
1. requirements documentation
2. requirements discussion
3. requirements evolution
Requirements inquiry cycle (2)
Colin Potts, Kenji Takahashi, and Annie I. Antón. Inquiry–Based Requirements Analysis. IEEE Software, 11(2):21–32, Mar. 1994.
Requirements gathering techniques
1. Brainstorming
2. Questionnaires
3. User groups
4. Lead user interviews
5. Workshops
6. Prototyping
7. Beta customers
8. Work in user setting
1. Brainstorming
• Gathering of stakeholders and the exchange of ideas in an open atmosphere where no one risks being ridiculed for their ideas and no ideas are rejected/criticized.
Involved stakeholders Advantages Disadvantages
Relevant internal and
external stakeholders
Product manager(s)
Many ideas
Simple organization
Low commitment
Too many ideas
Difficult to create a
good atmosphere
where everyone is
involved
Difficult to get good
representation of
customer base
2. Questionnaires
• Research instrument to get quantitative data from respondents
Involved stakeholders Advantages Disadvantages
End users Lot of information
Low costs
Difficult to create
good questionnaires
3. User groups
• Groups of customers who commonly use your products and services. They provide input on product improvements, and offer feedback on their needs and desires
Involved stakeholders Advantages Disadvantages
Members of user
groups
Product manager(s)
High-quality
outcome, focused on
actual business
problems
Improved customer
relationships
Risk of dominating
users
Risk of ‘complain
sessions’
Too much focus on
low-level
requirements
4. Lead user interviews
• Interviews with representatives of certain groups of stakeholders or key accounts
• Lead Users are users of a product that currently experience needs still unknown to the public and who also benefit greatly if they obtain a solution to these needs (von Hippel, 1986)
Involved stakeholders Advantages Disadvantages
Lead users
Product manager(s)
High-quality outcome Time-consuming
Difficult to find
representative lead
users
5. Workshops
• Also called: Joint requirements development sessions
• Requirements are jointly identified and defined by stakeholders. Cross-functional implications that are unknown to individual stakeholders are uncovered.
Involved stakeholders Advantages Disadvantages
Relevant internal and
external stakeholders
Product manager(s)
Uncovering cross-
functional issues
High-quality outcome
Customer buy-in
Time-consuming
Danger of ‘opinion-
leadership’
Who commits to
requirements?
6. Prototyping
• Users can experiment with the system and point out its strengths and weaknesses of the implemented requirements.
Involved stakeholders Advantages Disadvantages
End users
Developers/designers
Product manager(s)
Visualization
stimulates new ideas
Usability issues are
also included
Interaction between
designer and end-
user lead to high-
quality outcome
Time-consuming
High costs
Not all functionalities
are covered
“Is it already done?”
7. Beta customers
• Users who test the beta-version of a working product in a real production environment
Involved stakeholders Advantages Disadvantages
Customers
Developer(s)
Account manager(s)
Product manager(s)
Clear requirements
Mutual trust and
commitment
Can also be used for
testing customer-
specific functionality
Time-consuming
Difficult to get good
representation of
customer base
8. Work in user setting
• Product manager works as an end-user to experience the current functionality
Involved stakeholders Advantages Disadvantages
Product manager Good insight in
operational product
Improves customer
relationship
Time-consuming
Just perspective of
specific customer
Selection of techniques
Experience Product team
Experi
ence C
usto
mer
/ U
ser
low high
low
hig
h
Fuzzy problem
Teaching
Catch-up Mature
Fuzzy problem: • Brainstorming • Workshops
Teaching: • Prototypes • Beta-customers
Catch-up: • Lead user interviews • User groups • Work in user setting
Mature: • Questionnaires • Workshops • Prototypes
Agenda
• Requirements sources
• Requirements gathering
• Requirements organization
– Organization techniques
– Requirements dependencies
– Linking requirements and architecture: Functional architecture framework
Requirements organization
• Requirements can be organized in many different ways, e.g.
– Per product
– Per component
– Per functional area
– Per theme
– ....
Thematic grouping (1)
• A theme groups requirements that should be implemented together.
• A release theme typically:
– Is interesting enough to be mentioned in press releases and used in advertising campaigns
– Appears in sales leaflets and product brochures
– Is negotiated as part of product roadmaps
– Is small and broad enough for evaluating alternative implementation strategies
Thematic grouping (2)
Example (Car Garage IS):
The release theme Order process management involves the use cases
– Create order
– Implement order
– Close order
– Record car
– Edit car properties
– Generate task lists
Use abstraction levels if neccessary
• The highest abstraction level is closest to company strategy
• The lowest abstraction level is closest to software design
• Requirements on the same abstraction level are comparable to each other
• Traceability across abstraction levels allows understanding of how software design contributes to implementing company strategy
• The number, naming, and meaning of abstraction levels is company‐ or product‐specific
Gorschek,T., Wohlin, C. (2006). Requirements Abstraction Model. Requirements Engineering, 11(1), 79-101.
Example 1 (2 levels)
Means-end relationship
If the means (requirements) are sufficiently achieved, the ends (goals) are considered achieved as well.
Means and ends should not be compared to each other when prioritizing.
Example 2 (4 levels)
Themes and abstraction levels Theme: lending process automation
Theme: data storage
Theme: theft protection
Requirements dependency types
Most common types:
• Combination (AND). A printer requires a driver to function, and the driver requires a printer to function.
• Implication (REQUIRES). Sending an e-mail requires a network connection, but not the opposite.
• Revenue-based (CVALUE). “Affects customer value of” A detailed on-line manual may decrease the customer value of a printed manual.
• Cost-based (ICOST). “Affects implementation costs” A requirement stating that "no response time should be longer than 1 second” will typically increase the cost of implementing many other requirements.
Carlshamre et al. (2002)
Requirements dependency types (2)
Other dependency types:
• Exclusion (OR). In a word processor, drawings can be either provided as integrated drawing model or a link of external drawing application.
• Time-related (TEMPORAL). The function Add object should be developed before Delete object.
Dealing with dependencies
• Record dependencies in requirements database
• Include in prioritization and selection process
– Not all prioritization techniques support this
• Have as little possible dependencies, as they complicate prioritization and selection
Linking requirements and architecture
• Twin Peaks Model:
Nuseibeh, B. (2001). Weaving together requirements and architecture. IEEE Computer, 34(3), 115–119.
Why the Twin Peaks Model?
• Joint refinement
– Twin Peaks explicitly allows the customer to explore the solution space early (tailor-made software)
• Integration of software products
– More and more, software development is a process of identifying and selecting desirable requirements from existing commercially available software packages. With Twin Peaks, developers can identify requirements and match architectures rapidly and incrementally.
• Rapid change
– Twin Peaks is receptive to changes as they occur
Twin peaks adapatation CBSP Intermediate Model
• Component, Bus, System, Property (CBSP) Approach (Grünbacher, Medvidovic & Egyed, 2003)
• Intermediate model to join RE & SA
• Goal is to aid requirements refinement
• “Looks like requirement”
• “Feels like architecture”
• End result: elicited architectural building blocks
Functional architecture framework
• Instrumentation of the Twin Peaks model
• Consider practical issues like:
– How to manage the product vision for future, subsequent releases?
– How to register incoming requirements from customers and prospects?
– How to assign work to development teams?
– How to manage large volumes of requirements in a distributed company?
Vision
• Develop a complete vision on the functional architecture of all relevant applications of your product in the business domain
the Functional Architecture Framework
• The FAF is:
– the standard positioning arrangement for all requirements
– developed together with architects, partners, customers
– used to show the product roadmap
– expressed in easy to understand models
User working scope: event manager
Example: Event Ticketing
Legal Merchandising Customer
Relationship Management
ticketing contract
event request
booking
ticket types
banking details
payee interaction
options terms of services
customer details
event details
Contract management
Ticket sales
Pay- ment
Acqui- sition
Functional architecture
On-line Event Ticketing
Information flow
Product scope
ticketing contract
event request
booking
ticket types
banking details
payee interaction
options terms of services
customer details
event details
Contract management
Ticket sales
Pay- ment
Acqui- sition
Module
FA on module level: Ticket sales
Sub-module Module scope
Event registration
Event reporting
templates
booking
reports
ticket types final ticket
payment details
Visitor management event details
Ticket selection
Pre-payment
arrangement
Ticket sales
Type management
package structures
ticket overview
visitor details
FA of Contract management
Contract baseline
Event administration
Options handling
contract
version
Contract management
option
details
final contract
terms of services
ticket types event details
options
Sub-module
Module scope
payee interaction
Functional Architecture for ERP product
Bussiness Planning Product Innovation
Master Planning
Production
Requirements Planning
Warehousing
Pur- chase
Sales Assembly
Product Information
Receipt & Goods
Component Manufact.
Assembly Packing & Shipping
Sales Forecast
Invoiced Sales Order
Customer Request
Packing and shipping order
Sales Order Ready for Assembly
Master Plan Material Plan
Material Plan Subcontracting
Progress
PO/ Contracts/ Inquiries
FAS Order Production Orders/ schedules
Received Goods
Picking List
Shipment order
Purchase
Picking List
BusinessPlan
Features: Event Ticketing
Acquisition Payment
Ticket Sales Contract
Mgmt
Type Management
Event Registration Contract
Baseline Options handling
Event Administration
Open basket Save basket Print ticket Remove unused baskets Monitor abuse
Select baseline
Select options
Check consistency
….
Visitor Management
Ticket Selection
….
….
….
….
….
….
….
….
Pre-payment Arrangement
….
….
Event reporting
The extension to feature modeling is part of the course Software Architecture
Technical systems
• FAs can also be provided for technical systems
• Example:
Front-end
Firefox architecture
DocShell
Document Object Model
Gecko (layout engine) JavaScript
Localization
Mac OS X Developme
nt
MathML
Networking (Necko)
Binary Plugins (including NPAPI)
MailNews
Quality Assurance
Semantic Data Interchange (RDF)
Security
Vector Graphics (SVG)
Toolkit
Cross Platform Components (XPCOM)
Exchange Language Binding (XBL)
User Interface Language (XUL)
XULRunner
Coding modules
• Modules should be coded for the requirements management processes
Module Sub-module Module code
… … …
Ticket Sales
Visitor management TiSa-VM
Ticket selection TiSa-TS
Event registration TiSa-ER
…
Contract mgmt
Contract baseline CoMa-CB
Event administration CoMa-EA
Options handling CoMa-OH
… … …
Product variability
• Products are sold in different markets with specific requirements
• Software parameterization allows for market specific applications
• Examples:
– Event ticketing tool for scientific conferences, festivals, corporate events
– Enterprise edition, Academic edition, Village edition
• Product variability: one product can be sold in distinct markets in a market-specific configuration
• Issue: How to perform requirements management for a multi-market product?
Typology
• A typology is a classification of a Application Domain based on some discriminating characteristics
• Example: Typology of Event ticketing
– Scientific conference
– Single-venue festival
– Multi-venue festival
– Corporate event
ticketing contract
event request
booking
ticket types
banking details
payee interaction
options terms of services
customer details
event details
Contract management
Ticket sales
Pay- ment
Acqui- sition
Components: modules & typologies
Ticket Sales • Visitor management • Ticket selection • Event registration • Type management • Pre-payment arrangmt • Event reporting Contract management • Event administration • Contract baseline • Options handling
• ……
Typology of Event Ticketing:
• Scientific conference
•Single-venue festival
•Multi-venue festival
•Corporate event
Functional component
• The FAF consists of Functional Components
• A Functional Component is a virtual (sub-)module specific for one particular type
• Examples: – Ticket selection in Multi-venue festival type
– Event reporting in Conference type
– Options handling in Corporate event type
• Product Requirements are linked to: – one Functional Component, or
– groups of Functional Components
Linking requirements to the FAF
PR146: Requirement for Corporate Event Type: Visitor records are to be uploaded from the HR files
FC: Visitor management in
Corporate Event Type
FC: Visitor Management in
Conference Type
PR283: Requirement for Conference Type: The records of visitors should be kept for future years
Functional Components
for Visitor Management
Coding functional components
Module Sub-module Typology Functional Component
… … … …
Ticket Sales
Visitor Management
Conference 111
Single-venue 112
Multi-venue 113
Corporate 114
Ticket Selection
Conference 121
Single-venue 122
Multi-venue 123
Corporate 124
Contract Management
Contract Baseline
Conference 211
Single-venue 212
Multi-venue 213
Corporate 214
… … … …
Coding functional components
Module Sub-module Typology Functional Component
… … … …
Ticket Sales
Visitor Management
Conference TiSa-VM-CO
Single-venue TiSa-VM-SV
Multi-venue TiSa-VM-MV
Corporate TiSa-VM-CE
Ticket Selection
Conference TiSa-TS-CO
Single-venue TiSa-TS-SV
Multi-venue TiSa-TS-MV
Corporate TiSa-TS-CE
Contract Management
Contract Baseline
Conference CM-Bas-CO
Single-venue CM-Bas-SV
Multi-venue CM-Bas-MV
Corporate CM-Bas-CE
… … … …
Usage
• The Functional Architecture Framework provides an ordering scheme for all functional requirements
• Adaptable for the future markets:
– Functional Architecture can be adapted:
• Addition of a (sub-)module
• Rearrangements of the modules
– Product variability
• Adaptation of typology for different markets
– Components can be added
Case studies
Selected three companies based on differences
1. Local vendor, single country
2. Medium sized multinational vendor
3. Very large globally operating vendor
Cases conducted as semi-structured interviews, interviewees were responsible for relating requirements to the architecture
Collected documentation and experiences were the basis of the FAF
Case studies
Isah Exact Infor/Baan
Market specifity High, specific Low, wide Very low
Development team Single team Multiple teams Distributed
Requirements volume Low Medium High
Product variability None Simple Complex
FAF implementation Only basic No variability Full FAF
Lessons learned from cases (1)
• Informal development processes can still benefit from a strong structure in requirements management
• Implementing the full FAF allows a very high volume of requirements to be managed efficiently
• The data provided by the FAF decreases dependency on an individual product manager or architect to know how the application is structured
Lessons learned from cases (2)
• Mappings in the FAF made it possible to involve the right architects
– This made it possible to scope the impact of requirements on the architecture early in the definition of a release
• The relation between functional architecture and system architecture makes the impact of changes on the architecture visible earlier in the process
• Providing extra benefits from the FAF to all stakeholders proved vital to the acceptance and effectiveness of the FAF
Some RM figures for BaanERP (2001)
• 250 modules; 10.000 components; 4.5 MLOC
• Per release (9-12 mo. duration)
– 100 Conceptual Solutions
– 100 Functional Designs (Team)
• About 9000 Market Requirements
• 2500 Product requirements in RDB
• 117 Product requirements in the 5.2 release
• 4830 SW eng days for release
• Average 41 days per requirement
We welcome more recent data from case studies!
RDB Functional Components
RDB PR to FAF mapping
Questions?
top related