Introduction to the Webinar

In this section, Mark Griffin introduces the webinar titled "Four Reasons Why Requirements Are Hard." He welcomes the audience and introduces Earl, the speaker for the webinar.

Mark's Introduction

• Mark Griffin is the host of the Constructs Inspect and Adapt podcast.

• The webinar is titled "Four Reasons Why Requirements Are Hard."

• Earl, a technical service provider and CTO at Constructs, will share insights into his decades of work in the requirement space.

• The focus will be on making requirements less challenging.

Discussion on Working with Humans

In this section, Mark and Earl discuss their long-standing professional relationship and how working with humans can make requirements challenging.

Working with Humans

• Mark and Earl have been colleagues for almost 16 years.

• Earl mentions that working with humans is fascinating but also challenging.

• Requirements are more of a human issue than a technical issue.

• Interacting with humans requires finding new ways to communicate effectively.

Introduction to Earl's Background

In this section, Earl provides an introduction to his background and experience in the requirement space.

Earl's Background

• Earl is a csdp (Certified Software Development Professional).

• He is Constructs' CTO and a senior fellow at Constructs.

• Earl has extensive experience as a manager, systems analyst, QA representative, process architect, and consultant.

• He has worked in various industries such as Telecom, computer hardware and software, Pharmaceuticals, medical devices, oil and gas retail, etc.

Four Reasons Why Requirements Are Hard

In this section, Earl discusses the four reasons why requirements are hard and provides an overview of each reason.

Reasons Why Requirements Are Hard

• Requirements involve people, making them complex and messy.

• Defining requirements is often confusing, with many people having different interpretations.

• Requirements are contextual and depend on various factors.

• Requirements have multiple parts, and important aspects are often overlooked.

Webinar Logistics and Interaction

In this section, Earl explains the logistics of the webinar and encourages audience interaction.

Webinar Logistics

• The webinar includes a question button for asking questions.

• Feedback tools are available for providing feedback during the session.

• The talk is being recorded.

• Adjust video settings to view the full 16 by 9 aspect ratio if needed.

Reason 1: Requirements Involve People

In this section, Earl delves into the first reason why requirements are hard - they involve people.

Reason 1: Requirements Involve People

• Communicating requirements between individuals can be challenging due to differences in understanding and interpretation.

• Effective communication requires feedback loops to ensure accurate understanding.

• Humans tend to focus on solutions rather than clearly defining problems, which can lead to misunderstandings.

Communication Challenges in Requirement Gathering

In this section, Earl discusses communication challenges that arise during requirement gathering.

Communication Challenges

• Message sent does not always equal message received due to various factors like noise in transmission or misinterpretation of words.

• Feedback is crucial for truly understanding what the other person intends to convey.

• Iterative communication involving feedback helps bridge gaps in understanding between individuals.

Understanding the Human Aspect of Requirements

In this section, the speaker discusses how human beings tend to provide solutions rather than clearly stating the problem when it comes to requirements. They also highlight the importance of considering the competency and level of detail required based on different factors.

The Tendency for Solutions Instead of Problems

• Stakeholders often present solutions rather than clearly articulating the underlying problem.

• Non-designers may not be proficient in designing technology implementations, leading to poor designs.

• Example: A company had a VP of marketing who was a brilliant UI designer, but others in marketing tried to imitate their skills, causing issues.

Competency and Detail Requirements

• The level of technical competency and understanding of the business domain affects the amount of detail needed in requirements.

• More competent individuals require less detail as they can grasp concepts quickly.

• Startups with a close-knit team may have an intuitive understanding, but introducing new members or external vendors requires more detailed documentation.

• Criticality, team size, distance (physical or cultural), and regulatory factors also influence the need for more detailed requirements.

Challenges with Natural Language

• Natural language tends to be verbose and imprecise, leading to vague and ambiguous requirements.

• Words can have multiple meanings, causing confusion.

• Some attempts have been made to address this issue through more precise languages or models.

Planning for Iteration

• To mitigate challenges caused by human aspects in requirements gathering, it is important to plan for iteration and feedback loops.

• Iteration helps clarify understanding between development teams and stakeholders.

Tips for Dealing with Human Aspects in Requirements Gathering

This section provides practical tips for managing the complexities associated with human aspects in requirements gathering. It emphasizes iterative approaches and effective communication strategies.

Embrace Iteration

• Plan for iterative cycles to refine and improve requirements understanding.

• Iteration allows for learning and better alignment between development teams and stakeholders.

Effective Communication Strategies

• Use clear and concise language to avoid ambiguity.

• Encourage open communication channels for feedback and clarification.

• Foster a collaborative environment where stakeholders feel comfortable expressing their needs.

Consider Different Perspectives

• Recognize that different individuals have varying levels of technical competency and domain knowledge.

• Tailor the level of detail in requirements based on the audience's understanding.

Documentation Practices

• Balance the need for detail with the risk of information overload.

• Provide sufficient context, especially when there are physical or cultural distances between team members or vendors.

Conclusion

The speaker concludes by emphasizing the importance of iterative approaches, effective communication, considering different perspectives, and finding a balance between detail and clarity in requirements gathering.

Iteration and Learning in Methodologies

The speaker discusses the importance of iteration and learning in different methodologies, such as waterfall and agile. Iteration through modeling tools like UML helps in the early stages of waterfall processes, while agile methodologies focus on iterating through working software.

Importance of Iteration in Waterfall and Agile Methodologies

• In waterfall processes, iteration occurs through modeling using precise languages like UML.

• Agile methodologies emphasize iteration through working software.

• Waterfall processes iterate early via modeling, while agile methodologies iterate through small increments of working software.

Planning for Iteration

• It is crucial to plan for iteration in both waterfall and agile methodologies.

• Many agile teams overlook the need for an explicit iteration plan.

• Planning to iterate allows for learning from mistakes and improving the solution.

Challenges with Defining Requirements

The speaker highlights challenges faced when defining requirements, including ambiguity and lack of helpful definitions. Common definitions often fail to provide clarity or guidance in determining what constitutes a requirement.

Ambiguity in Requirement Definitions

• Existing definitions of good requirements being well-written and unambiguous are not helpful.

• Different individuals may have varying interpretations of what constitutes detail or ambiguity.

Lack of Helpful Definitions

• Official definitions do not effectively assist organizations in defining requirements.

• The distinction between "what" versus "how" is not practical or helpful when defining requirements.

• Defining subtypes or types of requirements is also challenging due to the use of natural language.

A More Helpful Definition

• A more practical definition proposed by the speaker is that a requirement is a decision imposed on implementation.

• Requirements represent decisions made about how something should be built or function.

Summary

The transcript covers two main topics: iteration and learning in methodologies, as well as challenges with defining requirements. In terms of iteration, the speaker discusses the importance of iteration in both waterfall and agile methodologies. In waterfall processes, iteration occurs through modeling using precise languages like UML, while agile methodologies emphasize iteration through working software. Planning for iteration is crucial to learn from mistakes and improve solutions.

Regarding requirements, the speaker highlights challenges faced when defining them. Existing definitions often lack clarity and fail to provide practical guidance. Ambiguity in requirement definitions and difficulties in defining subtypes or types of requirements are common issues. The speaker proposes a more helpful definition that considers requirements as decisions imposed on implementation.

Overall, understanding the significance of iteration and addressing challenges in requirement definition can contribute to more effective project management and successful outcomes.

The Importance of Decision-Making in UI Design

This section discusses the significance of decision-making in UI design and the role of different individuals involved in making these decisions.

The Right Person to Make UI Decisions

• The VP, who is a UI Guru, is considered the right person to make UI decisions.

• However, the marketing people working under the VP lack the skills and knowledge to make good UI decisions.

• It is crucial to determine if the person making the decision is indeed the right person for it.

Understanding the Scope of Decisions

• When making decisions, it is essential to clarify what problems need to be solved and whether those needs are known.

• Decisions can be about solutions or consistent with other previous decisions.

• Determining the scope of a decision helps understand its significance and impact.

• Timing also plays a role in decision-making. It's important to consider if a decision needs to be made immediately or if more information is required before deciding.

Making Informed Decisions

• Agile methodology emphasizes making decisions at the last responsible moment when sufficient information is available.

• Understanding why decisions are being made helps determine their purpose, such as writing code or assessing project size.

• Content availability also influences decision-making. Sufficient content should be present before proceeding with implementation.

Different Levels and Types of Decisions

• Various types of decisions exist, including those related to problem-solving and different scopes.

• Decision levels range from organization-wide mission-level decisions to specific goal-oriented ones.

• For example, in a banking context, managing money could be one goal with various workflows like depositing or withdrawing money.

Requirements vs. Design Decisions

• Requirements are contextual and can sometimes overlap with design decisions.

• Douglas Adams' Hitchhiker's Guide to the Galaxy illustrates how everything we know about Earth can be seen as design rather than requirements.

• Distinguishing between problem space (requirements) and solution space (design) helps navigate decision-making.

The Missing Link: Decision Scopes

• The concept of decision scopes is often overlooked but crucial in understanding the decision-making process.

• Decision scopes can range from wide to narrow, depending on the impact and focus of the decision.

Different Kinds of Decisions in Problem-Solving

This section explores different types of decisions involved in problem-solving and highlights the importance of recognizing them.

Problem-Solving Decisions

• Decisions are made regarding what problems need to be solved.

• Different kinds of decisions exist, including those related to problem identification and scope determination.

Solution-Solving Decisions

• In addition to problem-solving decisions, there are also decisions about how to solve a given problem.

• These decisions involve choosing topologies, building systems, dividing into subsystems or components, and reaching unit-level solutions.

Viewing the World as a Decision-Making Process

• Recognizing that the world operates as a decision-making process helps categorize different types of decisions.

• Teaching others about these distinctions enables better understanding and classification of various decision types.

Requirements vs. Design: A Shortened Perspective

• The distinction between requirements and design can sometimes be simplified by considering "what" vs. "how" decisions.

• While requirements focus on what problems need to be solved, design decisions revolve around how to solve those problems effectively.

Contextual Nature of Requirements and Design

This section delves into the contextual nature of requirements and design decisions, using Douglas Adams' example as an illustration.

Requirements vs. Design Spaces

• Requirements are contextual and can vary based on individual perspectives.

• Differentiating between requirement spaces (problem space) and solution spaces (design space) helps navigate the decision-making process.

The Earth as Design

• Douglas Adams' Hitchhiker's Guide to the Galaxy presents an example where everything we know about Earth is considered design rather than a requirement.

• The question of what problem Earth was built to answer highlights the contextual nature of requirements and design.

Conclusion

This section concludes the discussion on decision-making in UI design, emphasizing the importance of recognizing different types of decisions and understanding their scopes.

Recognizing Decision-Making as a Process

• Viewing the world as a decision-making process helps identify and categorize various types of decisions.

• It enables better understanding and classification of problem-solving and solution-solving decisions.

Importance of Decision Scopes

• Decision scopes, ranging from wide to narrow, play a crucial role in understanding the impact and focus of each decision.

• Recognizing decision scopes enhances clarity in decision-making processes.

Contextual Nature of Requirements and Design

• Requirements and design decisions are contextual, varying based on individual perspectives.

• Distinguishing between requirement spaces (problem space) and solution spaces (design space) aids in navigating decision-making effectively.

New Section

In this section, the speaker discusses the difference between high-level and low-level requirements and emphasizes the importance of making all decisions well.

Understanding High-Level and Low-Level Requirements

• High-level requirements have a broad scope and impact multiple routines or functions.

• Low-level requirements have a narrow scope and only affect one routine or function.

• The decision scope determines whether a requirement is high or low level, not how vague it is.

• Both high-level and low-level requirements should be measurable, testable, and unambiguous.

New Section

This section explores the concept of spaces in relation to requirements. The speaker explains that understanding what you've been asked to build helps determine the spaces involved.

Spaces in Requirements

• Spaces refer to the context in which requirements exist.

• When building something, it interacts with external factors such as other systems, stakeholders' needs, compliance, etc.

• The problem space refers to what you've been asked to build, while the solution space refers to how you design it.

• Understanding your box (boundary) helps identify problem decisions versus solution decisions.

New Section

Here, the speaker further explains the concept of problem space and solution space. They highlight that individual decisions can become either requirements or design based on their relationship with the product's boundary.

Problem Space vs Solution Space

• The problem space is outside the box (boundary) where you determine what problems you're trying to solve with your product.

• The solution space is inside the box (boundary) where design decisions are made on how to build it.

• Decisions within the red box are typically considered design decisions.

• Decisions outside the red box are related to solving problems or fulfilling needs.

New Section

The speaker discusses the importance of understanding the boundary of your product to differentiate between requirements and design decisions.

Boundary and Product Understanding

• The boundary of your product determines whether a decision is a requirement or a design decision.

• Requirements are about what problems you're trying to solve with your product.

• Design decisions are about how you're going to build it.

• It's crucial to define the boundary of your product before evaluating the quality of requirements or design decisions.

New Section

This section illustrates how decisions can change from being solution decisions to becoming requirements when subcontracting or involving external parties.

Impact on Decisions

• Decisions made within your box (boundary) are specific to your solution.

• When subcontracting or involving external parties, their box becomes smaller, and the same decision may become a requirement for them.

• Individual decisions are space agnostic; they become requirements or design based on the boundary of the product.

New Section

The speaker emphasizes that understanding the boundary is essential for evaluating the quality of requirements and design decisions.

Evaluating Requirements Quality

• The distinction between requirements and design depends on understanding the boundary of your product.

• Without knowing the boundary, it's challenging to assess whether decisions are inside or outside, requirements or design.

• Defining the context and drawing out the boundaries helps clarify what interactions need consideration.

New Section

In this section, practical tips are provided for helping organizations determine their boundaries and understand their contexts.

Tips for Determining Boundaries

1. Draw Your Context:

• Place your boundary in the middle and identify who/what interacts with it.

• Consider different consumers' needs and expectations related to the product.

2. Pretend Technology Isn't the Solution:

• Focus on understanding the problems you're trying to solve rather than getting caught up in technological solutions.

New Section

The speaker concludes by emphasizing the importance of defining boundaries and considering problem spaces and solution spaces when evaluating requirements.

Importance of Boundaries

• Defining boundaries is crucial for intelligently discussing requirements and design decisions.

• Understanding problem spaces and solution spaces helps differentiate between requirements and design.

• Evaluating decision quality requires a clear understanding of the boundary and context of your product.

The Importance of Context and Acceptance Criteria in Requirements

In this section, the speaker emphasizes the significance of considering context and acceptance criteria when defining requirements. They explain that these two elements help ensure that problem decisions are well-specified and not just solution decisions.

Understanding Context and Separating Requirements from Design

• The speaker suggests separating out the context to understand what is a requirement and what is design.

• By understanding the context, one can better identify the problem decisions that need to be made.

Three Parts of a Good Requirement

• A good requirement consists of three parts: context, function, and acceptance criteria.

• The context provides information about who is involved and what they are trying to achieve.

• The function describes what needs to be done or achieved.

• Acceptance criteria define how the function should be performed in an acceptable way.

Challenges with Acceptance Criteria

• Acceptance criteria are often misunderstood or not properly defined.

• Many people mistakenly treat acceptance criteria as additional functions rather than specifying what makes a function acceptable.

• It is important to clearly define acceptance criteria, such as time constraints or quality standards.

Incomplete Decision-Making

• Often, only one part of a requirement is captured, leaving out the context and acceptance criteria.

• Simply writing user stories without considering all three parts does not result in complete decision-making.

Examples of Acceptance Criteria

In this section, the speaker provides examples of acceptance criteria using the analogy of making toast. They highlight how acceptance criteria go beyond functional requirements by specifying factors like time constraints and quality standards.

Making Toast Example

• When making toast, simply stating the steps to make toast is not enough.

• Acceptance criteria for making toast include factors like time constraints and desired level of browning.

• The acceptance criteria define what makes the function of making toast acceptable.

Importance of Clear Acceptance Criteria

• Acceptance criteria should be clearly defined and inherited from higher-level requirements.

• Poorly defined or missing acceptance criteria can lead to misunderstandings and unsatisfactory implementations.

Importance of Well-Defined Requirements

In this section, the speaker emphasizes the importance of well-defined requirements at the top level. They explain that when top-level requirements are well-specified, they tend to flow down effectively, ensuring better decision-making throughout the project.

Focusing on Top-Level Requirements

• It is crucial to focus on a few key requirements at the top level and make well-informed decisions about them.

• When top-level requirements are well-defined, they guide decision-making throughout the project.

Challenges with Acceptance Criteria

• Many projects lack clear acceptance criteria at the top level, leading to incomplete decision-making.

• Capturing acceptance criteria at the high level helps ensure that all subsequent decisions align with overall goals and standards.

Understanding Acceptance Criteria

In this section, the speaker discusses the importance of acceptance criteria in software development and the challenges faced in defining them.

Simplifying Tips for Acceptance Criteria

• The speaker highlights the need to have all three parts of acceptance criteria: description, validation, and completion.

• Due to limited tools available for dealing with acceptance criteria, the speaker suggests using ISO 2510 as a reference guide.

• The speaker emphasizes the importance of identifying what customers will judge as acceptable when defining acceptance criteria.

• While there are many items on the list of acceptance criteria, only a few are crucial for positive value judgments.

Telling the Story for Better Requirements

This section focuses on how storytelling can help improve requirements gathering and understanding.

Using Storytelling for Requirements

• The speaker explains that telling a story can help bring out acceptance criteria and provide context that may be missing in written requirements.

• By engaging in conversations rather than simply documenting requirements, stakeholders can provide valuable feedback and ensure better understanding.

• Telling a complete story about how a function is used in different situations helps uncover more acceptance criteria and facilitates feedback.

Recap: Problems and Tips

This section summarizes the four problems discussed earlier and provides tips to address them.

Problems and Tips

• The four problems identified are people problem, definitional problem, contextual problem, and multiple parts problem.

• The speaker suggests planning for iteration throughout the project to avoid rework at the end.

• A helpful definition of requirements is viewing them as decisions that drive implementation.

• Considering the product boundary and using techniques like the magic garden gnome can help address contextual challenges.

• Storytelling can be used to drive out ambiguity and have richer conversations about multiple parts of a requirement.

The transcript provided does not specify the language, so I have assumed it to be in English.

Iterative and Incremental Requirements in Waterfall

The speaker discusses the importance of iteration and incremental development when working with waterfall requirements. They emphasize the need to have multiple models, such as use cases, domain models, activity models, and state charts, being built up incrementally. This iterative approach helps uncover individual system shell statements and allows for incremental review processes.

• Iteration through models is essential in waterfall requirements.

• Multiple models should be built up incrementally.

• Use cases, domain models, activity models, and state charts are examples of different types of models.

• Building these models incrementally helps discover system shell statements.

• Incremental review processes are important for feedback.

Working Space vs Repository in Waterfall

The speaker explains the concept of a working space versus a repository in the context of waterfall development. They highlight the importance of separating these two spaces to ensure efficiency and flexibility during the development process. The working space should be fast, easy to change, and dynamic, while the repository serves as a static place where the final document resides.

• Separating working space from repository is beneficial in waterfall development.

• Working space should be fast, easy to change, and dynamic.

• Repository is where the final document resides.

• Change control applies to the repository but not the working space.

Capturing Requirements with Distributed Teams

The speaker discusses different approaches for capturing requirements when working with distributed teams. They mention using online whiteboards and modeling tools like Miro to facilitate collaboration. In-person methods like using whiteboards or projectors can also be effective. Tablets with pens are recommended for dynamic drawing work.

• Online whiteboards and modeling tools like Miro can facilitate collaboration with distributed teams.

• In-person methods like whiteboards or projectors can also be effective.

• Tablets with pens are recommended for dynamic drawing work.

Dealing with Industry Standards in Requirements

The speaker explains how to handle industry standards in the requirements process. They suggest analyzing the standard and determining if it provides solution decisions or decision content. Solution decisions made by the standard should be labeled as such and included in the solution space. The reasons for following the standard should be evaluated, considering factors like market share, access to markets, and certification requirements.

• Analyze industry standards to determine if they provide solution decisions or decision content.

• Label solution decisions made by the standard and include them in the solution space.

• Evaluate reasons for following the standard, such as market share, access to markets, and certification requirements.

Importance of Problem Domain Knowledge

The speaker agrees that having people who understand the problem domain and iterating with them is crucial for developing software products. However, they note that not everyone has equal skill in diving into problems and switching between problem and solution spaces. Modeling is highlighted as a valuable skill that not everyone possesses.

• Understanding the problem domain and iterating with knowledgeable individuals is important for software development.

• Not everyone has equal skill in diving into problems and switching between problem and solution spaces.

• Modeling is a valuable skill that not everyone possesses.

Conclusion

In this transcript, several key points related to iterative and incremental development in waterfall requirements were discussed. The importance of building up multiple models incrementally was emphasized, along with separating working space from repository. Capturing requirements with distributed teams using online whiteboards or in-person methods was explored. Handling industry standards involved analyzing their content and evaluating reasons for following them. Lastly, having people with problem domain knowledge was deemed essential but not universally possessed by all individuals.

The Benefits of Agile Methodology

In this section, the speaker discusses the advantages of using agile methodology in software development.

Agile allows for feedback and iteration

• Agile methodology enables the delivery of working software to stakeholders for feedback.

• This approach allows for a wider skill band as it focuses on putting actual working software in front of people.

• Stakeholders can provide input and opinions on the software, leading to iterative improvements.

Understanding the problem before proposing solutions

• The speaker follows a model where they start with a solution because that's what stakeholders often want to discuss initially.

• They then explore the problem by asking variations of "why" and "who else" questions to understand its impact on others.

• By listening to stakeholders and understanding their perspective, they can guide them towards analyzing the real problem rather than just focusing on their proposed solution.

Removing ambiguity from requirements

• The key to removing ambiguity from requirements is accepting specific criteria.

• Using scales with different points helps clarify expectations. For example, determining how fast someone wants their toast can reveal technological limitations or further discussions about preferences.

• Having a clear understanding of the problem is crucial. Without it, any solution may seem equally valid.

User Stories as Requirements

In this section, the speaker discusses user stories and their role as requirements in agile development.

User stories can become requirements

• User stories contain three essential parts: the product owner telling the story, context, and function.

• While user stories can grow up to be requirements, they are not imposed until Sprint planning at the end of an iteration.

User stories focus on discussing problems

• User stories aim to encourage discussions about problems rather than jumping straight into solutions.

• However, getting people to talk about problems is challenging due to human complexity and resistance.

Challenges with Legacy Systems and Untangling Decisions

In this section, the speaker addresses challenges related to working with legacy systems and untangling decision-making processes.

Working without formal requirements

• The team of developers is configuring a new system without formal requirements.

• As a business analyst, there is no visibility into how decisions are being made.

• This lack of documentation makes requirements documentation and testing preparation nearly impossible.

Agile approach with feedback directly to developers

• The team seems to be following an agile approach by iterating on an as-configured solution and gathering feedback from users.

• However, the direct feedback given to developers bypasses the business analyst's involvement in understanding user needs and documenting requirements.

Lack of formalization and testing

• Without a formal requirements document, change requests become the primary means of capturing decisions.

• Testing becomes more challenging without clear specifications, requiring improvisation during development.

Please note that these summaries are based solely on the provided transcript.

Magic Gnome Technology and Collaboration

The speaker suggests that having access to "magic gnome technology" can help drive conversations with developers. They recommend learning in parallel with the developers to better understand their needs and requirements.

Using Magic Gnome Technology for Collaboration

• Having "magic gnome technology" allows you to focus on what developers are developing without worrying too much about it.

• Learning in parallel with the developers can help facilitate conversations about their needs and how the technology can be utilized effectively.

Book Recommendations

The speaker shares two book recommendations related to the topics discussed in the video.

Recommended Books

• "Mastering the Requirements Process" by Suzanne and James Robinson (Third Edition) is recommended for its comprehensive coverage of requirements gathering. The speaker mentions being mentioned in this book multiple times.

• "Value Requirements: A Handbook" by Tom is suggested as a resource for understanding how to set scales and numbers using a more formalized language approach.

Contact Information and Assistance

The speaker provides contact information for further assistance or discussions related to software development.

Contacting Constructs

• To reach out personally, one can contact Earl at earl.bd@constructs.com or hello@constructs.com.

• Constructs aims to promote better software development and offers assistance through chats or calls, depending on the complexity of the issue.

• If someone requires specific slides from the presentation, they can request them via email. However, sending the entire slide deck may not be possible due to business considerations.

Conclusion and Appreciation

The host expresses gratitude towards Earl for his insights throughout the video. They also encourage viewers to share the video with others who may find it valuable.

Wrapping Up

• The host expresses appreciation for Earl's contributions and the engaging discussion.

• The video will be available on the YouTube channel for those who missed parts of it or want to revisit specific sections.

• Viewers are encouraged to share the video with colleagues and friends who may benefit from it.

• Feedback, comments, and ideas for future webinars are welcomed by contacting Constructs through various channels.

Timestamps have been associated with relevant bullet points as per the provided transcript.