Requirements Elicitation Techniques and Use Case Development: Worked Library Example

Collecting stakeholder statements is not the same as producing testable requirements. Drawing actors and ovals is not yet a useful use case either. The requirements process moves from interviews, observation, a questionnaire, policy review, and a workshop to a traceable specification and acceptance checks. In the fictional campus library, every policy value remains consistent from evidence through modelling and acceptance tests.

Requirements elicitation: where it starts and what it must produce

Elicitation discovers stakeholder goals, constraints, assumptions, exceptions, and conflicts. The chain is: collect evidence, analyse and reconcile it, specify requirements, then validate the intended need. Software Requirements in Software Engineering: SRS, Elicitation and Validation with a Worked Example follows the wider lifecycle through SRS writing, validation, traceability, and change control. The library reservation here concentrates on choosing evidence sources and developing one use case from them.

Outputs are a stakeholder map, evidence log, rules, functional and non-functional requirements, a use-case diagram, a fully dressed use case, and acceptance criteria. “Members need faster service” is raw input. “Show reservation confirmation within 2 minutes” is measurable; its threshold needs agreement.

For document placement, standards context, and a tested lab-booking specification, use SRS Document Structure and Standards: A Worked Lab Booking Specification. The library reservation instead traces raw elicitation evidence into actors, UC-07, alternate flows, and acceptance criteria.

How to choose an elicitation technique

They complement one another: interviews find reasons, observation behaviour, questionnaires breadth, documents rules, workshops agreement, and prototypes interface confusion. Focus groups compare views; brainstorming generates options. Match “why” to interviews, reported-versus-actual work to observation, repeated closed questions to questionnaires, rules to documents, conflict to workshops, and uncertain interaction to prototypes.

Worked example, part 1: evidence into requirements

For the fictional goal “Reserve an unavailable library title”, stakeholders are Student, Librarian, Notification Service owner, and Library Administrator:

• EV-OBS-01: During 12 book-seeking sessions in a 30-minute peak, 3 requested titles had zero copies. Staff manually noted a name in 2 of those 3 cases.

• EV-SUR-01: Of 120 invited students, 84 responded and 57 wanted an automatic notification. Response rate = 84 / 120 x 100 = 70%. Respondent preference = 57 / 84 x 100 = 67.9% to one decimal place, not 67.9% of all invitees.

• EV-DOC-01: The fictional policy allows at most 3 active loans and 2 active reservations per member, with 48 hours to collect an assigned copy.

• EV-WS-01: Students requested 72 hours, the librarian proposed 24 hours, and the workshop retained the documented 48-hour rule.

Derived artefacts are: BR-01, member must be active; BR-02, reservations below 2; BR-03, assignment expires after 48 hours; FR-01, reserve a zero-copy title; FR-02, join after existing reservations; FR-03, show position; FR-04, request notification; NFR-01, display and dispatch within 2 minutes. NFR-01 needs validation.

Worked example, part 2: build the use-case model

The Campus Library System boundary leaves Student and Librarian outside as human roles, and Notification Service outside as a supporting system. An actor is a role with a goal, not a person, table, screen, or system.

Inside are Reserve Book, Validate Membership, Check Reservation Limit, Send Reservation Confirmation, Process Book Return, and Notify Next Member. Reserve Book uses <<include>> for the three required sub-behaviours. Notify Next Member uses <<extend>> for a non-empty queue; its arrow points to Process Book Return.

Worked example, part 3: specify UC-07

Main flow: (1) Student requests BK-207. (2) System validates active M-104. (3) It reads 1 reservation and confirms 1 < limit 2. (4) It confirms 0 copies and queue 2. (5) It creates R-501 at position 3. (6) It displays both. (7) It requests the same Notification Service confirmation, measuring display and dispatch against 2 minutes.

Alternate and exception flows. A2: if M-104 is inactive, the system rejects the request and creates nothing. A3: if the member already holds 2 reservations, it reports the limit reached and leaves the queue unchanged. A4: if BK-207 has 1 copy, it offers normal borrowing instead of wait-listing. E5: if a duplicate request arrives with the same idempotency key, it returns the existing R-501 rather than creating R-502. A step earns a place in these flows only when it changes behaviour, so ordinary clicks stay out.

• AC-01: Given active M-104 with 1/2 reservations, BK-207 availability 0, and queue 2, when reserving, then R-501 has position 3.

• AC-02: Given count 2/2, when reserving, then create nothing.

• AC-03: Given inactive M-104, when reserving, then create nothing.

• AC-04: Given assignment at 09:00 on 18 July 2026, when calculating the deadline, then return 09:00 on 20 July 2026, exactly 48 hours later. The date is fictional.

Common traps in elicitation and use cases

• Picking a technique out of habit, with no question behind it, collects irrelevant evidence. Start from the uncertainty you actually need to close.

• “Fast” and “easy” are untestable. Define a measure.

• A named student is not an actor. Model the Student role.

• Notification Service inside the boundary hides dependency. Keep it outside.

• Reversed relationships change meaning. Point <<include>> to required behaviour and <<extend>> to its base.

• Button instructions bind one interface. Describe intent and responsibility.

• Calling 57/84 “67.9% of all 120” swaps the denominator. State the base every percentage is taken on.

• Changing 48 to 72 hours breaks consistency. Trace rules to approved sources.

In objective questions, one changed word can shift an answer from evidence collection to modelling, or from a functional requirement to a quality target.

How exams can test these concepts

A common question asks which technique fits a situation: observation when reported work differs from actual work, or a workshop when 72 hours and 24 hours have to be reconciled. Others ask you to classify “maximum 2 active reservations” as a business rule, “confirmation within 2 minutes” as a non-functional requirement, mandatory Validate Membership as <<include>>, and conditional Notify Next Member after Process Book Return as <<extend>>.

A numerical question can test the denominator: 84 / 120 x 100 = 70%, while 57 / 84 x 100 = 67.9%. Classification questions test whether a statement is a business rule, functional requirement, or non-functional requirement. Exam pattern and marks still come from the official notification for the applicable cycle.

Short version and the next practice step

1. Match the technique to the uncertainty.

2. Keep evidence IDs.

3. Separate rules, functional requirements, and quality targets.

4. Define actors and the boundary before relationships.

5. Test the main and alternate flows with unchanged values.

Use NTA UGC NET Paper 2 for the complete subject sequence, or the NET catalogue to compare related courses and test series.