D284 Software Engineering is banner number ITSW 2226 and four competency units in the School of Technology. The catalog places it after the core programming and project management courses for a reason: it introduces software engineering principles to students who can already write code and already know what a project plan is, and it asks them to connect the two. What it builds toward is the discipline that separates a program from a product, which is requirements you can trace, a design you can defend, a process you chose on purpose and a plan for verifying that what you built is what was asked for.
The course grades engineering, not coding
Students who arrive strong at programming often find this the least comfortable technology course, because writing better code does not help. The subject is everything around the code: eliciting what somebody actually needs, expressing it so a developer and a stakeholder read it the same way, choosing a development approach that suits the situation, and being able to show that every requirement ended up somewhere in the design and somewhere in the tests.
Requirements are where the course begins and where most points are available. Functional requirements state what the system does, non-functional requirements state how well it has to do it, and the second category is the one that gets left out. Response time, concurrent users, availability, security posture, accessibility and maintainability are non-functional and they are the requirements that decide the architecture. A requirement set with thirty functional lines and no non-functional lines is incomplete no matter how detailed the thirty are.
Process choice is the second graded idea. Predictive, iterative and agile approaches each suit different conditions, and the competency is not knowing definitions but matching an approach to a scenario and defending it. A fixed regulatory deliverable with a fixed scope and a hard audit date is not an argument for a two week sprint cadence, and a product with unstable requirements and a reachable customer is not an argument for a full specification signed before development.
Modeling is the third. Use case diagrams, class diagrams, sequence diagrams and activity diagrams are the standard vocabulary, and they are read, not admired. A diagram that uses the wrong arrow for the relationship it means is worse than no diagram, because it makes a false statement precisely.
Mapping scored aspects onto engineering artifacts
Aspects are judged one at a time at WGU, each needs a 2, and no strong section rescues a weak one. In an engineering course the aspects usually name artifacts directly, which makes the mapping unusually clean: this aspect becomes the requirements table, that one becomes the class diagram, that one becomes the test plan.
Budget with the artifacts in mind, because diagrams and tables displace prose. Suppose your rubric shows eleven scored aspects and the written document should run about 2,000 words alongside the models. Eleven into 2,000 is 182 each as a flat split. Now subtract. Four of those aspects are satisfied primarily by a diagram or a table, and each needs only an introduction and a reading of the artifact, so call them 100 words each, which is 400 and releases roughly 330. The process justification aspect is pure argument and takes 350. The requirements aspect needs both the table and an explanation of how the requirements were derived, so 300. Risk and verification aspects take 250 each. Adding those, 400 plus 350 plus 300 plus 500 is 1,550, leaving 450 for the remaining three aspects at 150 apiece. The document lands at 2,000 with the argument sections carrying the weight and the artifacts carrying the detail.
Build a traceability column into your requirements table from the start: requirement identifier, the design element that implements it, the test that verifies it. Aspects about completeness and verification become answerable by pointing at that column.
Working through D284 now?
Send the aspects and the scenario. You get a requirements structure, the model set the aspects imply, and a traceability table you can defend line by line.
The artifact set an engineering deliverable usually needs
| Artifact | Question it answers | The defect that ruins it |
|---|---|---|
| Stakeholder list | Who has a stake, what each one needs, who decides | Naming roles without naming their competing interests |
| Functional requirements | What the system must do, one testable statement per line | Compound requirements holding three obligations in one sentence |
| Non-functional requirements | How well, how fast, how safe, how available | Being absent entirely, or stated without a number |
| Use cases | How an actor achieves a goal, including what happens when it fails | Only the main flow, no alternate or exception flows |
| Structural model | What the parts are and how they relate | Association arrows used where inheritance or composition was meant |
| Behavioral model | The order in which things happen across components | Messages that no interface in the class model supports |
| Process and plan | Which methodology, which phases, which milestones and why | A methodology named but never connected to this project |
| Verification plan | How each requirement will be proven satisfied | Test types listed generically with no link to requirements |
Consistency across artifacts is scored even when no aspect says so. A class in the sequence diagram that does not exist in the class diagram is the fastest way to signal that the models were drawn separately rather than derived from one another.
Sources, standards and the precision engineering writing needs
Engineering claims want sources with standing. Established software engineering texts, published methodology descriptions from their originating bodies, and recognized standards for requirements and quality are the strong citations. A vendor blog explaining why its product suits agile teams is marketing and reads as such. Where APA is required in your program, cite the edition and the year, and be careful with methodology terms that have precise published definitions, because using one loosely in a course about precision is expensive.
Numbers are the second discipline. A non-functional requirement without a figure is not a requirement. The system should be fast is untestable. The system shall return search results within two seconds for up to five hundred concurrent users is testable, and testable is the entire point of writing it down.
Diagrams follow a published notation, so use it correctly rather than approximately. If you use a modeling tool, keep the exported images legible at the size they will be read, and label every diagram with a figure number and a caption that states what it shows. An unlabeled diagram dropped between paragraphs forces the evaluator to infer your intent.
What separates Competent from returned here
WGU grades Competent or Not Competent, with revision and resubmission available without penalty when an aspect falls short. Because a return costs time rather than record, and because a six month term is a fixed budget of time, the useful goal is a first submission that is complete rather than elegant.
Complete, in this course, means every artifact the aspects imply is present, they agree with one another, and the argument sections argue. The strongest submissions read as one coherent project: the stakeholders explain the requirements, the requirements explain the design, the design explains the plan, and the verification section closes the loop back to the requirements.
Returns follow from disconnection. Requirements that appear in the table and never again. A methodology chapter that could have been written for any project. A test plan that names unit, integration and acceptance testing without saying what would be tested or which requirement each activity satisfies. Each of those is a complete-looking section that answers a general question rather than the one your scenario asked.
Six expensive mistakes in this course
- Writing requirements as features. A feature list describes a product. A requirement is a single testable obligation with an identifier you can reference later.
- Omitting non-functional requirements. They are half the engineering content and the half that drives design decisions the aspects will ask you to justify.
- Drawing diagrams last. Models are thinking tools. Drawn after the document is written, they only illustrate what you already decided and contradict it in three places.
- Choosing a methodology by preference. The aspect asks for a fit between approach and situation. Name the conditions in your scenario that make the choice correct.
- Skipping alternate flows in use cases. Failure paths are where real requirements hide, and they are the flows evaluators check for.
- Leaving the artifacts inconsistent. A name that changes between the requirements table and the class diagram tells a reader the documents were never reconciled.
How we work on this course
Support for D284 is document architecture before drafting. Send the scored aspects and the scenario and you get a requirements structure with identifiers and a traceability column, the model set your aspects imply, a methodology argument built from the conditions in your own case, and a model document in the register WGU expects. Where your course includes an objective assessment, our work there is preparation only: terminology drills, scenario practice and a straight read on your preassessment. Objective assessments are proctored, we prepare students and never sit or assist during any assessment, and we never ask for or touch WGU portal credentials.
Four units makes this one of the heavier courses in the plan, and it is also one of the most reusable, since the requirements and modeling work here returns in the graduate software engineering courses and in the capstone.
Three questions D284 students ask
Is D284 the same as ITSW 2226?
How much programming does D284 involve?
Which modeling notation should I use?
Where D284 sits in WGU's programs
The July 2026 catalog places this code in 5 current WGU programs. 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.