Name the responsibility in ordinary language.
A module might maintain a directory, handle a structured request, manage a reference register, or support a review decision. Begin with the responsibility rather than a collection of screens. The screens should follow the work the part needs to support.
Describe who uses the module, which records belong to it, and which decisions it is allowed to make. Naming those elements helps separate a useful component from a general container for unrelated features.
Bring the rules into the scope.
Required fields, allowed transitions, ownership, and record relationships influence how the module behaves. Some rules belong to the organization rather than the software team. The project should identify who can confirm them and which examples demonstrate their meaning.
Potential work includes a bounded record-management feature, shared application component, structured request module, or configurable business rule. Platform access, existing data, and external dependencies affect the feasible implementation.
Reuse the stable part.
A reusable module should have a clear purpose and an interface that remains understandable in another context. Reuse does not mean forcing every task through one universal component. Similar-looking screens can represent different responsibilities and need different behavior.
Choose configuration only where variation is real and manageable. A small explicit difference can be easier to maintain than a large set of switches that allows combinations nobody has reviewed.
Review the module as a whole.
Check the ordinary task alongside missing information, disallowed actions, and interactions with related parts. A technically successful action still needs an understandable result for the person using it.
A defined delivery can include the implemented module, representative records, rule definitions, and maintainer notes. Any ongoing support or compatibility commitment requires an explicit agreement rather than an assumption based on the word “reusable.”