Requirements Engineering I: Discovering Needs

What is a requirement?

A requirement is a statement of something the system must do, or a property it must have, to be useful to its stakeholders. Good requirements describe what is needed and why, not how it will be built.

Requirements come in three kinds:

• Functional requirements — what the system does: "A student can report an inappropriate post."
• Non-functional (quality) requirements — how well it does it: performance, reliability, usability, security (Chapter 1's quality attributes). "A reported post is hidden from other students within 1 minute."
• Constraints — limits on the solution: "The system must run on the university's cloud servers in mainland China"; "It must be finished by week 15"; "Only open-source libraries with permissive licences."

Engineers also separate user requirements (in the stakeholder's language, for the stakeholder) from system requirements (detailed, precise, for the developers and testers). Both are needed: the first to agree on the need, the second to build and test it.

Stakeholders: who decides what "useful" means?

A stakeholder is anyone who affects or is affected by the system. Users are only one group. For StudyBuddy:

A power/interest grid helps plan communication: high power + high interest → manage closely (instructors); high power + low interest → keep satisfied (IT); low power + high interest → keep informed (students, TAs); low power + low interest → monitor.

Why eliciting requirements is hard

We call it elicitation (drawing out), not "collection", because requirements are rarely lying around ready to be picked up:

1. People do not know what they want until they see something — then they know what they don't want ("yes, but…").
2. Tacit knowledge: experts do things so automatically that they forget to mention them ("of course we never publish grades before the exam board meets").
3. Say ≠ do: people describe the ideal process, not what they really do.
4. Conflicts: students want complete answers; instructors want hints only.
5. Different vocabulary: "course" may mean a subject (CPS 4301) or one section (W03).
6. Change: needs change while the system is built — and because it is built.

Elicitation techniques

Good teams combine techniques: interview five students, observe two study sessions in the library, run a survey to see how common the discovered problems are, then test a paper prototype.

Interviewing well

Most requirements work starts with interviews, and most interviews are done badly. Rules of thumb:

• Ask open questions ("How do you prepare for a CPS exam?") before closed ones ("Do you use WeChat groups?").
• Do not lead. "Wouldn't it be great if an AI answered your questions?" tells the person what to say. Ask "What happens when you get stuck on an exercise at 11 p.m.?"
• Ask about the past, not the future. "Tell me about the last time you looked for a study partner" gives facts; "Would you use a matching feature?" gives polite guesses (people say yes to be nice).
• Ask "why?" — often more than once — to move from solutions to needs.
• Listen more than you talk; do not pitch your idea during an interview.
• Summarize and confirm at the end: "So the main problem is…, is that right?"
• Get consent before recording, and protect the recording — it is personal data.

User stories: small pieces of value

Agile teams usually write requirements as user stories:

As a first-year student, I want to see classmates in my course who are free at the same time as me, so that I can form a study group before the midterm.

The three parts answer who, what and why. The "so that" part is often skipped — and it is the most important, because it lets the team judge whether a different solution would meet the same need.

A story is not a full specification. Ron Jeffries described the 3 Cs: the Card (a short reminder), the Conversation (the team and stakeholders discuss details), and the Confirmation (acceptance criteria that say when it is done).

INVEST — six qualities of a good story:

Acceptance criteria: Given / When / Then

Acceptance criteria turn a story into testable statements. A popular format from Behaviour-Driven Development (BDD) is Given / When / Then:

Scenario: Two students with overlapping free time are matched
  Given Ana and Ben are both enrolled in CPS 4301
    And both marked Thursday 19:00-21:00 as free
  When Ana opens "Find study partners" for CPS 4301
  Then Ben appears in her list
    And the shared time "Thu 19:00-21:00" is shown

Scenario: Students in different courses are not matched
  Given Ana is enrolled in CPS 4301 and Chen is not
  When Ana opens "Find study partners" for CPS 4301
  Then Chen does not appear in her list

• Given — the starting situation (context, data).
• When — the one action or event being tested.
• Then — the observable outcome.
• And / But — continue the previous step.

Good criteria cover the happy path, the important alternative paths and the edge cases (no free time entered, the student is the only one in the course, overlapping by only 5 minutes).

Personas, story maps and the MVP

A persona is a realistic, specific description of a typical user, built from research, used to keep the team focused on real people: "Yuki, 19, first-year CS student from Shanghai, commutes 50 minutes, studies late at night, shy to ask questions in class, uses her phone for everything." Designing for Yuki leads to different choices (mobile first, anonymous questions) than designing for "users".

A story map (Jeff Patton) arranges stories along the user's journey (left to right: join course → ask a question → get help → find partners → prepare for the exam) and by priority (top to bottom). Cutting a horizontal line across the map gives the minimum viable product (MVP): the smallest release that lets users complete the whole journey and gives the team real feedback.

The Kano model: not all features are equal

Professor Noriaki Kano classified features by how they affect satisfaction:

Kano surveys ask two questions per feature: "How would you feel if the app had X?" (functional) and "How would you feel if it did not have X?" (dysfunctional), each answered with I like it / I expect it / I am neutral / I can tolerate it / I dislike it. The pair of answers gives the category. Delighters become must-bes over time — yesterday's surprise is tomorrow's expectation.

The AI angle: AI as an elicitation assistant

AI tools can help at several points:

• Preparing: drafting an interview guide, listing stakeholders you forgot, reading a university policy and summarizing its rules.
• Analysing: grouping 200 survey comments into themes; turning an interview transcript into draft user stories.
• Checking: finding missing edge cases in acceptance criteria ("What if the student has no free time entered?"), spotting vague words.

And the risks:

1. Invented requirements (hallucinations). Ask an AI for "requirements for a study app" and you get a generic list — gamification badges, dark mode, social feeds — that no WKU stakeholder asked for. Every requirement needs a source: a person, a document, or data. Requirements without a source are only ideas.
2. The AI is not your user. An AI can simulate "a typical student", but it has never missed a bus to Wenzhou or tried to find a partner the night before a CPS midterm. Simulated users are useful for preparing questions, never as a replacement for real people.
3. Privacy and consent. Uploading a recorded interview with an instructor to an external AI service is a data transfer. Get consent, remove names, or use a tool approved by the university.
4. Bias toward the average. AI proposes what is common in its training data; your stakeholders' special needs (Chinese and US regulations, Chinese-English bilingual students) may be exactly what is uncommon.

Requirements for an AI feature

Buddy itself is an AI feature, and it needs requirements that ordinary features do not:

• Scope: "Buddy answers only from the materials the instructor uploaded for that course; otherwise it says it does not know."
• Quality measure: "In a monthly sample of 50 answers reviewed by the instructor, at least 90% are correct and cite a source."
• Behaviour on uncertainty: "If no relevant material is found, Buddy suggests posting the question on the Q&A board."
• Policy: "Buddy gives hints, not complete solutions, for exercises the instructor has tagged as graded."
• Fallback: "If the AI service does not respond within 10 seconds, the student sees a clear message and can post to the board instead."

These are elicited from instructors, IT and students like any other requirement — and they will need special testing methods (Chapter 9).

Key takeaways

• A requirement says what and why; a design says how. Ask "why?" to turn solutions into needs.
• Functional requirements, non-functional (quality) requirements and constraints are all needed; user requirements and system requirements serve different readers.
• Identify all stakeholders; use a power/interest grid to plan how to involve them.
• Elicitation is hard (unknown needs, tacit knowledge, say ≠ do, conflicts); combine techniques.
• Interview with open, non-leading questions about past behaviour; get consent.
• User stories: As a… I want… so that…; check with INVEST; confirm with Given/When/Then acceptance criteria covering edge cases.
• Personas keep the team focused on real people; a story map helps cut an MVP; the Kano model shows which features are must-be, performance or delighters.
• AI helps prepare, analyse and check — but every requirement needs a real source, and interview data must be protected.