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.

Scenario 1

• Objective: Enhance the school’s online learning experience.
• Goals: Reduce average system downtime by 50% within 3 months; ensure 95% of logins succeed on the first attempt.
• Reasoning:
  • This objective is broad and aspirational (“enhance learning experience”), but the goals are measurable and time-bound (downtime reduced by 50% in 3 months, 95% login success).
  • The goals are directly linked to the objective, and they allow the client to check whether improvements are being achieved.

Scenario 2

• Objective: Improve student and parent satisfaction with the portal.
• Goals: Achieve an average rating of 4.5/5 on parent surveys within 6 months; cut “unsatisfied” responses by 30% within the next term.
• Reasoning:
  • This example connects a high-level objective (improve satisfaction) with clear, quantifiable targets (4.5/5 average, 30% fewer unsatisfied responses).
  • The goals are measurable and time-constrained, allowing the school to verify success and showing exactly how satisfaction will be tracked.

• Input type: Online learning system usage logs and user feedback.
• Formats: Numerical values (average session length in minutes), categorical values (login success/failure), open-ended feedback (comments).
• Characteristics: Data must directly relate to system performance and user experience, be both quantitative and qualitative, and if possible link to individual accounts for targeted support.
• Reasoning:
  • This is a good example because it defines both the type and format of the input (quantitative logs, qualitative comments), explains the characteristics (relevant to system use), and highlights compatibility (linking back to user accounts).
  • It ensures clarity for developers while keeping the focus on client needs.

Student Learning App

• An online revision platform provides personalized reports to students and teachers every week.
• These reports include visual dashboards with graphs that show the number of practice questions attempted, time spent studying each subject, and comparative scores against class averages.
• Alongside the visuals, the system generates written summaries identifying common areas of weakness, such as repeated mistakes in algebra or difficulty with interpreting graphs in biology.
• In urgent cases, the system sends automatic alerts when performance drops sharply (for instance, if a student suddenly fails several assignments in a row), allowing teachers to intervene quickly.
• Output reports are also customizable, so that teachers can filter results by subject, timeframe, or specific groups of students.
• This ensures that the data is actionable, easy to understand, and directly linked to supporting learning outcomes.

School Online Homework System

• The school introduces a digital homework submission system and sets out clear benchmarks to evaluate its success.
• The first measure is effectiveness: whether students can reliably upload assignments and teachers can easily mark them.
• The second is efficiency: how quickly the system processes dozens of submissions at once, especially during peak times when multiple deadlines overlap.
• The system is also tested for accuracy, ensuring that automated grading tools consistently mark work against the correct rubric without errors.
• Another benchmark is usability, measured by feedback from both teachers and students on how intuitive the interface is to use.
• Finally, the system must demonstrate maintainability, meaning it should be easy for IT staff to update when syllabuses change or when new coursework requirements are added.
• Collectively, these evaluation criteria help the school decide if the system is truly fit for long-term use.