Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© agileSEQUENT, Inc – All rights reserved
Fundamentals of Software Product
Definition Process
MRD > PRD > FRD
Leon Kotovic...
© agileSEQUENT, Inc – All rights reserved
Part 1 - Agenda
  Why software business is a good business – but not without ri...
© agileSEQUENT, Inc – All rights reserved
Part 2 - Agenda
  Select a simple requirement (is it really simple?)
  Revise ...
© agileSEQUENT, Inc – All rights reserved
Why software business is a good business – but not without
risks
  Relentless p...
© agileSEQUENT, Inc – All rights reserved
That’s why your software product …
  Has to be clearly better in every way than...
© agileSEQUENT, Inc – All rights reserved
Goals
  Introduce product management process
  Selected areas of focus
- Defin...
© agileSEQUENT, Inc – All rights reserved
Unconditional adherence to fundamentals of product
management process
What makes...
© agileSEQUENT, Inc – All rights reserved
Fundamentals of product management: MRD, PRD and
FRD
What’s the
problem?
• Marke...
© agileSEQUENT, Inc – All rights reserved
Overview of MRD, PRD, and FRD steps, activities, and
building blocks
What’s the
...
© agileSEQUENT, Inc – All rights reserved
Follow MRD, PRD, FRD process … and product building
blocks will emerge
How to cr...
© agileSEQUENT, Inc – All rights reserved
Introducing another areas of focus (but beyond the scope of
this presentation)
A...
© agileSEQUENT, Inc – All rights reserved
Product Platform enables early recognition of shared
capabilities common to all ...
© agileSEQUENT, Inc – All rights reserved
Part 2 – Are you ready to define a product?
  Select a simple requirement (is i...
© agileSEQUENT, Inc – All rights reserved
Let’s review a (seemingly?) simple requirement:
Administrator registers a new co...
© agileSEQUENT, Inc – All rights reserved
Requirement statements must be “binary”: one noun, one
verb, one or more conditi...
© agileSEQUENT, Inc – All rights reserved
Components, features, and functions must be easily detected
from requirements st...
© agileSEQUENT, Inc – All rights reserved
All building blocks (components, features, and functions)
have unique attributes...
© agileSEQUENT, Inc – All rights reserved
Features represent aggregated functionality required to
manage related activitie...
© agileSEQUENT, Inc – All rights reserved
Functions represent very granular tasks required to
enable each feature
Defining...
© agileSEQUENT, Inc – All rights reserved
Use Cases describe a sequence of steps (combined
functionality) to accomplish a ...
© agileSEQUENT, Inc – All rights reserved
Use Cases can be presented in three major forms
Use Case forms
• Free form parag...
© agileSEQUENT, Inc – All rights reserved
Each Use Cases can further described in four levels of
detail
Use Case forms
• D...
© agileSEQUENT, Inc – All rights reserved
Let’s summarize all the building blocks ….
Building initial product definition
...
© agileSEQUENT, Inc – All rights reserved
… and build initial Registration product definition
Building initial product def...
© agileSEQUENT, Inc – All rights reserved
Once functional decomposition is complete, dependency
assessments (between funct...
© agileSEQUENT, Inc – All rights reserved
Product Description Datasheet is the most critical document
created during early...
© agileSEQUENT, Inc – All rights reserved
Product Definition Datasheet is used to create other, critical
product collatera...
© agileSEQUENT, Inc – All rights reserved
Product Definition Datasheet is used to create other, critical
product collatera...
Upcoming SlideShare
Loading in …5
×

Fundamentals of Product Definition Process - MRD PRD FRD

Fundamentals of Product Definition Process - MRD PRD FRD

  1. 1. © agileSEQUENT, Inc – All rights reserved Fundamentals of Software Product Definition Process MRD > PRD > FRD Leon Kotovich CEO www.agilesequent.com Leon@kotovich.net
  2. 2. © agileSEQUENT, Inc – All rights reserved Part 1 - Agenda   Why software business is a good business – but not without risks   Goals of this presentation: how to define a software product   What makes software companies successful   Three steps of product management process   Closer look at the product management process   How to create building blocks of a product   Additional areas of focus   Importance of Product Platform as a deliberate concept NOTE: Part 2 will be a working exercise, where a simple requirement will be traced through the product management process, creating a building blocks for a product datasheet Topics
  3. 3. © agileSEQUENT, Inc – All rights reserved Part 2 - Agenda   Select a simple requirement (is it really simple?)   Revise it and detect components, features, and functions   Create a consolidated view of the initial product definition   Create a product datasheet! Topics
  4. 4. © agileSEQUENT, Inc – All rights reserved Why software business is a good business – but not without risks   Relentless pressure in all industries / segments to automate, improve information flow, reduce cycle time …   Relentless search for competitive differentiation   Hence - industry-specific software solutions are easier to sell   Prohibitively high costs of conversion once adopted   “Golden goose”: software which enables and embeds a critical process   Much easier to build a loyal customer base (unhappy customers can be loyal too)   Financial gains can be significant   The marginal cost of next multi-million dollar sale is largely equal to the cost of pressing a new CD (or sending a new executable file)   Risks - the competition is fierce, unforgiving, and ruthless Why “everyone” wants to be a software company
  5. 5. © agileSEQUENT, Inc – All rights reserved That’s why your software product …   Has to be clearly better in every way than your competition   Must solve the business problem with sustainable economic benefits   Can easily show cost / benefit even to those that will not use it   Should engage the end user in a delightful manner   Should also evoke an emotional response …   Ease of use: is it still only a promise?   User interface: is it ‘blah’ or ‘brilliant’? Is your product management process and organization behind it great enough to be the driver of great products? Are you great enough to create great products?
  6. 6. © agileSEQUENT, Inc – All rights reserved Goals   Introduce product management process   Selected areas of focus - Define products - Identify building blocks - Create product definition collateral - Establish “binary clarity” and traceability   Learn how to identify and structure building blocks   Trace a simple requirement through the process   Practice … practice … and then practice again Goals of this presentation: how to define a software product
  7. 7. © agileSEQUENT, Inc – All rights reserved Unconditional adherence to fundamentals of product management process What makes software companies successful?   Another term for product management: “relentless championship”   Overarching attribute of successful software companies: “binary clarity” in all activities (not an exhaustive list): What’s the problem? • Market & segments • Known problems • Cost of problems • Range of solutions • Cost of solutions What’s the solution? • Better process • Better information • More actions • New needs • Lower costs How does it look? • Product portfolio • Product platform • Components • Features / functions • Collateral Product Management & Definition Process Low complexity High complexity How do we do it? • Use cases • Release plans • Release schedules • Integrated Product Development Plan Medium complexity The most difficult and critical step: converting solutions into products
  8. 8. © agileSEQUENT, Inc – All rights reserved Fundamentals of product management: MRD, PRD and FRD What’s the problem? • Market & segments • Known problems • Cost of problems • Range of solutions • Cost of solutions What’s the solution? • Better process • Better information • More actions • New needs • Lower costs How does it look? • Product portfolio • Product platform • Components • Features / functions • Collateral Product Management & Definition Process Low complexity High complexity How do we do? • Use cases • Functional flows • UI elements • Integrated Product Development Plan Medium complexity MRD: Marketing Requirements Definition PRD: Product Requirements Definition FRD: Functional Requirements Definition Three steps of product management process: MRD, PRD, and FRD Focus of this presentation
  9. 9. © agileSEQUENT, Inc – All rights reserved Overview of MRD, PRD, and FRD steps, activities, and building blocks What’s the problem? What’s the solution? How does it look? How do we do it? MRD: Marketing Requirements Definition PRD: Product Requirements Definition FRD: Functional Requirements Definition Closer look at the product management process Problems Solution 1Are aligned with Solution 2 Solution 3 P R D # 1 Platform Services P R D # 2 P R D # 3 Are translated into  Must be unique  Business rules known  Needs/competition known  Critical voids known  Solutions must have “borders”  Relationships identified  Vision statements declared  Compelling features identified  Solutions -> Products  Products -> Components  Components -> Features  Features -> functions  Functions -> Use cases  Technical architecture Are decomposed into Are decomposed into Technical Architecture • Components • Features • Functions • Use Cases Activities Building Blocks Steps Enabled by …
  10. 10. © agileSEQUENT, Inc – All rights reserved Follow MRD, PRD, FRD process … and product building blocks will emerge How to create building blocks of a product Step MRD Activity • Define solution vision statements • Translate: solution visions into products • Identify: business rules PRD • Create: relationship diagrams from business rules • Translate: products into components • Translate: components into features • Translate: features into functions FRD • Translate: functions into use cases • Translate: use cases into detailed elements (workflow, error processing, dialog steps, parameters, expected results, user experience, other functions/services invoked, etc.) Building blocks • Product portfolio • Product Platform • Business rules • Relationship diagrams • Component models • Feature list • Functional inventory • Use cases • Use Case packages • Or – User Stories
  11. 11. © agileSEQUENT, Inc – All rights reserved Introducing another areas of focus (but beyond the scope of this presentation) Additional areas of focus   Product Platform as a deliberate concept
  12. 12. © agileSEQUENT, Inc – All rights reserved Product Platform enables early recognition of shared capabilities common to all products Product Platform as a deliberate concept   Managing shared, internal, or common services as a Product Platform creates multiple benefits: Product Platform  Registration  Search capabilities  Content management  Dashboard  Scalability / Performance   Allows to market capabilities not easily marketed (performance, content management)   Creates additional points of differentiation   Creates “yet another” slide why “we are better”   Ensures discipline in delivering shared capabilities across multiple products   Accelerates product development, “done once, available to all” Product #1 Product #2 Product #3   Platform is a PRODUCT!
  13. 13. © agileSEQUENT, Inc – All rights reserved Part 2 – Are you ready to define a product?   Select a simple requirement (is it really simple?)   Revise it and detect components, features, and functions   Create a consolidated view of the initial product definition
  14. 14. © agileSEQUENT, Inc – All rights reserved Let’s review a (seemingly?) simple requirement: Administrator registers a new company as a customer Selected example ”Administrator can establish a company hierarchy by creating X sub-levels under the top level unit. If a sub-level unit within the company holds a unique contract, the administrator has to locate the unit and update it with contract- specific information. (Email notification will be sent to sub-level owner to notify them). Goals of this exercise:   Re-write the requirement to pass “binary clarity” tests   Detect and identify components   For each component, identify features   For each feature, identify functions   For each function, assign a use case for further decomposition   Detect the need for business relationship diagrams Assumptions:   Product vision statement already exists
  15. 15. © agileSEQUENT, Inc – All rights reserved Requirement statements must be “binary”: one noun, one verb, one or more conditions (ideally – one) Selected example Revised language:  Company hierarchy will support unlimited number of levels (can be done by the Administrator only).  Administrator can define a contract at any level within the company hierarchy. For relationship between contracts and company hierarchy, see Diagram 1.1. • Detected component: Manage Companies • Also detected a business rule (only Administrator can create companies and hierarchies) • Detected function: Specify # of organizational levels • Detected component: Manage Contracts • Identified a diagram which needs to explain how contracts relate to organizational hierarchy Notes: ”Administrator can establish a company hierarchy by creating X sub-levels under the top level unit. If a sub-level unit within the company holds a unique contract, the administrator has to locate the unit and update it with contract- specific information. (Email notification will be sent to sub-level owner to notify them).
  16. 16. © agileSEQUENT, Inc – All rights reserved Components, features, and functions must be easily detected from requirements statements Components, features, functions – should be detectable Revised language (continued):  Administrator can display all contracts that may exist at any level within a company  Administrator can search through all contracts  Owner of organizational unit can subscribe to and receive events when contracts are updated • Detected feature in Manage Contracts Component: Display Contracts • Detected feature in Manage Contracts Component: Search Contracts • Identified new component: Manage Notifications • Identified new implications: how to notify (direct e-Mail, Dashboard, or both) Notes: ”Administrator can establish a company hierarchy by creating X sub-levels under the top level unit. If a sub-level unit within the company holds a unique contract, the administrator has to locate the unit and update it with contract- specific information. (Email notification will be sent to sub-level owner to notify them).
  17. 17. © agileSEQUENT, Inc – All rights reserved All building blocks (components, features, and functions) have unique attributes … beginning w/components Defining building blocks   Components own business rules and business relationships   For example: Manage Companies, Manage Users, Manage Contracts, Manage Viewing Rights   Components are derived from business requirements Product • Consists of Components c Components • Consist of Features c Features • Consist of Functions Functions • Consist of Use Cases
  18. 18. © agileSEQUENT, Inc – All rights reserved Features represent aggregated functionality required to manage related activities Defining building blocks   Feature decomposition is frequently based on “life cycle” technique   “Create new, add, enhance, maintain, reduce in scope, retire, archive, and delete”   For example: the first feature in Manage Companies component is Create Company   The second feature is Update Company   The third feature is Deactivate Company   … and so on … Components • Consist of Features Features • Consist of Functions c Functions • Consist of Use Cases Products • Consist of Components c
  19. 19. © agileSEQUENT, Inc – All rights reserved Functions represent very granular tasks required to enable each feature Defining building blocks   Functional decomposition is frequently based on “domain identification” technique   “What are the elements which make the company (domain)?”   Elements: name, legal address, number of org. levels, names of each business unit, distribution locations, etc.   Functions are tasks required to obtain/define each elements. For example:   Create Legal Name, Create Address, Specify Number of Levels, Assign Business Unit Names, Specify Distribution Locations Features • Consist of Functions Functions • Consist of Use Cases Products • Consist of Components c Components • Consist of Features c
  20. 20. © agileSEQUENT, Inc – All rights reserved Use Cases describe a sequence of steps (combined functionality) to accomplish a chosen task Defining building blocks   Uses Cases can be presented in three major forms: - Narrative - Scenario - Conversation   Use Cases describe “what happens” from an “external perspective”   Use Cases can be organized based on relevance, frequency of use, value to the users   Impact of adding/removing features or functions can be analyzed   Uses Cases do NOT describe: - User interfaces - Performance goals / application architecture - Non-functional requirements Functions • Consist of Use Cases Products • Consist of Components c Components • Consist of Features c Features • Consist of Functions
  21. 21. © agileSEQUENT, Inc – All rights reserved Use Cases can be presented in three major forms Use Case forms • Free form paragraph(s) • Describes the intent of actor performing Use Case • Describes high level actions of the user during the Use Case • Refer to key concepts (business rules, relationship diagrams) from the MRD, PRD, and FRD documents Narrative • Description of a specific path (driven by intent) – written from an actor’s point of view • List of steps required to accomplish Use Case • Each step – simple declarative statement • Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components Scenario • Description which emphasizes interactions between an actor and the system • Shows optional and repeated actions • Each action can be decomposed into sub-actions • Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components Conversation Required Elements  Actors  Intent (could be multiple) Supporting Elements  Key concepts and relationships  Known constraints
  22. 22. © agileSEQUENT, Inc – All rights reserved Each Use Cases can further described in four levels of detail Use Case forms • Description of a specific path (driven by intent) – written from an actor’s point of view • List of steps required to accomplish Use Case • Each step – simple declarative statement • Describes intent, actions, expected parameters, expected results, responsibilities of platform and other products’ components Scenario   Summary (required) - General descriptions and overviews of system functionality and/or business processes   Core (required) - Descriptions of users and tasks, how they interact with the system - Descriptions of specific workflows   Supporting - Descriptions of lower-level activities used to complete parts of the Use Case   Internal - Descriptions of behaviors and interactions between internal system components
  23. 23. © agileSEQUENT, Inc – All rights reserved Let’s summarize all the building blocks …. Building initial product definition   The Registration process (new company / customer setup) might be better managed as a part of Product Platform – shared capability   Two major components have been identified:   Manage Companies, Manage Contracts   Manage Companies component has these features:   Create New Company, Update Company, Deactivate Company, Delete Company   Create New Company feature has these functions:   Specify Name, Specify # of Org Levels   Manage Contracts component has these features:   Define Licensing Models, Select Licensing Model
  24. 24. © agileSEQUENT, Inc – All rights reserved … and build initial Registration product definition Building initial product definition Product Platform  Registration Registration Manage Companies Manage Contracts Manage Notifications Manage Users Authenticate Users Log Activity Component Model Manage Companies FeaturesComponent • Create new Company • Update Company • Deactivate Company • Delete Company Functions • Specify name • Specify # of org. levels • Display all “children” units • Specify names for all units • Specify legal addresses • Specify contact information • Define contracts (passed to Manage Contracts) • Update addresses • Update contacts Manage Contracts • Define licensing models • Define contracts • Specify licensing attributes • Name / save licensing model • Select licensing model • Modify licensing attributes
  25. 25. © agileSEQUENT, Inc – All rights reserved Once functional decomposition is complete, dependency assessments (between functions) must be performed Functional dependency assessment 1.  Dependencies between different components in the same product 2.  Dependencies between different components in different products 3.  Dependencies between product components and platform components 1 2 3
  26. 26. © agileSEQUENT, Inc – All rights reserved Product Description Datasheet is the most critical document created during early product definition activities Critical Collateral created Manage Companies FeaturesComponent • Create new Company • Update Company • Deactivate Company • Delete Company Functions • Specify name • Specify # of org. levels • Display all “children” units • Specify names for all units • Specify legal addresses • Specify contact information • Define contracts (passed to Manage Contracts) • Update addresses • Update contacts Company Registration – Release 1.0 • NEW: Support for licensing models • NEW: Support for distribution locations • NEW: Support for contracts at any organizational level Notes  Component / Feature / Function decomposition process creates foundation for the Product Description Datasheet (PDS)  PDS is used to create other product launch collateral:   Competitive analysis briefs   User Guide changes   Training Guides   Deployment Guide
  27. 27. © agileSEQUENT, Inc – All rights reserved Product Definition Datasheet is used to create other, critical product collateral … Additional collateral created during product management PDS Product Definition Datasheet Product Release Notes • Audience: internal only • Built incrementally during development • Functionality delivered and NOT delivered • Known workarounds How PDS is used • Functional reference Product Technical Guide • Audience: product architects & customer support • Overview of product architecture • Internal workflows • Functional dependencies How PDS is used • Functional reference Product User Guide • Audience: actual users of the product • Descriptions of functionality • Common business scenarios • Instructions How PDS is used • Functional reference
  28. 28. © agileSEQUENT, Inc – All rights reserved Product Definition Datasheet is used to create other, critical product collateral … Additional collateral created during product management PDS Product Definition Datasheet Product Trainer Notes • Audience: trainers • Summarizes new features & demonstrations • Functionality delivered and NOT delivered • Instructions how to explain new features How PDS is used • Functional reference Product Deployment Guide • Audience: adoption consultants • Summarizes new features and functionality • Content spec. changes & migration options • Initial setup requirements How PDS is used • Functional reference Product Marketing Collateral • Descriptions of functionality • Competitive analysis How PDS is used • Functional reference

×