Accendo Reliability

Your Reliability Engineering Professional Development Site

  • About
    • Adam Bahret
    • Alex Williams
    • Andre Kleyner
    • Anne Meixner
    • Arthur Hart
    • Ash Norton
    • Carl Carlson
    • Chris Jackson
    • Chris Stapelmann
    • Dennis Craggs
    • Dev Raheja
    • Doug Lehr
    • Doug Plucknette
    • Fred Schenkelberg
    • George Williams
    • Gina Tabasso
    • Greg Hutchins
    • James Kovacevic
    • James Reyes-Picknell
    • Joe Anderson
    • John Paschkewitz
    • Katie Switzer
    • Kevin Stewart
    • Kirk Gray
    • Les Warrington
    • Mike Konrad
    • Mike Sondalini
    • Nancy Regan
    • Perry Parendo
    • Philip Sage
    • Ray Harkins
    • Rob Allen
    • Robert (Bob) J. Latino
    • Robert Kalwarowsky
    • Ryan Chan
    • Shane Turcott
    • Steven Wachs
    • Tim Rodgers
    • Usman Mustafa Syed
  • Reliability.fm
    • Dare to Know
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Maintenance Disrupted
    • Practical Reliability Podcast
    • Reliability Matters
    • Masterminds in Maintenance
    • Accendo Reliability Webinar Series
    • Asset Reliability @ Work
  • 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
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • Maintenance and Reliability
      • Plant Maintenance
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The RCA
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Musings on Reliability and Maintenance Topics
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside FMEA
      • Testing 1 2 3
      • The Manufacturing Academy
      • Reliability Reflections
  • eBooks
    • Reliability Engineering Management DRAFT
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Groups
    • Reliability Integration
    • Mastermind
    • Study Groups
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • SPC-Process Capability Course
    • Reliability Centered Maintenance (RCM) Online Course
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • 5-day Reliability Green Belt ® Live Course
    • 5-day Reliability Black Belt ® Live Course
    • CRE Preparation Online Course
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home
Don’t show this message again.

Cookies

This site uses cookies to give you a better experience, analyze site traffic, and gain insight to products or offers that may interest you. By continuing, you consent to the use of cookies. Learn how we use cookies, how they work, and how to set your browser preferences by reading our Cookies Policy.

by Robert Allen Leave a Comment

Demystifying Business Requirements

Demystifying Business Requirements

In a previous article, we compared and contrasted the definition of a requirement, with a ‘story’, which is used in agile/scrum.  In that article, we stated:  “requirements and stories establish a clear understanding of customer needs in the context of desired functionality”.

What if we want to establish a clear understanding of a customer’s needs in the context of desired business functionality?  The customer can be an internal or external customer, business functionality can be a business process (IT-enabled or otherwise).

Also recall the definition of a requirement:  A requirement defines “what the product (or process) design shall provide <output> at operating conditions <input>”.

Let’s start with a new business process….an example would be to get a supplier-provided part to the warehouse, and then to the manufacturing shop floor:

It can be seen that a business requirement is:

“Procurement shall provide supplier parts to the warehouse on or before the order fulfillment date as determined by material planning, using suppliers selected by sourcing”

(It’s important to remember we’re designing a new business process in this example, not troubleshooting an existing one…)

Arguably, there are organizational design constraints embedded in this requirement, since the input organizations (material planning, sourcing) are defined.  Regardless, this requirement statement can be validated by each department leader, and the architecture/design (how the requirement will be met) can be determined by asking the following fundamental questions:

  • Is the output measurable (at the warehouse)? We will want to know the actual performance relative to the requirement (on or before the order fulfillment date).
  • Is the suppliers order fulfillment date mutually understood and agreed by both the supplier and material planning?
  • Does sourcing acknowledge they are responsible for selecting suppliers that are able to fulfill orders as scheduled?
  • Does material planning acknowledge they are responsible for order fulfillment dates that are accurate, realistic and unambiguous?
  • Are the inputs measurable (supplier performance, material planning performance)?
  • Who is accountable? How are resource constraints or skillsets in each of the departments effectively managed?  What is the best reporting structure to enable this?
  • How can the business requirement be met with a minimal amount cost?

It is also apparent some enterprise resource planning IT-system requirements and stories can be derived from the business requirement and detailed information flow processes.

This article demonstrates (1) how a business process comes first and (2) how business requirements can be developed based on internal / external customer needs and (3) how lower-level business, organizational, key performance indicators, and IT system requirements can be derived.

Well written business requirements can proactively ensure an efficient business process and IT-enablement.

Filed Under: Articles, Product Development and Process Improvement Tagged With: business requirements, IT enablement, Project Management, Project Management Process

« Using a Strip Chart
Where to Take an Oil Sample »

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

Stay in touch with Rob and improve your product and processes.

You will receive occasional emails with announcements, recent articles, and maybe a question or two.

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

  • Establishing Fixed Time Maintenance Intervals
  • Risk-Based Analysis of Random Variables
  • The Basics of PM Programs
  • The Power of a Sample
  • Taking Care of Our Equipment Requires More than just Proactive Maintenance

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