D779 Software Product Design and Requirement Engineering is banner number ITSW 5102 and three competency units in the School of Technology, at the graduate level. The catalog describes it as effectively integrating user needs and system requirements into software product design, and the word integrating carries the whole course. Needs and requirements are different objects written in different languages by different people, and the discipline being built is the translation between them, done in a way that survives challenge and can be traced in both directions.
A need is not a requirement, and the gap is the subject
A user need is a statement about a problem in the user's own words. A requirement is a statement about a system that an engineer can build against and a tester can verify. Turning the first into the second loses information if done carelessly and invents information if done ambitiously, and managing both risks is the competency this course grades.
Elicitation comes first and it is not the same as asking. People describe solutions when asked about problems, they omit what is obvious to them, and they disagree with each other in ways that only surface when their statements are put side by side. Interviews, observation, document analysis and workshops each surface different material, and choosing a technique for a reason is a graduate-level judgment the aspects usually ask about.
Specification is the second discipline. A requirement that says the system should handle errors gracefully cannot be built or tested. One that says the system shall reject a submission with an invalid account number, retain the entered data, and display the reason next to the field is buildable, testable and arguable. Precision in requirement writing is a skill with rules: one obligation per statement, active voice with a named subject, no compound conditions hidden behind an and, and no adjectives standing where a number belongs.
Prioritization and negotiation close the loop. Not every requirement survives, and being able to structure a prioritization with a stated method and defend the resulting cut is what separates a requirements engineer from a requirements recorder. Product design decisions follow from those cuts rather than from the full wish list.
Turning scored aspects into a requirement set and a budget
Each aspect is judged separately at WGU and needs a 2 to pass. Here the aspects tend to name stages of the requirements process, so the mapping is stage to artifact, and the trap is producing every artifact without connecting any of them.
Budget the writing. Suppose ten scored aspects and a document of about 2,100 words alongside your requirement tables. Ten into 2,100 is 210 each. Sort them. Three aspects are artifact aspects where the table answers, needing 120 words each of framing, which is 360 and releases about 270. Two ask you to justify elicitation and prioritization method choices, at 320 each, or 640. Two ask about traceability and validation of the requirement set, at 300 each, or 600. Two ask about the product design decisions that follow, at 250 each, or 500. One is a conclusion at 130. That totals 360 plus 640 plus 600 plus 500 plus 130, which is 2,230, so trim one design section to 170 and one traceability section to 250, landing near 2,100 with method and traceability argument carrying more than half.
Give every requirement an identifier from the first draft and every need a separate one. The link between the two identifier sets is your traceability, and building it later from memory is what produces the gaps evaluators find.
Working the D779 requirements task?
Send the aspects and the product scenario. You get an elicitation plan, a requirement format that survives review and a traceability structure.
Rewriting weak requirements into testable ones
| Defect | Weak statement | Rewritten |
|---|---|---|
| Adjective instead of a measure | Reports should load quickly | The system shall render a standard report within a stated time for data sets up to a stated size |
| Two obligations in one line | The system shall validate and archive submissions | Split into two numbered requirements, each independently verifiable |
| Solution stated as need | The user needs a dropdown of regions | The user needs to restrict results to one region without typing its name |
| Unnamed actor | Notifications will be sent | The system shall notify the assigned reviewer within a stated interval of assignment |
| Hidden condition | Managers can approve requests | A user with the manager role shall approve a request only when it is in submitted state and not their own |
| Unverifiable quality | The interface shall be intuitive | A first-time user shall complete the primary task without assistance in a stated number of steps |
Running your own draft requirements through these six defects catches most of what a review would find, and it is the fastest quality pass available in this course.
Evidence, traceability and citation
The evidence in a requirements deliverable is the chain. Each requirement should point back to a need, a stakeholder or a document that motivated it, and forward to the design element that satisfies it and the verification that will prove it. A requirement with no ancestor was invented, and a requirement with no descendant is unimplemented, and both are conditions an aspect about completeness is written to detect.
Where you elicited from real people, report the method, the number of participants and their roles, and quote rather than paraphrase where the wording matters. Anonymize individuals. Where your scenario supplies the raw material, quote it directly when deriving a requirement so the derivation can be checked.
For sources, established requirements engineering texts and published standards for requirement documentation and quality give you named criteria to write against, and citing the criterion you applied is stronger than asserting that a requirement is well formed. Use APA where your program requires it. Prioritization methods have published definitions, so name the method and apply it faithfully rather than describing an informal ranking with a formal method's name.
What clears, and what returns
WGU marks work Competent or Not Competent, and a performance assessment that misses an aspect returns for revision without penalty. In a six month flat rate term the cost is the days, which is why building traceability into the first draft is cheaper than reconstructing it after a return.
Deliverables that clear read as one derivation. The needs are recognizable as things a person said or a document stated. The requirements are testable and individually numbered. The prioritization uses a named method and produces a cut that the design then respects. The design decisions cite the requirements they satisfy.
Returns follow from breaks in that chain. Requirements that appear from nowhere, usually the ones the author personally thought the product should have. Non-functional requirements missing or stated without measures. A prioritization that ranks everything as high. And a design section that describes a product without referencing a single requirement identifier.
Eight mistakes that cost D779 students time
- Recording solutions as needs. When a stakeholder asks for a feature, the need is the problem behind it. Capture both and keep them separate.
- Compound requirements. An and hides a second obligation that can pass and fail independently. Split every one.
- Adjectives where numbers belong. Fast, secure and intuitive are placeholders for measures nobody supplied yet.
- Building traceability at the end. Reconstructed links are guesses, and the gaps they leave are exactly what completeness aspects look for.
- Prioritizing everything as essential. A prioritization with no lower tiers has made no decision, and the aspect asked for a decision.
- Skipping validation. Requirements need checking against the need with the person who has it, not only checking for internal consistency.
- Leaving constraints out of the set. Regulatory obligations, platform limits and interfaces to systems you do not control are requirements too, and they are the ones that reshape a design once discovered late.
- Writing the design before the cut. A product design drafted against the full wish list has to be redone once prioritization removes a third of it, so decide the scope first and design against what survived.
How we work on this course
D779 support is structure and precision. Send the scored aspects and the product scenario and you get an elicitation plan matched to what the case allows, a requirement template that satisfies the quality criteria your aspects reference, a traceability structure carrying identifiers from need through verification, and a model document written the way WGU graduate evaluators read requirements work. Where a section of your course is assessed by an objective assessment, we prepare only, and objective assessments are proctored: we never sit or assist during one and never ask for or use portal credentials.
Requirements courses reward front loading more than almost anything else in a graduate plan, because a defect in the requirement set propagates into every later artifact. In a six month flat rate term that propagation is what costs you a course.
Three questions D779 students ask
Is D779 the same course as ITSW 5102?
Do I need real stakeholders to interview?
How many requirements should I write?
Where D779 sits in WGU's programs
The July 2026 catalog places this code in 3 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.