D614 Decision Process Engineering Capstone, catalog number DTAN 6227, is the three CU capstone that integrates the WGU Master of Science, Data Analytics core with the decision process specialization, requiring you to evaluate organizational needs and identify the business requirements that follow from them. The deliverable is not a model and not a pipeline. It is a redesigned way of deciding, justified end to end.
Requirements are the named deliverable
The catalog description for DTAN 6227 puts unusual weight on identifying business requirements, and that emphasis is worth taking literally. In this capstone the requirements are not preamble to the interesting work. They are a substantial part of what is scored, and they are where most of the integration happens.
A business requirement in this context is a testable statement about what the redesigned arrangement must do, traced to an organisational need and stated in language the organisation would use. Not the system shall be scalable, but the credit decision must be returned within ninety seconds for at least ninety five percent of applications, because applicants abandon the form beyond that point. The second version can be verified, argued about and signed off. The first cannot.
The other thing under examination is whether the capstone integrates the whole degree. Process mapping from one course, decision framing from another, analytical evidence from the core, and communication for the stakeholders who have to accept the change. A capstone that draws on only one of those is a course project wearing a capstone title.
Turning scored aspects into a section plan
Capstone rubrics live in your Course of Study and carry more aspects than ordinary courses. Count them first, because the aspect list is what tells you how deep each part has to go. Every aspect is scored independently against a three point scale and each needs a 2, so a compelling redesign with a weak evaluation plan is a returned capstone.
Capstones arrive in stages with approval checkpoints. Treat the approved scope as binding and record any change with its reason at the moment it happens, rather than reconstructing the story at the end.
The word budget, worked. Assume nine scored aspects and a report near 3,600 words. Reserve 250 for an executive opening and 180 for a close, leaving about 3,170, or roughly 350 per aspect. Then rebalance: the organisational need aspect and the requirements aspect go to 500 each, funded by trimming description heavy aspects to about 270. This capstone is named for requirements, and a report that spends more words describing tools than specifying requirements has mis weighted itself against its own rubric.
A structure that fits this capstone
Your capstone directions and any template take precedence over everything here. Where the shape is yours, this ordering supports the integration the course expects.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Executive summary | Need, redesign, expected effect and what it will take to get there | Written last, read first, checked against the body |
| Organisational need | Who is affected, what the current arrangement costs, evidence for both | The aspect that justifies the project existing |
| Current decision process | How the decision is made now, mapped, measured and evidenced | Baseline for every claim of improvement |
| Business requirements | Numbered, testable statements with owners and acceptance criteria | The named centrepiece; quality here drives several aspects |
| Proposed design | The redesigned process, the analytics that support it, the human and machine split | Each element traced to a numbered requirement |
| Feasibility | Data availability, systems, skills, cost and timeline | Where ambitious capstones lose credibility |
| Evaluation plan | The measures that will show whether the redesign worked, and when they are read | Distinguishes a proposal from a delivered piece of thinking |
| Risks and adoption | What could fail, who resists, and how that is managed | Expected at graduate level; silence is noticed |
Number the requirements and use the numbers everywhere else. A design section where each paragraph opens by naming the requirement it satisfies is the fastest thing in the world to score, and evaluators notice.
Evidence craft across a long project
Capstone evidence is gathered over months and used in a week, which means the collection habit decides the writing experience.
- Keep a dated decision log with reasons. The justification sections are largely transcription from it.
- Evidence the current state with something other than opinion: system data, observed cases, documented cycle times, or a stated count of interviews.
- Attach acceptance criteria to every requirement. A requirement nobody could fail is not a requirement.
- Quantify the cost of the current arrangement, even approximately, and show the arithmetic.
- Cite external benchmarks for claims about what good looks like in the sector.
- Use APA throughout and build the reference list continuously rather than at the end.
Include the counter argument. A capstone that names the strongest objection to its own recommendation and answers it reads as considered work, and it usually satisfies risk aspects at the same time.
What separates Competent from a submission sent back
With more aspects in play, the odds that one is thin rise, and that is the usual shape of a capstone return.
- Requirements are numbered, testable and each has acceptance criteria.
- Every design element names the requirement it satisfies.
- The current state is evidenced rather than asserted.
- Feasibility addresses data, systems, skills and cost, not just technical possibility.
- The evaluation plan names measures, timing and a responsible role.
Capstone performance assessment work can be revised and resubmitted with no grade penalty, but capstone evaluation queues are the longest in the degree. With six month flat rate terms, a return arriving in month five is the most expensive delay in the programme.
Six mistakes that cost time in D614
- Requirements written as aspirations. Statements about being efficient or user friendly cannot be tested and cannot be signed off.
- Skipping the current state measurement. Without a baseline, no improvement claim in the whole capstone can be supported.
- Designing before the need is evidenced. It produces a solution looking for a justification, which is visible in the writing.
- Feasibility limited to technology. Skills, budget, data access and organisational appetite belong there too.
- No evaluation plan. A redesign with no way to tell whether it worked is a proposal, not engineering.
- Leaving the executive summary as first drafted. After months of work it usually describes a project you no longer did.
- Presenting the redesign as obviously better. Every reallocation of a decision takes discretion away from somebody, and a capstone that never acknowledges the loss reads as naive about the organisation it claims to understand.
Writing requirements that survive review
Because this capstone is named for requirements, it is worth spending real time on how they are written. A requirement that survives review has five parts, and they fit in one sentence plus a line of acceptance criteria.
It names the actor or system that must do something. It states the behaviour in active language. It carries a measurable condition, which is where a number belongs. It states the circumstances under which it applies, because most requirements are conditional and unstated conditions cause arguments later. And it has an owner, because a requirement nobody owns is never verified.
Separate the functional requirements from the constraints. What the arrangement must do is different from the limits it must respect: budget, regulation, existing systems, data protection obligations and the skills of the people who will operate it. Mixing the two is the most common structural error, and it makes the design section hard to trace.
Then run each requirement through two tests. Could someone demonstrate it was not met? If not, it is a wish. And does it trace back to a specific organisational need documented earlier in the report? If not, either the need section is incomplete or the requirement is invented. Both tests take seconds per requirement and both catch problems that would otherwise be found by an evaluator instead.
How support works on this course
Send the rubric from your Course of Study, the capstone directions and any template. What comes back is aspect mapped and staged: a need section built on evidence, numbered requirements with acceptance criteria, a design that traces to them, a feasibility section covering more than technology, and an evaluation plan with timing and owners. Plus a walkthrough so the capstone is yours to defend.
Terms run six months at a flat rate, and a capstone is the one course where slipping past the term boundary is common and expensive. Starting it in month one is worth more than any writing technique.
Questions students ask about D614
Is D614 the same course as DTAN 6227?
Does D614 require building a working system?
Can you write my capstone?
Where D614 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.