Before agreeing on document workflow requirements for Megapolis.DocNet, it is essential to define expected system behaviour, verification methods, and the contractor's scope of responsibility. An illustrative internal memo scenario demonstrates how to structure discussions with IQusion to prevent ambiguity regarding project scope and acceptance criteria for the delivered solution.

A feature name does not define the scope of work

The public Megapolis.DocNet page on the IQusion website describes document cards, routing, search, tasks, electronic signatures and APIs. That list does not establish whether a specific behaviour is included in a particular version and licence or requires configuration, development or an exchange with another system. Establish the boundary before agreeing an estimate. The phrase “approval workflow” alone does not explain document returns, temporary delegation or error handling.

Four categories can help structure the discussion. They describe how a requirement might be implemented; the final classification depends on the confirmed solution configuration:

  • Product capability: the behaviour is already available in the agreed delivery scope. Confirm it with documentation for that version and a scenario check.
  • Configuration: supported settings provide the behaviour without code changes. The contractor identifies the relevant settings and their limitations.
  • Development: a new or modified software component is proposed. Agree its maintenance, upgrade implications and acceptance criteria separately.
  • Integration: the requirement concerns an exchange between systems. It may also involve configuration or development; it needs a data contract and error-handling rules.

Public materials from IQusion IT LLC (IQusion) describe assessment, EDMS configuration and integrations as parts of implementation. That list is insufficient to assess a specific requirement: the customer needs delivery boundaries, confirmed behaviour and a person responsible for each change.

An illustrative internal memo scenario

The following synthetic example is intended to help prepare requirements. It does not describe a completed project, an executed demonstration or confirmed functionality of a particular product edition. An author creates an internal memo, an approver returns it with a comment, and a temporary delegate receives authority only for a defined period. Following approval, the document should reach another system; if that system is unavailable, the responsible person should be able to see the exchange status.

The process owner first describes the expected states and permitted actions. For example, a return should retain the earlier version and comment; delegation should not grant access to unrelated documents; resending should not create unintended duplicates. These are proposed requirements for discussion. Each needs confirmation of feasibility and an agreed verification method.

Evidence to request before agreeing a requirement

The table identifies what to request on the agreed software version using test accounts. Its implementation categories are hypotheses to verify. Neither a feature name nor a product description is sufficient to settle the classification.

Requirement — Evidence needed — Possible work category — Acceptance criterion Internal memo card — Field list, validation rules and a save example on the agreed version — Product or configuration; confirm delivery scope — Required fields are checked and saved values are available to the authorised role Return to author — A walkthrough of submission, return and resubmission — Configuration if supported; otherwise assess development — The comment, earlier state and agreed change history are retained Temporary delegation — Checks of allowed and prohibited actions before, during and after the delegation period — Decide after checking role and time-limit behaviour — Actions are allowed only within agreed limits; access is revoked when the period ends External system unavailable — Error handling, retry behaviour and duplicate prevention rules — Integration; identify configuration and code separately — The responsible person can see the status and retries follow the agreed rules

The future verification record should identify the version, modules, test roles, initial data and expected result. Until a check has taken place, mark its result “not verified”. A successful demonstration of one workflow does not automatically confirm all access rules or integration behaviour during failures.

Recording the agreed scope

After discussion, the process owner and IT team can work with the contractor to add a decision owner, implementation method, dependencies and evidence reference to each requirement. If evidence is insufficient, leave the requirement open. State precisely which behaviour remains unconfirmed and what must be shown before its scope can be agreed.

For business automation, a shared table connects the process description with verification of its outcome. For this illustrative scenario, the practical output is an agreed requirements table for an internal memo. It can support a work estimate and later acceptance checks, alongside a delivery specification and arrangements for maintaining any changes.

Sources used

  1. Впровадження документообігу (iqusion.com)
  2. Системна інтеграція (iqusion.com)
  3. Корпоративний електронний документообіг Megapolis.DocNet (iqusion.com)
  4. Документообіг та архів (softline.company)