DoAssignment study guide

B1.5 · Confirm requirements and plan ongoing support

Learn to confirm requirements and plan ongoing support through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

A practical guide to agreeing what a solution must do and arranging help after delivery

In Grade 11 computer science, you practised planning and building programs from stated problems. In a larger project, a request may be incomplete or open to interpretation. A solution can work according to a programmer’s assumptions and still fail to meet users’ needs. Expectation B1.5 focuses on two connected responsibilities: confirm requirements and plan ongoing support. Confirmation checks that the people involved agree on what the solution is expected to do. Support planning considers how users will get help and how questions or problems will be considered after delivery. These responsibilities help keep the work clear for the people who depend on it.

What you will learn

Explain why requirements should be confirmed with the people who need a solution.
Clarify a broad request and turn it into focused requirements that can be reviewed.
Plan ongoing support by identifying a contact, useful information for reports, and agreed responsibilities.

1. Review the request before treating it as a requirement

A request often describes a concern rather than a complete specification. “Make sign-up easier” gives a goal, but does not say who signs up, what information is needed, or what counts as easier. Before planning a solution, identify the people who will use it or be affected by it. Ask focused questions about their needs.

A requirement is a clear statement of something the solution must do or a condition it must meet. Keep each statement focused enough that the people involved can agree whether it has been met. “The form should be simple” is difficult to confirm because people may interpret “simple” differently. A clearer requirement might specify the information the form must collect and what confirmation a user should receive—but only if the people involved agree those are needed.

Separate what is known from what still needs an answer. Record assumptions as questions to confirm, not as settled facts. Ask who will use the solution, what information must be entered or displayed, what should happen when information is missing, and who can confirm that the result meets the need. The appropriate questions depend on the project.

A request is not necessarily a complete requirement.
Ask about users, expected actions, needed information, and unclear cases.
Make assumptions visible and confirm them rather than relying on them silently.

2. Confirm that requirements are understood and agreed

Confirmation is a conversation with the people responsible for the project and those whose needs it serves. Present proposed requirements in language they can understand, invite corrections, and check that important terms have the same meaning for everyone. A requirement is not confirmed just because it appears in a document or seems reasonable to a developer.

For each requirement, ask how the people involved would recognize that it has been met. A concrete example or a review of a proposed screen or process can reveal different interpretations. Record decisions and unresolved questions so a suggestion is not mistaken for an agreed need.

Requirements may change when people learn more or circumstances change. When someone requests a change, clarify what has changed, who needs to agree, and whether the current plan still addresses the intended need. This keeps the agreement clear; it does not mean accepting every requested feature without discussion.

Share proposed requirements with relevant people and invite corrections.
Use clear examples to expose different interpretations.
Record decisions and questions that remain unresolved.

3. Plan support beyond delivery

A delivered solution may still need assistance. Users may need help understanding how to use it, a problem may need to be reported and considered, or an agreed requirement may need review if circumstances change. Planning ongoing support means deciding how these needs will be handled rather than assuming that delivery ends the responsibility.

A support plan should identify who users contact, what information helps explain a problem, and who is responsible for considering it or deciding what happens next. Relevant instructions should be available to users and to the people providing support. A useful report can describe what the user was trying to do, what they expected, and what happened instead.

Make the plan fit the users and the project. A small class project might name an agreed contact and provide a short guide; another project may need a different arrangement. Review responsibilities with the people who will use and support the solution. Do not promise a response time or level of support unless it has actually been agreed.

Delivery does not automatically provide users with help or instructions.
Name an agreed contact and clarify who considers reports.
Keep support arrangements realistic and agreed, not assumed.

4. Keep the agreement and support plan connected

Confirmed requirements give users and support contacts a shared reference point. If a user reports that an expected task cannot be completed, the team can compare the report with the agreed requirement and ask for details. The report does not decide automatically whether the cause is a problem, a misunderstanding, or a changed need, but it gives people a clearer basis for discussing what to do.

A practical sequence is to clarify the need, write a focused requirement, review it with relevant people, record the agreement, and identify how users will get help after delivery. If the project changes, revisit the affected requirement and support arrangement with the people responsible. This sequence supports communication and planning; it does not guarantee that a solution will be free of problems.

Requirements help people discuss whether a solution meets an agreed need.
Support gives users a route for questions and reports after delivery.
When needs change, revisit both the relevant agreement and support arrangements.

Worked example

Turn a broad request into confirmable requirements

A school club asks for a way to collect event registrations. Show how to clarify the request and prepare requirements for review without assuming features the club has not requested.

Review proposed requirements

The club's decision determines whether to record agreement or clarify the draft.

Clarify the people and purpose
Ask who will submit registrations and who will use the collected information. The request does not tell us whether participants register themselves or an organizer enters their details, so leave that as a question to confirm.
Draft focused requirements
After the club answers, write only the needs it agrees to. For example, it might require collecting a participant name and event choice, and showing a confirmation after submission. These are proposed requirements for review, not facts established by the original request.
Review and record
Ask the club to check each statement and explain whether it matches its needs. Record corrections and unresolved details, such as who may view registrations. Do not treat that access decision as settled until the club confirms it.

Answer: The request becomes useful for planning after the club confirms who uses the process, what information is needed, and what should happen after submission. Keep undecided details visible.

Check: The proposed requirements are not confirmed just because they sound reasonable; the club must review and agree to them.

Worked example

Plan a clear route for user support

A class project delivers a simple equipment sign-out tool. Prepare an ongoing-support plan that helps users report problems and makes responsibilities clear, without promising resources that have not been agreed.

Support responsibilities

A proposed communication path. The contact and responsibilities must be agreed.

Identify users and contact
Name the intended users and an agreed person or role they can contact. If nobody has accepted responsibility, record that as an unresolved planning item rather than inventing an arrangement.
Explain what to report
Ask users to describe the task they attempted, what they expected, and what happened. This helps the responsible person understand the report. Avoid asking users to provide unrelated personal information.
Clarify response and instructions
Agree who reviews reports and who decides whether instructions, the solution, or the agreed requirements need attention. Provide concise usage instructions. Do not state a response deadline unless one has been agreed and can be supported.

Answer: A useful plan names an agreed contact, explains what information to include in a report, identifies who considers the report, and provides user instructions. Any missing responsibility or response commitment remains to be agreed.

Check: This plan describes a way to request help; it does not claim that the tool has been tested or that a particular support capacity exists.

Worked example

Respond to a changed need

After a club has agreed that its registration process collects participant names and event choices, a club leader asks to add an emergency contact field. Show how to handle the request while keeping requirements and support responsibilities clear.

Review a proposed change

Clarify the request, then record the decision with the responsible people.

Clarify the proposed change
Ask why the additional field is needed, who needs the information, and who should be able to see it. The request alone does not establish that collecting it is appropriate or agreed.
Review with responsible people
Share the proposed change with the people who can confirm the club's requirements. Ask whether the field belongs in the agreed process and what instructions users would need. Do not silently treat it as part of the original agreement.
Update the agreement if approved
If the relevant people agree, record the revised requirement and make sure the support contact knows about the change. If they do not agree or need more information, record the open question and keep the current agreement clear.

Answer: Treat the added field as a proposed change. Clarify its purpose, obtain agreement from the responsible people, and update the recorded requirement and relevant support information only if approved.

Check: A request from one person is not automatically an agreed requirement; confirmation remains necessary.

Common mistakes and how to avoid them

Treating a broad request as a complete requirement.

Correction: Ask what users need, clarify uncertain details, and have relevant people confirm the resulting statements.

Assuming that delivery means users will know how to get help.

Correction: Plan a clear contact route, useful instructions, and agreed responsibilities for considering reports.

Accepting every new request as an agreed change.

Correction: Clarify the proposed need and obtain agreement from the people responsible before revising requirements.

Promising a response time or level of support without agreement.

Correction: Describe only responsibilities and commitments that the project has actually agreed to provide.

Lesson summary

Clarify who needs the solution and what they expect it to do.
Write focused requirements and review them with relevant people.
Record agreements and unresolved questions so assumptions are not mistaken for decisions.
Plan who users contact, what information helps explain a problem, and who considers it.
When needs change, clarify the request and confirm any revision before treating it as an agreed requirement.

Check your understanding

Question 1

A client says, “The tool should be easy.” What is the best next step?

Treat “easy” as confirmed because the client stated it.
Ask what users need to do and what would show the client that the tool meets that need.
Add several features that commonly appear in similar tools.
Begin building immediately and ask for feedback only after delivery.

Show answer and explanation

Ask what users need to do and what would show the client that the tool meets that need.

The statement is open to interpretation. Clarifying the expected user task and an observable indication of success helps the client and project team agree on a more useful requirement.

Question 2

Which item best belongs in an ongoing-support plan?

A made-up promise that every report will be answered within one hour.
A named, agreed contact and instructions for reporting what the user expected and what happened.
A claim that the solution will never need changes.
A list of features that have not been requested or confirmed.

Show answer and explanation

A named, agreed contact and instructions for reporting what the user expected and what happened.

A support plan should explain how users can seek help and what information is useful. Do not invent response commitments or claim that future changes will never be needed.

Question 3

A new feature is requested after requirements were agreed. What should happen before it is treated as part of the agreement?

Add it automatically because any request changes the project.
Ignore it because requirements can never change.
Clarify the need and review the proposed change with the responsible people.
Ask users to assume the feature is included while the team decides.

Show answer and explanation

Clarify the need and review the proposed change with the responsible people.

A request should be clarified and confirmed with the relevant people. Record the decision or remaining question so the agreed requirements stay clear.

Key terms

Requirement: A clear statement of something a solution must do or a condition it must meet.
Confirm: Review a proposed requirement with relevant people, resolve or record uncertainty, and establish what they agree to.
Ongoing support: Arrangements for helping users and considering questions or problems after a solution is delivered.
Assumption: Something treated as true without confirmation; in project planning, it should be checked rather than quietly relied upon.

Continue through ICS4U

View the complete ICS4U Ontario Grade 12 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 12 Computer Science (ICS4U), expectation B1.5. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question