spm 4 requirements gathering and organization
DESCRIPTION
Lecture 4 of Software Product Management course at Utrecht UniversityTRANSCRIPT
![Page 1: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/1.jpg)
Software Product Management Requirements gathering and organization
Lecture 4
Sjaak Brinkkemper
Garm Lucassen
10 September 2014
![Page 2: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/2.jpg)
SPM Competence Model
![Page 3: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/3.jpg)
SPM Competence Model
![Page 4: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/4.jpg)
Agenda
• Requirements sources
• Requirements gathering
• Requirements organization
![Page 5: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/5.jpg)
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
![Page 6: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/6.jpg)
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
![Page 7: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/7.jpg)
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
![Page 8: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/8.jpg)
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
![Page 9: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/9.jpg)
Agenda
• Requirements sources
• Requirements gathering
– Inquiry cycle
– Gathering techniques
• Requirements organization
![Page 10: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/10.jpg)
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
![Page 11: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/11.jpg)
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.
![Page 12: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/12.jpg)
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
![Page 13: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/13.jpg)
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
![Page 14: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/14.jpg)
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
![Page 15: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/15.jpg)
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
![Page 16: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/16.jpg)
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
![Page 17: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/17.jpg)
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?
![Page 18: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/18.jpg)
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?”
![Page 19: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/19.jpg)
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
![Page 20: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/20.jpg)
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
![Page 21: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/21.jpg)
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
![Page 22: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/22.jpg)
Agenda
• Requirements sources
• Requirements gathering
• Requirements organization
– Organization techniques
– Requirements dependencies
– Linking requirements and architecture: Functional architecture framework
![Page 23: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/23.jpg)
Requirements organization
• Requirements can be organized in many different ways, e.g.
– Per product
– Per component
– Per functional area
– Per theme
– ....
![Page 24: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/24.jpg)
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
![Page 25: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/25.jpg)
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
![Page 26: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/26.jpg)
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.
![Page 27: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/27.jpg)
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.
![Page 28: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/28.jpg)
Example 2 (4 levels)
![Page 29: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/29.jpg)
Themes and abstraction levels Theme: lending process automation
Theme: data storage
Theme: theft protection
![Page 30: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/30.jpg)
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)
![Page 31: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/31.jpg)
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.
![Page 32: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/32.jpg)
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
![Page 33: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/33.jpg)
Linking requirements and architecture
• Twin Peaks Model:
Nuseibeh, B. (2001). Weaving together requirements and architecture. IEEE Computer, 34(3), 115–119.
![Page 34: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/34.jpg)
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
![Page 35: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/35.jpg)
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
![Page 36: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/36.jpg)
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?
![Page 37: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/37.jpg)
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
![Page 38: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/38.jpg)
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
![Page 39: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/39.jpg)
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
![Page 40: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/40.jpg)
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
![Page 41: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/41.jpg)
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
![Page 42: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/42.jpg)
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
![Page 43: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/43.jpg)
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
![Page 44: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/44.jpg)
Technical systems
• FAs can also be provided for technical systems
• Example:
![Page 45: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/45.jpg)
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
![Page 46: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/46.jpg)
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
… … …
![Page 47: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/47.jpg)
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?
![Page 48: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/48.jpg)
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
![Page 49: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/49.jpg)
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
![Page 50: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/50.jpg)
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
![Page 51: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/51.jpg)
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
![Page 52: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/52.jpg)
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
… … … …
![Page 53: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/53.jpg)
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
… … … …
![Page 54: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/54.jpg)
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
![Page 55: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/55.jpg)
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
![Page 56: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/56.jpg)
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
![Page 57: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/57.jpg)
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
![Page 58: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/58.jpg)
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
![Page 59: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/59.jpg)
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!
![Page 60: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/60.jpg)
RDB Functional Components
![Page 61: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/61.jpg)
RDB PR to FAF mapping
![Page 62: SPM 4 Requirements Gathering and Organization](https://reader033.vdocuments.us/reader033/viewer/2022051013/547a3c5c5806b571048b47e8/html5/thumbnails/62.jpg)
Questions?