DoAssignment study guide

B4.2 · Clarify a program specification with stakeholders

Learn to clarify a program specification with stakeholders through clear examples and targeted practice.

Ontario Grade 11 Computer Science

Software Development

ICS3U study topic B4.2

A program specification describes what a program is expected to do. A stakeholder is someone affected by the program or involved in requesting or using it. The expectation B4.2 is to clarify a program specification with stakeholders: talk with the people connected to the program so that unclear requests become shared, understandable requirements. This is not guessing what someone meant. It is asking, listening, recording the answer, and confirming that the recorded meaning is right.

What you will learn

Explain why a programmer clarifies a specification with stakeholders before building a program.
Identify unclear or missing details in a request.
Ask focused questions and record answers as agreed program requirements.
Check that the stakeholder and programmer understand the clarified specification in the same way.

Why clarification matters

A request often begins as a short description of a need, not a complete set of instructions. For example, “Make a program to track club attendance” names a goal but leaves many details open. Does “attendance” mean recording who arrived, counting people, or both? Who will enter the information? What should happen if a name is missing?

Different people may use the same word differently. A club organizer may mean “late” as arriving after the meeting starts; a student may think it means arriving after a grace period. If the programmer silently chooses one meaning, the finished program may follow the programmer’s interpretation rather than the stakeholder’s need.

Clarification is a conversation that reduces this gap. It does not require advanced technical language. Ask about the purpose, users, information going in, expected results, and any important conditions. Record the answers in plain language, then read them back or otherwise ask the stakeholder to confirm them.

A stakeholder is connected to the program as a requester, user, or affected person.
A specification states what the program should do.
Clarifying means resolving uncertainty with stakeholders rather than making unsupported assumptions.

A practical clarification routine

Start by restating the request in your own words. This gives the stakeholder a chance to correct a misunderstanding early. Then identify words or situations that could have more than one meaning. Ask one focused question at a time, and listen for the specific answer rather than offering your own guess.

Useful questions include: Who will use the program? What information will they provide? What result do they need to see or save? What should happen in a particular situation, such as missing information or a repeated entry? Are there limits or rules the program must follow? Ask only questions that help make the request clearer.

Record decisions as statements that can be understood and checked. For instance, replace “show attendance clearly” with an agreed description of what information appears. Avoid turning a stakeholder’s answer into a more specific rule unless the stakeholder has agreed to that rule. If the answer is still uncertain, mark it as unresolved and ask again rather than treating it as settled.

Finish by confirming the clarified specification with the stakeholder. A useful confirmation is specific: summarize what information the program receives, what it does with that information, and what result it provides. Invite corrections. Keep the agreed wording available to the people involved so that the same interpretation can guide the work.

Restate the request, locate ambiguity, ask, record, and confirm.
Separate agreed requirements from questions that still need an answer.
Use stakeholder-approved wording; do not present guesses as requirements.

Think in terms of input, process, and output

Input, process, and output provide a simple way to organize clarification. Input is the information a user provides or selects. Process is what the program is expected to do with it. Output is what the user should receive or see. These are prompts for a conversation, not a substitute for asking the stakeholder what they mean.

For an attendance program, possible inputs might include a meeting date and students’ names. The process might involve recording each arrival. The output might be a list of attendees. Each detail needs confirmation: Is the date entered by a user? Should a name be recorded once or can it appear more than once? Should the result be a list, a count, or both?

No program code is needed to teach this expectation. The important work here is gathering and confirming requirements. Programming languages and classroom conventions may differ, but a clear shared understanding is useful before implementation in any language.

Use input, process, and output to find details that need clarification.
Treat each proposed detail as a question until the stakeholder agrees to it.
B4.2 concerns clarifying the specification with stakeholders, not writing a particular program.

From questions to shared understanding

A helpful clarification conversation stays close to the stakeholder’s goal. If an answer introduces a new unclear term, ask what that term means in the situation. For example, if someone says the program should list “active members,” ask what counts as active for this program. Do not assume that a familiar word has a single meaning.

After recording answers, review the specification as a whole. Check that the input, process, and output descriptions fit together and that important cases have not been left vague. Then ask the stakeholder to confirm or correct the summary. Agreement is shown by the stakeholder’s confirmation, not by the programmer’s confidence.

Clarification can reveal that a decision has not yet been made. In that case, record the open question and identify who can answer it. This is more accurate than inventing a rule. The aim is a specification that the people involved interpret consistently enough to guide the program’s work.

Check the meaning of important words in context.
An unanswered question stays unresolved; it is not an agreed requirement.
Confirmation gives stakeholders a chance to correct the written understanding.

Turning an attendance request into clarified details

Part to clarify	Question for the stakeholder	Status in the example
Input	What information will the club leader enter?	Confirmed: meeting date and attendee names
Process	What should the program do with that information?	Still needs clarification unless the organizer answers
Output	What result should the leader receive?	Confirmed: a list of names for the meeting
Unclear case	How should repeated names be handled?	Unresolved until the organizer decides

Worked example

Clarifying an attendance request

A club organizer says, “I need a program to track attendance.” Identify useful questions and show how the request could become clearer without inventing answers.

Restate the goal
Say, “You want a program that helps record attendance at club meetings.” This checks whether tracking attendance is the intended goal before exploring details.
Ask focused questions
Ask who will enter attendance, what information they will enter, and what result they want. The phrase “track attendance” does not yet specify an input or output.
Record only confirmed answers
Suppose the organizer confirms that a club leader will enter a meeting date and attendee names, and wants a list of those names for that meeting. Record those statements as agreed requirements. Leave any other details open until the organizer answers them.
Confirm the summary
Read the recorded requirements back to the organizer and ask whether they are accurate. This lets the stakeholder correct the specification before it is treated as settled.

Answer: The request becomes clearer when the organizer confirms who enters information, which information is entered, and what result is needed. The example’s meeting date, attendee names, and list are agreed only because the example states that the organizer confirmed them.

Check: The programmer does not decide how to handle repeated names unless the organizer clarifies that detail.

Worked example

Clarifying the word “late”

A teacher requests a program that marks students as late. Show how to resolve the ambiguity before recording this as a requirement.

Identify the unclear term
“Late” needs a shared meaning. The request does not say what event or time determines whether a student is marked late.
Ask for the rule
Ask the teacher what should count as late for this program. Do not choose a time or grace period yourself; either choice would add a rule that has not been confirmed.
Write the agreed meaning
If the teacher confirms a specific rule, record that rule in clear words and ask the teacher to verify the wording. If the teacher has not decided, record the question as unresolved instead.

Answer: The requirement can state what “late” means only after the teacher provides and confirms the rule. Until then, the classification is unclear and must not be guessed.

Check: A confirmed definition of “late” clarifies the specification; a programmer’s preferred definition does not.

Worked example

Confirming a request for a reminder program

A student group asks for a program that reminds members about meetings. Use input, process, and output to prepare a clarification conversation.

Ask about input
Ask what meeting information someone will provide, and who will provide it. The request does not say whether a date, time, location, or other detail is needed.
Ask about process
Ask what the program should do with the information. “Remind” could refer to different actions, so ask what action the group expects rather than assuming one.
Ask about output
Ask what members should receive or see, and when they should receive or see it. Record the group’s answers in plain language and ask them to confirm the summary.

Answer: The questions organize the conversation without pretending that the group has already chosen details. A specification is clearer only after the stakeholders answer and confirm the relevant questions.

Check: Input, process, and output are useful prompts, but they do not supply missing stakeholder decisions.

Common mistakes and how to avoid them

Treating a short request as a complete specification.

Correction: Look for missing details and ask stakeholders what they mean before recording requirements.

Choosing a rule because it seems sensible.

Correction: Ask the stakeholder to decide or confirm the rule; otherwise keep it marked as unresolved.

Using technical words the stakeholder may not understand.

Correction: Ask clear, focused questions in plain language and explain any necessary terms.

Writing down an answer without checking that it was understood correctly.

Correction: Summarize the agreed specification and invite the stakeholder to correct it.

Lesson summary

B4.2 focuses on clarifying a program specification with stakeholders.
A stakeholder is someone connected to the program as a requester, user, or affected person.
Restate the goal, ask about unclear details, record answers, and confirm the written understanding.
Input, process, and output can help organize questions, but stakeholder answers determine the requirements.
Do not turn guesses or unanswered questions into agreed requirements.

Check your understanding

Question 1

A request says, “Make a program that shows progress.” What is the best next step?

Choose a progress measure and begin coding.
Ask the stakeholder what progress means here and what result they want to see.
Assume progress means a percentage because that is common.
correctIndex": 1, "explanation": "The request is ambiguous. Asking what the stakeholder means and wants helps clarify the specification instead of adding an unconfirmed interpretation." }], "glossary": [{"term": "Stakeholder", "definition": "A person connected to a program as a requester, user, or someone affected by it."}, {"term": "Program specification", "definition": "A description of what a program is expected to do."}, {"term": "Clarify", "definition": "Resolve uncertainty by asking, recording, and confirming what stakeholders mean."}]}

Show answer and explanation

Ask the stakeholder what progress means here and what result they want to see.

The request is ambiguous. Asking what the stakeholder means and wants helps clarify the specification instead of adding an unconfirmed interpretation.

Question 2

A stakeholder has not decided what should happen when information is missing. What should the programmer record?

The programmer’s preferred rule as an agreed requirement.
The question as unresolved and seek the stakeholder’s decision.
Nothing, because missing information cannot affect a specification.
correctIndex": 1, "explanation": "An unanswered decision remains unresolved. Recording it as open avoids presenting a guess as a stakeholder-approved requirement." }], "glossary": [{"term": "Stakeholder", "definition": "A person connected to a program as a requester, user, or someone affected by it."}, {"term": "Program specification", "definition": "A description of what a program is expected to do."}, {"term": "Clarify", "definition": "Resolve uncertainty by asking, recording, and confirming what stakeholders mean."}]}

Show answer and explanation

The question as unresolved and seek the stakeholder’s decision.

An unanswered decision remains unresolved. Recording it as open avoids presenting a guess as a stakeholder-approved requirement.

Key terms

Stakeholder: A person connected to a program as a requester, user, or someone affected by it.
Program specification: A description of what a program is expected to do.
Clarify: Resolve uncertainty by asking, recording, and confirming what stakeholders mean.

Continue through ICS3U

View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation B4.2. 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