Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Way of the Quality Warrior
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • Reliability Engineering for Heavy Industry
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Robert Allen Leave a Comment

Requirements versus Stories

Requirements versus Stories

In this article, we’ll compare and contrast the definition of a requirement, with a ‘story’, which is used in agile/scrum.

Both requirements and stories establish a clear understanding of customer needs in the context of desired functionality.

The framework for each is somewhat different, however.

Recall the definition of a requirement:

…a requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”

The framework of a story is as follows:

“as a <user> I want <action> so that <benefit>”

It can be seen that a requirement is somewhat more specific to the product design (or business sub-process).  The specific desired output @ input conditions is established.

In contrast, the story is a higher-level ‘need’ and benefit statement surrounding the desired functionality and is more closely associated with the ‘voice-of-customer’.  Stories can therefore be an important tool in virtually any project (including product development projects), even if agile methodologies aren’t used.

The example we’ll use is along the lines of a business requirement….let’s say we want to extract business intelligence data to provide a key performance indicator measurement (KPI): productivity.

The story might be:  As a functional manager, I want to be able to view a weekly measurement of productivity including performance trends.  I also want to be able to determine productivity trend drivers so countermeasures can be identified, and productivity improved accordingly.

A corresponding requirement might be somewhat more descriptive as follows:

“The productivity KPI view shall provide productivity (volume/work hours) where volume is defined as number of items and work hours is determined by time clock readings.  The view shall also include volume separately (since volumes can affect productivity).”

Also:  “Drill-down views shall show productivity of individuals by week and by day…etc.”  (Note: here we’re also defining ‘use cases’ which might also be considered a form of requirement as long as they’re output/input oriented).  Of course, the requirement might also include a graphic and/or the requirement can be validated with a working model of the productivity KPI tool being developed.

So the requirement is somewhat more specific, identifying the output (trend metric) and inputs (volume = items and time clock hours).  However, it fits with, and enables the benefit of the described by the story.

Stories and requirements are both quite useful.  Properly applied stories and requirements enables good critical thinking and the clarity that is necessary for high-quality project results.

Filed Under: Articles, on Leadership & Career, Product Development and Process Improvement Tagged With: agile, agile product development, customer value, Lean Project Management, New Product Development, PLC process, product development, project governance, Project Management, scrum

About Robert Allen

Robert Allen has over 25 years of professional experience in the areas of product development, process improvement and project management. Rob was a key contributor to numerous deployments of lean sigma and project management organizations, most notably with Honeywell and TE Connectivity. Included in Rob’s experience are multiple certifications and over 25 years of practice in the development, teaching, execution, and leadership of product lifecycle, lean product development, DFSS, lean six sigma, project management, systems engineering and supply chain.

« 10 Things Your Equipment Operators Can Do Today To Improve Reliability
Small Satellites, Emerging Technology and Big Opportunities (part three of seven) – No, we really mean ‘Mission Assurance’ »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Rob Allen
in the Product Development and Process Improvement series

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Join PD&PI

Your email is safe and the opt-in here provides your permission to send messages concerning the PD&PI article list plus special announcements. Privacy Policy

Recent Posts

  • test
  • test
  • test
  • Your Most Important Business Equation
  • Your Suppliers Can Be a Risk to Your Project

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy