Requirements Gathering Process for Church Extension Funds

A loan servicing issue rarely arrives as an isolated technology problem. It appears when a payment is posted incorrectly, an investor statement doesn't reconcile, or a state securities examiner asks why the same balance appears differently in the loan register and the general ledger. By then, the software project that created the problem may already be in configuration, migration, or testing.

For a Church Extension Fund, the requirements gathering process is therefore more than collecting feature requests. It is the disciplined work of identifying how loans, investor notes, cash, accounting, reporting, compliance, and ministry responsibilities must operate together. Requirements gathering means identifying, documenting, and organizing what a system must do, followed by analysis and validation before development or configuration proceeds, as described in this requirements gathering and management guide.

Why Requirements Gathering Is a Governance Decision for CEFs

A CEF can select a capable vendor and still experience a failed implementation if the organization never agreed on what “correct” means. Consider a familiar sequence. A loan servicing glitch changes how a payment is allocated between principal, interest, escrow, or fees. The issue surfaces during a state securities examination because investor liquidity reporting depends on the same underlying cash and ledger data. The examiner asks for the calculation rule, approval history, affected accounts, and evidence that management reviewed the correction. A board member then asks whether investor disclosures remain reliable.

That chain begins with an undocumented requirement.

The board's fiduciary responsibility doesn't end when it approves a technology budget. Directors must have reasonable assurance that the organization understands operational risk, regulatory obligations, financial reporting consequences, and the controls needed to manage them. A requirements register gives the board something more useful than a vendor demonstration. It shows which business outcomes matter, who owns each decision, how the requirement will be tested, and what evidence will remain after implementation.

Governance principle: A requirement isn't complete until its owner, source, test, and evidence are clear.

The historical development of requirements engineering supports this governance perspective. The practice was still being formalized in the early 1990s. The first Requirements Engineering conference in 1993 included social issues and ethnography among its dominant topics, while researchers were already identifying the need for computer-based elicitation tools, as documented in this historical analysis of requirements engineering. Early methods relied on interviews, questionnaires, document review, and observation. Those methods remain relevant for CEFs because critical knowledge still sits with loan officers, accounting staff, investor relations personnel, and auditors.

A disciplined process protects more than implementation timing. It preserves auditor confidence, supports board oversight, and gives the CFO a defensible record when a proposed shortcut would weaken reconciliation or compliance. A useful governance, risk, and compliance framework can help connect those responsibilities, while CEF leaders can also review governance, risk, and compliance services as they define the control environment around a new platform.

Building the Stakeholder Map Before the First Workshop

Missing roles create missing requirements. Before scheduling a workshop, identify every person who understands a workflow, bears accountability for an outcome, or can approve a trade-off.

Start with the executive sponsor, usually the executive director or CFO. That person establishes the business case, resolves priority conflicts, and confirms what the board must approve. The controller should define general ledger behavior, close procedures, reconciliations, journal-entry controls, and reporting expectations. Loan servicing staff understand the daily sequence that a process diagram often hides, including payoff exceptions, partial payments, construction draws, escrow movements, and manual corrections.

Investor relations brings a different form of knowledge. Note issuance, maturity schedules, interest calculations, statement production, tax reporting, and investor inquiries all create requirements that may not appear in a loan-focused demonstration. IT identifies integrations, identity management, data retention, access controls, and operational support. Compliance officers and outside state securities counsel interpret obligations that vary by jurisdiction and offering structure. The audit firm should participate early, because an auditor can identify evidence and reconciliation expectations before a configuration decision becomes expensive to change.

Use a RACI model, meaning responsible, accountable, consulted, and informed, but don't treat it as a substitute for judgment. Check whether any participant has a conflict of interest, particularly where a vendor relationship, legacy system preference, or departmental budget could influence a recommendation. Secure board endorsement for the decision rights and risk appetite before staff begin negotiating detailed features.

A simple map can make gaps visible:

The map should be approved before invitations go out. It becomes the first control against a workshop dominated by whoever happens to be available.

Running Discovery Workshops That Surface Real Workflows

A discovery workshop shouldn't be a brainstorming session in which participants describe an ideal future state. It should be a facilitated examination of how work moves, including approvals, exceptions, spreadsheets, handoffs, and evidence.

Begin with pre-work. Provide sample loan files, investor statements, journal-entry lists, chart-of-accounts extracts, policy documents, and representative reports. Remove sensitive information where necessary, but preserve the structure and edge cases. Ask participants to identify where a calculation originates, who changes it, who reviews it, and where the result is recorded.

Use a written agenda with time reserved for five activities: context, workflow walkthrough, exception handling, prioritization, and unresolved questions. The facilitator should open by stating the ministry and financial outcomes under review. That framing keeps the group from drifting into a feature-by-feature vendor discussion.

Follow the transaction from beginning to end

Take one church loan through application, underwriting, approval, closing, disbursement, servicing, payoff, and post-payoff reporting. Then trace an investor note from issuance through accrual, statement production, maturity, renewal, or redemption. Finally, walk through month-end close and a state reporting cycle. These scenarios expose dependencies that isolated feature lists miss.

Ask specific questions:

• Source: Where does the value originate, and which document supports it?
• Calculation: What rule determines interest, fees, allocation, or maturity treatment?
• Approval: Who can authorize an override or correction?
• Exception: What happens when a payment is partial, late, returned, waived, or misapplied?
• Evidence: What must an auditor, board member, or examiner be able to review?

One facilitator should control the sequence. A dedicated scribe should capture statements close to the participants' actual language, not reinterpret them into technical shorthand. Before the meeting ends, the group should validate the workflow map and mark disagreements rather than smoothing them over.

The United We Transform workshop exercises offer useful prompts for structuring dialogue and moving groups from discussion toward action. CEF leaders considering broader system change can also review technology modernization guidance for CEFs while keeping the workshop focused on documented operating needs.

A good workshop produces three concrete outputs: workflow diagrams, an exception register, and a decision log. Unresolved items should have an owner and a follow-up date. If a session ends with only a list of desired screens, discovery has not reached the work that matters.

Capturing Regulatory and Compliance Requirements

Compliance requirements are difficult to negotiate because the underlying obligation is not optional, yet the system behavior still needs precise definition. “Support state securities compliance” is a policy aspiration. “Record the source, approval, effective date, calculation, and distribution evidence for each investor note statement” is closer to a testable requirement.

Build the inventory by obligation, not by department. Review applicable state securities laws, offering documents, investor note covenants, IRS reporting requirements, GAAP reporting policies, internal approval policies, and the audit firm's expectations. The exact obligations will depend on the CEF's jurisdictions, products, and legal structure, so counsel and auditors should validate the interpretation.

Then translate each obligation into an artifact and an owner:

This matrix separates governance from scope creep. A vendor may call a control “custom work,” but that doesn't make the underlying obligation discretionary. Conversely, a requested dashboard may be useful without being a compliance requirement. The matrix gives the CFO a calm way to distinguish the two.

The literature identifies ambiguous or incomplete requirements, changing requirements, and tacit knowledge as recurring sources of downstream risk, with some prior studies attributing up to 90% of large software project failures to poor requirements elicitation, as reported in this requirements elicitation literature analysis. In a separate 12-company interview study, stakeholder-related challenges were reported by 13 interviewees, or 54%, while difficulty understanding and articulating needs was reported by 10 interviewees, or 42%; the findings appear in this extended interview study of requirements elicitation. Those findings explain why an auditor belongs in discovery, not merely in the final review.

Treating Data Migration as a Requirements Workstream

Data migration fails when staff treat it as a technical exercise scheduled shortly before cutover. For a CEF, migration defines whether historical loan balances, investor obligations, cash activity, and financial reporting can be trusted on the first day of operation.

Start by naming the source artifacts. The list may include general ledger trial balances, a chart of accounts, loan tapes with payment history, investor registers with maturity schedules, collateral and lien records, escrow balances, and decades of transaction detail. A 30-year loan tape raises questions that a clean sample file won't answer. Which historical fields are authoritative? How are modifications represented? Are payoff adjustments recorded separately? Can the old system distinguish a principal payment from a correction?

Each input needs a field-level mapping, cleansing rule, ownership decision, and reconciliation method. A legacy investor notes ledger may contain duplicate names, changed addresses, historical rates, and redemption activity. The requirement isn't just “import investors.” It may require preserving the original note identifier, linking transactions to the correct holder, retaining maturity history, and documenting any transformation.

Define acceptance before transformation

For the trial balance, specify the accounts that must tie to the approved closing period and identify who signs the reconciliation. For the loan tape, define the balance, accrued interest, payment, escrow, and status totals that must agree with the source system. For the investor register, define the population, principal outstanding, accrued interest, maturity dates, and transaction totals that must reconcile to the approved ledger.

Don't move a single row until the team has agreed on source authority and exception treatment. A record that cannot be mapped should enter an exception queue with a resolution owner, not disappear into a cleansing spreadsheet.

Data migration strategy guidance for CEFs can help structure this work, but the acceptance criteria belong to the CEF, its auditor, and its governing policies. The migration plan should be attached to the requirements baseline so the vendor cannot later characterize reconciliation as an optional post-go-live activity.

Writing Acceptance Criteria and a Traceability Matrix

A requirement becomes useful when a person can test it and a board member can understand the expected result. The Given, When, Then pattern works well for CEF workflows because it forces the team to define conditions, action, and outcome.

For example:

• Given an investor note has an approved principal balance and rate, when the scheduled accrual runs, then the system records the calculated interest, source terms, processing date, and resulting ledger entry.
• Given a borrower makes a payment smaller than the scheduled amount, when the payment is posted, then the system applies it according to the approved waterfall and displays any remaining balance or exception.
• Given an authorized employee waives a late charge, when the waiver is approved, then the system records the user, reason, date, affected account, and resulting accounting treatment.

Avoid vague statements such as “the system should handle investor reporting.” Write the expected report, population, timing, fields, approval, and evidence. A well-structured requirement record commonly includes an ID, description, source, related test cases, verification method, status, and owner, as summarized in this requirements traceability matrix guidance.

Connect every requirement to evidence

A requirements traceability matrix, or RTM, links a requirement from initial identification through verification and captures its source so reviewers can confirm where it came from, as explained in this guide to creating and using an RTM. For a CEF, add configuration reference, test result, sign-off, and audit evidence. Bidirectional traceability matters: move forward from requirement to test, then backward from a report or journal entry to the requirement that justifies it.

The RTM should remain live throughout configuration and testing. If a requirement changes, record the reason, decision authority, impact, and replacement test. That discipline prevents a late “small adjustment” from weakening a control without anyone acknowledging the trade-off.

Governing the Timeline, Testing, and Go-Live

The requirements gathering process reaches its practical test when the executive team must decide whether the organization is ready to proceed. Timeline, testing, and go-live shouldn't run as separate conversations. They should operate through a governance cadence with visible gates and decision rights.

The CFO should own the requirements baseline and resolve business priority conflicts. The controller should lead reconciliation. The IT lead should command cutover planning and technical readiness. The outside auditor can serve as an independent observer for user acceptance testing involving investor notes and loan servicing, without replacing management's responsibility for approval.

Testing should proceed in layers. Unit testing verifies individual calculations or configurations. Integration testing checks movement between loan servicing, investor notes, cash operations, and the general ledger. Regression testing protects previously approved behavior after changes. User acceptance testing confirms that staff can perform real scenarios. Parallel processing compares old and new results before the cutoff weekend.

Each layer needs pass or fail criteria tied to acceptance records, not to a vendor's assurance that the system is ready. The steering committee should review the following evidence at each gate:

• Traceability matrix: Every in-scope requirement has a test, owner, status, and evidence location.
• Defect burn-down: Open defects are classified by business impact, control impact, and disposition.
• UAT exit report: Named users have completed approved scenarios and documented exceptions.
• Parallel reconciliation: General ledger, loan tape, investor register, cash, and key reports reconcile under the agreed rules.
• Regulatory pre-flight checklist: Compliance, counsel, and audit expectations have documented owners and sign-off.

A cutoff weekend needs a written rollback posture. Define the point at which the CEF stops loading data, who authorizes reversal, how transactions received during the transition are captured, and how staff communicate with borrowers and investors. After cutover, reconcile the general ledger, loan tape, investor registers, and cash activity before declaring the implementation complete.

A 30-day hypercare window gives staff a defined period to log every defect against its original requirement ID, rather than allowing problems to become informal fixes. Align the review calendar with the audit calendar so CPA and regulator reviewers see requirements, tests, reconciliations, approvals, and exceptions as evidence of control.

The field has studied requirements practices at meaningful scale. One survey gathered 625 responses and retained 419 valid answers, with the authors noting a margin of error smaller than ±5% at 95% confidence, while another industry survey produced 194 usable responses, as documented in this requirements engineering survey. The practical lesson for a CEF is straightforward: measure readiness with validated evidence, not confidence expressed in a meeting.

CEFCore offers a unified environment for loan management, investor notes, general ledger, cash operations, reporting, and audit trails, which can give a requirements team a concrete operating model to evaluate rather than a collection of disconnected spreadsheets. Review the CEFCore platform with your CFO, controller, auditor, and servicing leads, and use the requirements, traceability, and reconciliation questions in this article to guide the conversation.