|
|
|
|
|
February 18; updated 15 Feb 2025 Authored by: |
Purpose
To define Best Practices in documenting Laboratory
Informatics Product requirements during a project with sustainability in mind
for the future.
Background
PMI / PMBOK: Knowledge Areas and Process Groups
As per The Standard for
Project Management and A Guide to the Project Management Body of Knowledge
(PMBOK® Guide), Requirement management falls under the Knowledge Area of
Project Scope Management.
The Outputs of planning being
Requirements documentation and Requirements traceability matrix.
The PMBOK states, “The
requirements management plan is a component of the project management plan that
describes how requirements will be analyzed, documented, and managed. “
PMI / PMBOK: Requirements Management
Within the Process Groups, Requirements Management includes
activities of Requirements analysis and Requirements monitoring and
controlling. As per the PMBOK:
“Requirements analysis. This domain focuses on examining,
decomposing, and synthesizing the elicited information into an actionable set
of requirements that fulfill the stated goals and objectives.
Requirements monitoring and controlling. Requirements are
continually traced, monitored, and controlled to ensure the product scope is
continually managed throughout the project and changes to the requirements are
placed in scope only when approved.”
Laboratory Informatics
As defined on the website Wikipedia (February 2021):
“Laboratory informatics is the specialized application of
information technology aimed at optimizing and extending laboratory
operations.[1] It encompasses data acquisition (e.g. through sensors and
hardware[2] or voice[3][4][5]), instrument interfacing, laboratory networking,
data processing, specialized data management systems (such as a chromatography
data system), a laboratory information management system, scientific data management
(including data mining and data warehousing), and knowledge management
(including the use of an electronic lab notebook).”
Scope
In Scope
This paper is meant to address
the output of the Planning Process Group and how requirements are documented,
and managed.
Out of Scope
· Project
specific requirements not addressing Product requirements
· Justification
for the documenting requirements and traceability
· The
important element of requirement elicitation
· The
development of preceding User stories and Use cases
Requirement Details
Requirements need to be SMART, that is:
· Specific
· Measurable
· Attainable
(appropriate, actionable, achievable)
· Realistic
· Testable
and Traceable
Considerations
Focus on Value
The current thinking is to not overdo or underdo
documentation but develop, requirements that just meet the need. Focus on
developing light weight requirements. Will it be used? Who will use it?
Basically, is there value in producing an artifact.
Approaches
Whether Predictive, Iterative. Incremental, Agile or Hybrid,
there needs to be some way to document “requirements”. These may take many
formats. The format should depend on the situation.
; PMBOK version 6 and Agile Practice Guide
PMBOK version
6 and Agile Practice Guide
Visual Representations
A large percentage of people interpret visual information faster.
Visual models are highly beneficial. Use visual models to support
BA for Practitioners Practice Guide; https://www.pmi.org/
Process
Use progressive elaboration. Start high-level and progressively
elaborate to different levels.
In general terms: Vision > User Story > User
Requirements > Use Cases and/or Functional Requirements > Detailed
Specifications
Level 1
The problem that is trying to be solved or vision.
Develop a high level process diagram or an Agile Epic.
Level 2
Breakdown the high level into a series of lower level items.
Provide Business Process modeling or create a series of User
Stories.
Level 3
Breakdown the lower level items into an individual user requirements.
Develop the business requirements that are needed.
Level 4
Breakdown business requirements into Functional Requirements.
Functional Requirements may be a combination of visual and
text. Individual Functional Requirements, Use case diagrams and/or Use Cases.
Level 5
Document Detailed Specifications for a technical perspective
of the system.
References
The Project Management Body of
Knowledge (PMBOK), https://www.pmi.org/
Requirements Management Practice
Guide; https://www.pmi.org/
BA for Practitioners Practice Guide; https://www.pmi.org/
Business
Analysis 2016: Modern Requirements – Getting High Quality Requirements Done
Fast - Angela Wick
https://en.wikipedia.org/wiki/Laboratory_informatics
Studies
Confirm the Power of Visuals to Engage Your Audience in eLearning; www.shiftelearning.com
No comments:
Post a Comment