Skip to content

Cursor-Assisted Requirements Engineering: Unifying Google Docs, Slack, JIRA, Confluence and Submodules Into Cross-Linked Markdown

Tracking software requirements and communicating effectively with all stakeholders when information is scattered across multiple systems like Slack, Google Docs, JIRA, Confluence, GitHub, and elsewhere can be challenging. While I wait for the industry to solve this, I experiment with makeshift solutions. My current workflow uses Cursor as the central hub. It operates on a requirements-focused GitHub repository that consolidates the relevant software-focused repos as submodules, copies of Slack threads, and Google Docs. I then use MCP to sync the remaining information.

Software Requirements Engineering with Human-Level AI

AI models increasingly cover the how of building software products, reshaping the role of software engineers. The ongoing shift may simply result in yet another abstraction layer while still requiring a “software engineer” to guide the implementation. Alternatively, the responsibilities of product managers and software engineers could gradually converge. In the latter case, a deep understanding of technology is still relevant, but most of the remaining work consists of understanding where software can add value and capturing the requirements with sufficient clarity and detail so that the AI models can derive the implementation from them.

Speccing AI-assisted Software Requirements Engineering

Answering questions on how a product with many software components should work can be challenging. The software may have been written by countless developers over a long period of time, and many may no longer be available for consultation. In principle, maintaining a formal and complete specification separate from the implementation would help in understanding the product’s intended behavior. In practice, such rigor requires an engineering budget and expertise that may be available only when developing safety- or security-critical systems. Additionally, studying a formal specification for a complex system to verify if the implementation conforms to it or to propose a modification can be time-consuming and error-prone.

For less critical systems, partially specified and incremental specifications that remain unmaintained may currently be a cost-effective way to develop software in large organizations. Regression test suites, both manual and automated, serve as the de facto specification for correct behavior.

Used judiciously, large language models could play a part in accelerating product development velocity while keeping unwanted undefined behavior at bay. This article briefly covers some situations where product development might benefit from a lightweight AI-assisted requirements engineering process and speculates on how some aspects of the tooling could be implemented.

Validating React Context Usage by Prop Drilling Opaque Tag Types

React context allows data to be passed to nested components outside props, reducing the need for prop drilling. Type checker can validate that a component passes correct values in a child component’s props. However, a component’s type signature does not expose the contexts it taps with useContext. Context-using hooks can be injected in props, making data access explicit and type-checkable. With dependency injection, type signatures in props are complete, allowing alternative implementations in different call sites, such as tests and component explorer configurations. If such customizability is unnecessary, it is enough to pass an opaque tag type that encodes which contexts are available, reducing some boilerplate code compared to dependency injection.