A use case that lives only in the author's head, or in a file nobody can find, has no value to a project. Once you have written scenarios and gathered requirements, the work shifts to documentation and communication: where use cases are stored, how they are named and versioned, how each one connects back to the requirements it satisfies, and how you keep all of it current as the product changes. This topic treats use cases and requirements as shared project artifacts rather than one-time deliverables.
Three practices hold this together. Organization means a repository with consistent structure, identifiers, and status so team members can locate and reuse what exists. Traceability means every requirement can be followed forward to the use cases, design elements, and test cases that realize it, and backward to the stakeholder need that justified it. Communication means presenting use cases in a form that clients, developers, and testers can each act on, and keeping stakeholders involved when things change.
As you watch, look for three things: how a formal specification document is structured and what sections it contains; how traceability links are created, visualized, and checked for gaps; and what concrete behaviors make stakeholder collaboration work rather than fail. Note also how design and test activities draw directly on these documents, since that downstream use is the main reason to invest in clean documentation.
A lecture-style walkthrough of the Software Requirements Specification document, the standard artifact used to record and communicate requirements on a software project. Based on its title and channel, expect coverage of what an SRS is for, the sections it typically contains, and the qualities a good specification should have, such as being complete, consistent, and unambiguous. It is presented in the exam-preparation style typical of Gate Smashers lectures.
It gives you a concrete template for how requirements are formally documented and organized, which is the foundation for a use case repository and for traceability links back to numbered requirements.
A short practitioner video from Nielsen Norman Group presenting an eight-step process for UX designers and researchers to collaborate more effectively with stakeholders. The description indicates it focuses on specific behaviors that increase collaboration and buy-in rather than on documentation formats. Expect practical guidance on involving stakeholders throughout a project rather than only at review points.
It directly addresses the communicating use cases to stakeholders subtopic from a trusted UX research organization, and its advice applies equally to keeping stakeholders engaged when requirements change.
A technical demonstration from MathWorks showing three approaches to analyzing requirements traceability in MATLAB, described as tracking the connections between requirements and other project artifacts. Expect to see how links between requirements, design, and tests are represented and how gaps or missing coverage can be identified. The examples are tool-specific but the underlying concepts are general.
It makes the abstract idea of traceability visible and concrete, and it illustrates how requirements feed forward into design and testing, covering two of this topic's subtopics at once.
These videos extend the module's core skills into the documentation stage. The SRS lecture shows how requirements are formally written down and separated into categories and qualities, supporting MO3 by giving you a structure in which functional and non-functional interface specifications are recorded. The stakeholder collaboration video reinforces MO2 by showing that requirements gathering is an ongoing relationship with users and sponsors, not a single interview session. The traceability demonstration connects back to MO1 by showing why use case scenarios must be identifiable and linked artifacts, so that each user goal you compose can be traced through to the design and tests that satisfy it.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.