[Class Report] Systems Development (2nd Year) — Week 33
~ Introduction to Requirements Definition: Putting “whose what are we solving” into words ~
In Week 33, we took our first proper step into system design as second-year students: requirements definition (requirements consolidation). This was a hands-on session where teams dug into “whose problem are we solving, and what exactly, before we build anything?”
■ Teacher’s Kickoff: “Design begins with a crystal-clear purpose”
Mr. Tanaka: “No matter how good your code is, if the problem you’re solving is fuzzy, you won’t end up with a good system. First, identify your users and stakeholders, and put into words what you’re trying to achieve.”
On the board, the teacher introduced a basic frame for requirements definition using the prompts Who / What / Why / When / How much.
■ Today’s Warm-up: Create a Stakeholder Map
We started by making stakeholder maps. Each team chose a project target (e.g., improving the school library system, a club reservation app) and listed people and organizations involved.
- Student A: “Students will use it, but teachers and library assistants are involved too.”
- Student B: “Admins will worry about whether updates and approvals add extra workload.”
Mapping stakeholders surfaced conflicts of interest and priorities and gave hints on setting the right granularity for requirements.
■ Exercise ①: Capture “what users want” with User Stories
Next, we wrote user stories (short, single-sentence format) to express feature requests from the user’s perspective. We used the familiar template:
“As a (who), I want to ~, so that ~.”
Examples:
- “As a library assistant, I want to see the loan status at a glance, so that I can send overdue notices quickly.”
- “As a first-year student, I want to easily check the availability of popular books, so that I can find what I want to borrow.”
Student C: “This format makes why we need the feature crystal clear.”
■ Exercise ②: Write Acceptance Criteria
Beyond user stories, we practiced specifying acceptance criteria—the concrete conditions under which a feature is considered complete.
Example (acceptance criteria for a story)
- Entering part of a title in the search field shows up to 10 matching books.
- Items with zero stock display “Unavailable” in red.
- Admins can download the lending history as a CSV.
Student D: “Once you write the criteria, the test cases basically pop out!”
■ Exercise ③: Quick Interviews & Persona Creation
To dig into real requirements, we did mock interviews in each team. One person played the user; another played the interviewer to probe needs and pain points. Based on results, we created a one-page persona (representative user).
- Persona examples: age, role, daily routine, pain points, desired improvements
- Student E: “Having a persona makes it easier to set feature priorities!”
■ Reflection: Prioritizing Features with MoSCoW
Finally, we classified the gathered requests using the MoSCoW method (Must / Should / Could / Won’t). This helped the team agree on what is absolutely necessary now and what can wait.
Student F: “You want to do everything, but I learned that prioritizing is the key to project success.”
■ Teacher’s Closing Comment
“Requirements definition is map-making for design. The more carefully you dig, the less you’ll get lost later in design and implementation. Today’s results will be the foundation for next week’s UML and data design.”
■ Homework (for next time)
- Submit the stakeholder map, 3 user stories, and 3 acceptance criteria compiled by your team.
- Create a one-page (A4) profile for one persona of your own.
- The team’s presenter should prepare a 2-minute explanation of your requirements definition for next week’s UML session.
■ Coming Up Next Week: Drawing “Structure” and “Behavior” with UML
Next week, using today’s requirements, we’ll practice drawing class diagrams (attributes/methods) and sequence diagrams (flow of processing). When requirements are solid, UML goes smoothly—so take good care of today’s work!
In Week 33, students learned to put user problems into words. By building consensus as a team on the “reason for building,” they laid solid conceptual foundations for design.