B1.1.1 Constructing a Problem Specification Notes

A poor example of a problem statement

“Our school’s database system is outdated.”

• This statement is vague and does not identify the specific issue.
• “Outdated” could mean many things: slow query responses, poor user interface, lack of integration with other systems, or limited storage.
• The problem also lacks justification.
• Why is being “outdated” harmful?
• Does it make it harder for teachers to access student grades, cause delays in report generation, or create security risks?

A better example of a problem statement

“Teachers spend an average of 15 minutes generating each student’s progress report because the database does not support automated report templates, leading to late distribution of term reports and frequent errors in student records.”

• This is a strong problem statement because it is specific, measurable, and linked to consequences.
• It identifies the precise problem (no automated templates), quantifies its impact (15 minutes per report, frequent errors), and links it to a negative consequence (late distribution, reduced reliability of student records).

Another strong example

“The current attendance system requires students to sign in on paper sheets, which then need to be manually entered by staff. This process delays attendance records by up to 24 hours and increases the risk of data entry errors, causing inaccurate student absence tracking.”

This is also effective because it:

• Highlights the workflow problem (manual entry of paper sheets).
• Provides quantifiable impact (24-hour delay).
• Identifies a real consequence for the client (inaccurate absence tracking).

A poor example of a constraint and limitation

“We don’t have many resources to fix our school portal.”

• This is vague and provides no guidance about what “resources” means.
• It could refer to money, staff, technology, or time.
• The impact of the limitation is also unclear.
• How exactly does this shortage of resources affect the project’s possible solutions?
• Without specifics, the limitation does not help in planning a realistic solution.

A better example

“The IT budget for upgrading the school portal is limited to $8,000, and additional hardware purchases are not allowed due to district policy.”

• This is a strong constraint because it is specific, measurable, and clearly stated. It identifies the exact budget limit ($8,000), the type of constraint (financial and technical), and the external factor (district policy).
• It makes clear what is and isn’t possible, which helps guide realistic decision-making during system design.