Before changing a program, you need to understand what the requested result is.
A programming specification describes requirements for the software.
It may tell you:
The specification tells you what the work is supposed to accomplish.
It is not the same thing as the finished code.
Consider this small soccer requirement:
The coach needs to see the team name and whether the selected player is available for Saturday's match.
Before thinking about C# syntax, identify the need.
The coach needs information that supports a lineup decision.
That tells you why the program behavior matters.
Now imagine the specification says:
Display the selected player's name and availability for the current match.
That is a required result.
It does not automatically say:
Do not turn your first implementation idea into a requirement.
Read what the specification actually says.
A useful specification often contains statements that can be checked.
For example:
The program displays the team name.
The program displays the selected player's name.
The program shows whether that player is available.
The supplied project structure remains unchanged.
Each statement gives you something specific to preserve or produce.
Vague phrases such as “make it better” are much harder to implement because they do not define observable success.
Technical specifications often use exact names.
If the supplied program refers to a file, project, object, control, or field by a particular name, that name may be part of the expected structure.
Do not rename something simply because another name seems more natural.
In shared technical work, exact names help instructions, code, tools, and feedback refer to the same thing.
A programming task usually starts from an existing state.
The specification may assume that:
Your job is not automatically to recreate all of those things.
Determine what is already provided before deciding what must change.
Suppose a soccer application already displays the team name correctly.
The new specification asks you to add player availability.
The existing team display is part of the starting program.
Unless the specification requires a change to it, preserve it.
This is an important habit in programming:
Change what the requirement calls for; preserve unrelated working structure.
Unnecessary changes make technical work harder to review and troubleshoot.
A specification becomes easier to work with when you turn each requirement into a question.
For:
The program displays the selected player's name.
ask:
Where does the program get the selected player's name, and where should that information appear?
For:
The program shows whether the player is available.
ask:
What information represents availability, and what result should the user see?
You do not need to know the code answer immediately.
The questions help you identify what you need to investigate in the supplied project.
When you open the Visual Studio solution, keep the specification beside you.
Do not browse every file with equal attention.
Use the requirement to guide where you look.
If the task concerns what appears in a window, you may need to locate the files related to that window.
If the task concerns a Player object, you may need to locate the file that defines or uses that part of the program.
The specification gives your exploration a purpose.
You have already used UML to represent objects, values, and relationships.
A programming specification may describe the same system in words.
For example:
A player has a name and availability value and belongs to a team.
A UML object diagram can show one specific snapshot of those ideas.
C# code can later create and work with corresponding objects.
The three representations serve different purposes:
Specification — describes what the software needs to represent or accomplish.
UML model — gives a visual representation of selected system structure or state.
C# code — gives executable instructions and definitions used by the program.
The course will increasingly ask you to connect those representations.
A specification for one activity should not be treated as permission to redesign the entire application.
If the current task asks you to work with one object and one simple value, do not add:
Solve the requirement in front of you using the concepts currently available.
When you receive a programming specification, read it in this order:
Only after those questions are clear should you begin making code changes.
Programming becomes much easier to reason about when the code is treated as a response to a clear requirement rather than as the starting point.