Storyboards and Use Cases – part 1: effectively capturing PLM requirements

PLM business requirements are typically process and outcome driven; they describe an operational intent in the form of expected capabilities and functionalities—complemented by non-functional requirements overlaid to storyboards, based on data volume and access frequencies. On the one hand, building requirements from current AS IS processes might lead to miss-opportunities or miss-alignment with PLM tools, whereas on the other hand “blue sky thinking” or building requirements from scratch might require iterative re-alignments to derive future TO BE processes that are supported by the selected platform. This is clearly a matter of trade-offs between legacy and new processes, legacy and new platforms, change mitigations and data migration, solution adaptation and training needs, deployment feasibility and business adaptability to change.

In this post, we explore how to effectively capture PLM requirements in the form of storyboards and use cases, which in turn will become the foundation of the solution design and deployment.

Enabling effective PLM delivery

Every PLM practice will have its own definition of a business process (a.k.a. workflow), a user method, a use case, a storyboard, a test case, etc. These artefacts are essential elements used to assess business needs, input to design, configuration and validation of the solution; they also contribute to building training material and communicating about the change. Broadly speaking, such artefacts can be defined as follows:

  • Storyboards are high-level block diagrams illustrating the bird’s-eye view of a given capability set to achieve specific business outcomes; they can be more or less detailed, focusing on pain points or suboptimum areas, completed with placeholders to describe what needs to be changed, configured or customized. They can be used as communication tools to flag expected improvements, gaps and areas where more analysis is needed across a wider subject matter or scope. Eventually, larger epic stories can be broken down as required in a number of smaller storyboards.
  • Use cases describe repeatable series of actions or interactions between systems and users, flow of events to achieve a certain activity or task; some steps might be manual while others can be automated through integration or system batch job. Use cases are typically converted to test cases when times come to validate the solution, including negative testing (also covering things that can go wrong or are not allowed).
  • User methods (or workflows) illustrate operational steps taken by a user to complete an activity; retrospectively, multiple methods and use cases can be combined in the context of a given storyboard. Methods and storyboards are directly used in training materials, even when they represent out-of-the-box processes which will be integral to the user education curriculum.

Business communication at all levels is critical to deliver effective PLM delivery: from Key Users to Executive Sponsors, internal support functions and suppliers. Business value can be validated through experimentation and testing following agreed storyboards and use cases—supporting business engagement and detailed method confirmation during User Acceptance Testing (UAT cycles).

Communicating upstream with the business

Storyboards and use cases are great visual aids to communicate requirements and progress through design solutions committed to the business, including status reviews with Change Leads and Key Users.

Ultimately, storyboards can combine swimlane activity flows representing “day-in-a-life” of a specific function, during their interactions with others and using a number of tools and processes. They need to be created from project outset and refined through ongoing conversations between end-users and implementation teams. Arguably, solution elements might not cover all aspects of storyboards; and equally, storyboards might not cover all requirements of specific solution elements. Storyboards can clearly be used for expectation setting with the business, build expectations for both current and later stages of the PLM roadmap and change journey.

Armed with such artefacts, business stakeholders can appreciate the convergence towards alignment on the solution design and expected functional outcomes—without having to read large blueprint documents or ready-made generic training materials which can be difficult to consume without contextualization.

Communicating downstream with IT and technical implementation teams

In parallel, technical teams and Solution Architects can create solution design specifications based on this input and continue to improve and update as the PLM project progresses through its delivery phases or sprints.

Functional and non-functional requirements from the business are captured through discovery and design workshops as a framework for mutual alignment on the solution to be adopted or developed.

  • Typically, storyboards do not cover integration testing, but they provide business context (alignment with outcome and strategy).
  • Use cases / test cases must be exhaustive and cover all bases relating to a goal.
  • Use cases that are not met during a given project iteration, sprint or phase can be carried over to the next via a backlog (as a way to plan future work, and pending that the business approves).

Clearly, developing and maintaining credible and accurate storyboards and use cases contribute to building trust with the business; such documentation does not have to be complex and can be broken down on management blocks. Starting with generic storyboards and use cases can be useful; they however need to be quickly and continuously adapted to the business language and requirements to become and remain relevant.

In the next part of this two-part post series, we will debate how important these artefacts are to foster business change adoption, confirm benefit realization, and training needs; we will also cover how they can also contribute to agile delivery.

What are your thoughts?

Original Publication by:

Momentum PLM and written by Lionel Grealou

Share this:

A profile picture for Lionel Grealou

Lionel Grealou

8th September


Latest Jobs

Architect, Windchill PLM

West Chester, PA, USA Competitive Permanent

Posted on behalf of

Johnson & Johnson

About the job Job DescriptionJohnson & Johnson Technology (JJT), the Enterprise Technology group supporting all business functions under Johnson & Johnson is currently recruiting for an Architect,...

PLM Analyst

Manhattan Beach, CA, USA Competitive Permanent

Posted on behalf of


About the job Description: Company Overview Fisker Inc. is a design led pioneering mobility technology company researching, developing and producing next generation electrically power...

Application Consultant - Data Management Solutions

Quakertown, PA, USA Competitive Permanent

Posted on behalf of

Synergis Engineering Design Solutions

About the job Synergis Technologies, the region’s leader in data management, engineering, architectural, civil and manufacturing design solutions is searching for an engineering professional who is...

Looking for people to join your team?

Advertise your role with Momentum PLM. Get Started 

Looking to become a contributor?

Submit an article to Momentum PLM.  Get Involved 

Our Contributors

See the minds behind Momentum PLM.  Learn More 

Meet the Vendors

Read up on the latest vendor updates  Learn More 

Get the latest PLM updates in your inbox

Subscribe to our newsletter

Email Address


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

By submitting your email address and any other personal information on the website, you consent to it being collected, held, used and disclosed in accordance with our Privacy Policy.