Requirements, UX and Application Design

Introduction

A graphical user interface or web application is successful only when it solves a real problem for its intended users. Programming skill alone does not guarantee success. An application may be technically correct yet fail because it is confusing, inaccessible, inefficient, insecure, or inconsistent with stakeholder expectations. Requirements analysis and user-centred design provide the bridge between a problem in the real world and an implementable Python application.

In this chapter, the term application includes desktop programs developed with Tkinter and web applications developed with Flask. Although the technologies differ, both require the developer to understand users, define system behaviour, design interactions, and establish objective conditions for acceptance.

The development process considered here is iterative rather than strictly linear:

1. Discover stakeholder needs.
2. Analyse and prioritise requirements.
3. Model users, tasks, and system boundaries.
4. Create interface prototypes.
5. Evaluate usability, accessibility, responsiveness, and ethical implications.
6. Define acceptance criteria.
7. Implement, test, and revise the design.

A well-designed interface is not merely attractive. It enables users to achieve meaningful goals accurately, efficiently, safely, and with an appropriate level of confidence.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish stakeholder needs, requirements, constraints, and assumptions;
• write clear functional and non-functional requirements;
• identify stakeholders, personas, user journeys, and user stories;
• translate user stories into testable acceptance criteria;
• apply prioritisation techniques to a realistic project;
• design low-fidelity prototypes for Tkinter and Flask applications;
• apply usability, accessibility, responsive-design, and ethical principles;
• evaluate requirements for ambiguity, feasibility, completeness, and consistency;
• communicate design decisions professionally to technical and non-technical stakeholders.

1. From Stakeholder Needs to Requirements

1.1 Stakeholders and their needs

A stakeholder is any person, group, or organisation that affects, is affected by, or has a legitimate interest in the application. Stakeholders may include:

• direct users, such as students, customers, patients, or administrators;
• sponsors who provide funding or define business objectives;
• managers who monitor performance or approve processes;
• support staff who handle errors and user queries;
• legal, security, or accessibility specialists;
• external services and organisations that exchange data with the system.

A need is a desired outcome expressed in user or organisational language. For example, a library user may say, “I want to know whether a book is available before travelling to campus.” This is not yet a complete software requirement. It identifies a problem and desired outcome but does not specify the exact system behaviour.

A requirement is a documented, necessary, and verifiable statement about what a system must provide or how it must operate. Requirements should be sufficiently precise for designers, developers, testers, and stakeholders to interpret them consistently.

The transformation can be represented as:

Need → Goal → User story → Requirement → Acceptance test

For example:

• Need: A student wants to find available rooms quickly.
• Goal: Locate a free room for a selected date and time.
• User story: “As a student, I want to search rooms by date and time so that I can reserve a suitable room.”
• Requirement: “The system shall allow an authenticated student to enter a date and time interval and display rooms available for that interval.”
• Acceptance test: Given a valid interval, when the student submits the search, then the system displays only rooms with no conflicting reservation.

1.2 Requirements, constraints, assumptions, and risks

These terms should not be used interchangeably.

Unrecorded assumptions are dangerous. If a team assumes that every user has a modern browser, reliable internet, or a large screen, the resulting design may exclude important users. Assumptions should therefore be documented and validated.

1.3 Eliciting requirements

Requirements elicitation is the systematic discovery of stakeholder expectations. Common techniques include:

• Interviews: useful for detailed experiences, motivations, and exceptions.
• Observation: reveals actual behaviour, workarounds, interruptions, and environmental constraints.
• Questionnaires: collect comparable responses from many people, but may lack depth.
• Workshops: allow stakeholders to negotiate priorities and resolve conflicting views.
• Document analysis: identifies rules, terminology, policies, and existing data structures.
• Prototyping: gives stakeholders something concrete to react to.
• Support-ticket analysis: reveals recurring failures in an existing service.

A strong interview question is specific and open-ended: “What happens after a booking is rejected?” A weak question encourages a preferred answer: “Would you like a convenient booking button?”

Elicitation should investigate normal cases, exceptional cases, accessibility needs, privacy expectations, security concerns, and the context in which work is performed.

2. Functional and Non-Functional Requirements

2.1 Functional requirements

Functional requirements describe services, behaviours, inputs, outputs, and responses. They answer the question: What must the system do?

Examples include:

• The system shall allow a user to create an account using a valid email address.
• The system shall calculate the total price from the selected items and applicable tax.
• The system shall display an error message when a required field is empty.
• The system shall allow an administrator to deactivate a user account.

Functional requirements often describe:

• data entry and validation;
• calculations and business rules;
• search, filtering, and sorting;
• authentication and authorisation;
• storage, retrieval, and modification of data;
• notifications and reports;
• integration with external systems.

2.2 Non-functional requirements

Non-functional requirements describe qualities, constraints, and operational conditions. They answer the question: How well, under what conditions, or according to which constraint must the system operate?

A non-functional requirement should be measurable where possible. “The page should load quickly” is vague. “The results page shall become usable within two seconds for 95% of requests under the defined test workload” is more testable. The measurement must identify the workload, environment, and measurement point; otherwise different testers may obtain incomparable results.

2.3 Qualities of good requirements

A high-quality requirement is:

• Correct: it reflects a genuine stakeholder need.
• Unambiguous: it has only one reasonable interpretation.
• Complete: necessary conditions and exceptions are included.
• Consistent: it does not conflict with another requirement.
• Feasible: it can be delivered within available resources and constraints.
• Verifiable: a test, inspection, demonstration, or analysis can determine compliance.
• Traceable: its source and related design and tests can be identified.
• Prioritised: its relative importance is known.

Avoid vague terms such as “easy,” “fast,” “user-friendly,” and “appropriate” unless they are operationally defined.

2.4 Requirements traceability

Traceability connects a requirement to its source, design element, implementation, and test. A simple traceability record may contain:

Traceability helps identify unimplemented requirements, redundant features, and tests that do not correspond to an agreed need. It is particularly valuable when requirements change.

3. Users, Tasks, and User Stories

3.1 Personas

A persona is a research-informed representation of a significant user group. It normally includes goals, context, abilities, frustrations, and relevant technical conditions. A persona is not a stereotype; it should be based on evidence from interviews, observation, analytics, or domain knowledge.

For example:

Amina, an undergraduate student: uses a mobile phone frequently, occasionally uses an older laptop, has limited time between lectures, and needs clear feedback when a booking fails. Her goal is to reserve a room without understanding the institution’s internal scheduling rules.

Personas keep design discussions focused on user goals rather than the preferences of the development team.

3.2 User journeys and task analysis

A user journey describes the stages through which a person moves while achieving a goal. A booking journey might include discovering the service, signing in, searching, selecting a slot, confirming details, receiving confirmation, and later cancelling.

Task analysis decomposes an activity into actions, decisions, information needs, and possible errors. It can reveal unnecessary steps and opportunities for better feedback.

A task is usually efficient when the user can:

1. understand what is possible;
2. identify the required information;
3. perform the action;
4. understand the result;
5. recover from errors without losing useful work.

3.3 User stories

A common user-story structure is:

As a [role], I want [capability], so that [benefit].

Example:

As a student, I want to cancel my own future reservation so that another student can use the room.

The story describes value, not implementation. It should be accompanied by acceptance criteria and, where necessary, business rules. A story should be small enough to estimate and implement, but meaningful enough to deliver user value.

The INVEST mnemonic is useful when reviewing stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable. It is a heuristic rather than an absolute law; some stories will have dependencies because real systems contain shared rules and infrastructure.

3.4 Roles and permissions

A requirement must distinguish authentication from authorisation. Authentication answers “Who is this user?” Authorisation answers “What may this authenticated user do?”

For instance, a student may create and cancel their own booking, while an administrator may view all bookings and modify room availability. These permissions should be stated explicitly rather than hidden in interface assumptions.

4. Acceptance Criteria and Validation

Acceptance criteria define the conditions under which a stakeholder accepts a feature. They convert a general story into observable behaviour.

A useful format is Given–When–Then:

• Given the initial context,
• When the user or system performs an action,
• Then the expected result occurs.

Example:

Story: As a student, I want to reserve an available room so that I can conduct a group meeting.

• Given the student is authenticated and the room is available,
• When the student selects the room, enters a valid time interval, and confirms,
• Then the system creates one reservation and displays its reference number.

Additional criteria should address failure conditions:

• Given the room is already reserved,
• When the student submits the request,
• Then the system does not create a duplicate reservation and explains that the slot is unavailable.

Acceptance criteria should cover:

• valid inputs;
• invalid, missing, and boundary inputs;
• permissions and authentication;
• data persistence;
• error messages and recovery;
• accessibility and keyboard operation;
• responsive behaviour where relevant;
• privacy and security expectations.

Acceptance criteria are not the same as implementation instructions. “Use a Tkinter Entry widget” is a design or implementation decision. “The user can enter and correct a booking date” is behaviour that can be accepted independently of the particular widget.

5. Prioritisation and Scope

Projects have limited time, budget, technical capacity, and user attention. Prioritisation makes trade-offs visible.

The MoSCoW method classifies features as:

• Must have: essential for the product to be viable;
• Should have: important but with a possible workaround;
• Could have: desirable if resources permit;
• Won’t have this release: deliberately excluded for the current scope.

For a first booking application, account login, availability search, and booking confirmation may be Must-have features. Calendar synchronisation may be a Should-have feature, while colour themes may be a Could-have feature.

Prioritisation should consider user value, risk, legal obligations, dependencies, cost, and learning value. Accessibility and security should not be treated as optional decoration when they are necessary for lawful and safe operation.

Scope statements are equally important. A project might explicitly exclude payment processing, automated room allocation, and integration with external calendars. Clear exclusions reduce expectation conflicts.

6. User Experience and Interaction Design

User experience (UX) encompasses the perceptions, emotions, behaviours, and outcomes associated with using a product. User interface (UI) is the visible and interactive part of that experience. UI is therefore one component of UX, not a synonym for it.

6.1 Usability principles

Important usability principles include:

• Visibility of system status: show progress, loading, saving, and completion states.
• Match with the real world: use familiar language and meaningful sequences.
• User control: support cancellation, undo, and safe recovery where appropriate.
• Consistency: similar actions and terms should behave similarly.
• Error prevention: constrain invalid input and confirm risky actions.
• Recognition rather than recall: show options and relevant information instead of requiring users to remember it.
• Error recovery: explain what went wrong and how to fix it.
• Minimalism: present necessary information without avoidable clutter.
• Help and documentation: provide assistance at the point of need.

A good error message is specific, respectful, and actionable. “Invalid input” is weak. “Enter a date in the format YYYY-MM-DD; the date cannot be in the past” is more useful, although date formats should ideally be presented through an appropriate control and localised where needed.

6.2 Information architecture and visual hierarchy

Information architecture organises content, functions, and navigation. Users should be able to predict where information is located. Related controls should be grouped, headings should describe content, and primary actions should be visually distinguishable without relying only on colour.

Visual hierarchy can be created through position, spacing, size, typography, grouping, and contrast. Excessive variation weakens hierarchy, while insufficient distinction makes controls difficult to scan.

6.3 Tkinter design considerations

Tkinter interfaces are desktop interfaces, but desktop users still need clear layout and accessible interaction. Useful practices include:

• use frames to group related controls;
• use grid for form-like layouts and configure row and column weights for resizing;
• provide keyboard traversal with sensible focus order;
• associate labels with their controls;
• use validation for dates, numbers, and required fields;
• avoid placing too many controls in one window;
• show success and error feedback near the relevant task;
• disable actions that cannot currently be performed, or explain why they are unavailable;
• ensure the window remains usable when resized and at increased font sizes.

A prototype should focus first on task flow and feedback, not on decorative styling.

6.4 Flask design considerations

Flask applications typically separate routes, templates, static resources, validation, and application logic. Requirements should influence this structure. For example, a multi-step process may need clear navigation, preservation of valid input, and server-side validation.

Important web-interface practices include:

• use meaningful headings and landmarks;
• provide labels for form controls;
• return useful validation messages;
• preserve user-entered values after recoverable errors;
• use semantic HTML before adding custom JavaScript;
• design for narrow and wide viewports;
• handle slow connections and server failures visibly;
• protect state-changing requests against common web threats such as cross-site request forgery.

A Flask route should not be considered complete merely because it returns a page. It must also satisfy requirements concerning authorisation, validation, error handling, privacy, and responsive presentation.

7. Accessibility and Inclusive Design

Accessibility means that people with different abilities can perceive, understand, navigate, and operate the application. Inclusive design goes further by recognising variation in language, culture, age, device, connectivity, and technical confidence.

Key practices include:

• do not communicate essential information through colour alone;
• maintain sufficient contrast between text and background;
• provide visible keyboard focus;
• ensure every interactive control has an accessible name;
• use headings in a meaningful hierarchy;
• provide alternatives for non-text content;
• allow text enlargement without loss of essential content;
• avoid time limits unless necessary and provide warnings or extensions;
• make error messages programmatically associated with fields where possible;
• use plain language and avoid unexplained technical terms.

Accessibility should be designed from the beginning, not added after implementation. Automated tools can identify some structural problems, but they cannot determine whether a task is genuinely understandable or whether a screen reader user can complete the whole workflow. Manual review and testing with people with diverse needs remain important.

Accessibility obligations may be affected by national law, institutional policy, procurement rules, and recognised standards such as the Web Content Accessibility Guidelines. The applicable legal and policy context should be confirmed rather than assumed.

8. Responsive Design

Responsive design allows a web interface to adapt to different viewport sizes, input methods, and conditions. It is not simply the act of shrinking a desktop page.

A responsive design should consider:

• content priority at different widths;
• flexible grids and containers;
• readable line lengths and adequate spacing;
• controls large enough for touch interaction;
• navigation that remains discoverable;
• tables that remain usable on narrow screens;
• images and media that scale without distortion;
• slow networks and interrupted connections.

Mobile-first design is a planning strategy in which the essential content and actions are designed for constrained screens first, then enhanced for larger screens. It does not imply that desktop users are less important.

For Tkinter, “responsive” usually refers to resizing behaviour within a desktop window rather than browser breakpoints. Layout managers, minimum sizes, font scaling, and scrollable regions must be considered.

9. Prototyping and Design Communication

A prototype is an intentionally incomplete representation used to explore, communicate, and evaluate a design. Prototypes reduce the cost of discovering misunderstandings before implementation.

9.1 Fidelity levels

• Paper or sketch prototype: fast and inexpensive; useful for early structure and task flow.
• Wireframe: shows layout, navigation, labels, and content priority without detailed visual styling.
• Interactive prototype: allows users to follow a simulated workflow.
• High-fidelity prototype: resembles the intended appearance and interaction, but may still lack production logic.

The appropriate fidelity depends on the question being investigated. A paper prototype is often better than a polished mock-up when the team is still deciding whether a feature is needed. High fidelity can cause stakeholders to focus on colours and wording before the underlying workflow is correct.

A prototype should identify:

• screen or window purpose;
• entry points and navigation;
• primary and secondary actions;
• input requirements;
• validation and error states;
• empty, loading, success, and failure states;
• accessible labels and focus order.

9.2 Design review

A design review should ask:

1. Can the target user identify the next action?
2. Does the interface expose the information needed for a decision?
3. What happens when input is invalid or a service is unavailable?
4. Can the complete task be performed by keyboard?
5. Does the design protect privacy and avoid unnecessary data collection?
6. Does the design work in the expected environments and devices?

Design rationale should be recorded. A short explanation of why a decision was made helps future developers maintain consistency and revisit assumptions when evidence changes.

10. Ethical Design, Privacy, and Trust

Software design affects people, so technical feasibility is not the only criterion for a good decision.

10.1 Privacy and data minimisation

Collect only information necessary for a stated purpose. Explain what is collected, why it is needed, how long it is retained, and who can access it. Sensitive information requires stronger safeguards and may be subject to data-protection law.

A requirements document should identify:

• the purpose of each data item;
• the lawful or organisational basis for processing where applicable;
• retention and deletion expectations;
• access roles;
• logging requirements;
• risks associated with disclosure or misuse.

A password field, for example, should not display the password by default, and passwords must be handled using appropriate secure mechanisms rather than stored as readable text.

10.2 Avoiding manipulative design

Dark patterns are interface choices that steer users toward outcomes they may not freely choose, such as making cancellation difficult, obscuring costs, or preselecting unnecessary data sharing. Ethical design uses clear choices, balanced presentation, and informed consent.

10.3 Fairness and automation

If an application ranks, recommends, approves, or rejects users, the team must consider potential bias, explainability, appeal mechanisms, and the consequences of errors. A simple Flask application may not use machine learning, but ethical issues still arise through access rules, defaults, notifications, and data practices. AI-generated interface text or code should be reviewed for accuracy, accessibility, security, licensing, and unintended bias.

11. Applied Case: Campus Room Reservation System

The following is an illustrative case, not a report of a real institution.

Background

A college currently reserves study rooms through email. Students send requests to administrative staff, who manually check a spreadsheet. Responses may take several hours, and conflicting reservations occasionally occur.

Problem

Students need immediate information about room availability. Administrators need reliable conflict prevention, an audit trail, and the ability to block rooms for maintenance.

Analysis

Interviews identify three principal roles:

• students, who search, create, and cancel their own future reservations;
• administrators, who manage rooms and view all reservations;
• maintenance staff, who report periods during which rooms cannot be booked.

Important constraints include existing institutional login, limited administrative time, and use on both laptops and mobile browsers. Privacy analysis shows that the system needs a user identifier and reservation details, but not a student’s unrelated academic records.

Requirements

Functional requirements include:

• students shall search rooms by date, start time, end time, capacity, and equipment;
• the system shall prevent overlapping reservations for the same room;
• students shall receive confirmation after a successful reservation;
• students shall cancel their own future reservations subject to institutional policy;
• administrators shall block rooms for maintenance;
• administrators shall view an audit history of changes.

Non-functional requirements include:

• the search form shall be usable with keyboard input;
• the web interface shall adapt to narrow screens;
• unauthorised users shall not view another user’s personal reservation details;
• the system shall provide a clear response when the reservation service is temporarily unavailable;
• common searches shall return results within a defined performance target under an agreed test workload.

Approach and solution

The team first creates paper prototypes for search, results, booking confirmation, and cancellation. A usability review finds that users interpret “duration” inconsistently, so the design changes to explicit start and end times. A second review finds that a colour-only availability indicator excludes users who cannot distinguish the colours; the design adds text labels such as “Available” and “Unavailable.”

A Flask implementation can provide server-side validation and database transactions for reservations. The transaction must recheck availability when the booking is submitted, because availability may change between the search and confirmation steps. The user interface should not promise a reservation until the server confirms it.

A possible acceptance test is:

• Given Room A is free from 10:00 to 11:00,
• when an authenticated student submits a valid request for Room A during that interval,
• then exactly one reservation is stored and a confirmation is displayed.

A conflict test is:

• Given Room A already has a reservation overlapping the requested interval,
• when another student submits the request,
• then no second reservation is created and the interface explains that the room is unavailable.

Outcome

The proposed design reduces unnecessary email exchange, makes conflicts visible before submission, and gives administrators a controlled maintenance function. The project remains limited in scope by excluding automatic calendar synchronisation from the first release.

Learning points

The case demonstrates that requirements are more than a feature list. They include roles, rules, exceptions, quality targets, privacy boundaries, and acceptance evidence. Prototyping exposed terminology and accessibility problems before they became code. Finally, the design must handle the difference between information observed during search and the authoritative decision made during booking.

12. Challenges and Limitations

Requirements and UX work involve uncertainty. Different stakeholders may have conflicting goals. Users may describe current workarounds rather than their underlying needs. Observation can influence behaviour, questionnaires can oversimplify problems, and prototypes can create unrealistic expectations.

Requirements also change because of new regulations, technical discoveries, organisational priorities, or user feedback. Change is not automatically failure, but uncontrolled change threatens scope, quality, and schedule. A disciplined process records the change, evaluates its impact, updates affected requirements and tests, and obtains appropriate approval.

Usability testing with a small number of participants can reveal severe problems but does not prove universal usability. Automated accessibility checks are valuable but incomplete. Performance targets depend on workload and infrastructure. Therefore, claims about quality must include the conditions under which they were evaluated.

13. Professional Best Practices

A diploma-level developer should develop the following habits:

1. Begin with user goals and organisational outcomes, not widgets or frameworks.
2. Separate facts, assumptions, preferences, constraints, and risks.
3. Use stable identifiers for requirements and acceptance criteria.
4. Write one clear obligation per requirement where practical.
5. Define exceptional cases and recovery paths.
6. Prototype important workflows before substantial coding.
7. Test accessibility with keyboard operation and varied text sizes.
8. Design for realistic devices, connectivity, and user expertise.
9. Minimise personal data and document access rules.
10. Review requirements with stakeholders and maintain traceability.
11. Treat error handling, empty states, and service failures as part of the product.
12. Use AI-assisted tools cautiously: verify generated code, protect confidential data, and retain human responsibility for decisions.

Chapter Summary

Requirements analysis translates stakeholder needs into precise, verifiable statements. Functional requirements describe what an application does, while non-functional requirements describe qualities and constraints such as usability, performance, accessibility, security, and privacy. Personas, task analysis, user journeys, and user stories help a development team understand user goals and context.

Acceptance criteria, especially in Given–When–Then form, provide observable evidence that a feature is complete. Prioritisation techniques such as MoSCoW help control scope, but accessibility, security, and legal obligations must not be dismissed as optional features. Prototypes allow teams to evaluate structure and interaction before implementation. Tkinter applications require careful window layout, focus order, validation, and resizing; Flask applications require semantic web structure, server-side validation, responsive layouts, authorisation, and secure state changes.

Usability, accessibility, responsive design, privacy, fairness, and avoidance of manipulative patterns are core design responsibilities. A professional developer records assumptions, traces requirements to tests, evaluates limitations, and iterates with evidence. These practices establish a foundation for reliable Python GUI and web applications.

Key Terms

Stakeholder: A person, group, or organisation affected by or interested in an application.

Need: A desired outcome or problem expressed from a user or organisational perspective.

Requirement: A necessary and verifiable statement about a system or its operation.

Constraint: A limitation that restricts possible solutions.

Assumption: A proposition accepted as true for planning purposes but requiring validation.

Functional requirement: A statement describing a service, behaviour, input, output, or rule.

Non-functional requirement: A statement describing a quality, constraint, or operational condition.

Traceability: The ability to connect a requirement to its source, implementation, design, and test.

Persona: A research-informed representation of a significant user group.

User journey: The stages and experiences involved in achieving a user goal.

User story: A concise statement of a capability and its value from a user’s perspective.

Acceptance criterion: A condition that must be satisfied for a feature to be accepted.

Prototype: An incomplete representation used to explore or evaluate a design.

Usability: The extent to which users can achieve goals effectively, efficiently, and satisfactorily.

Accessibility: The ability of people with diverse abilities to perceive, understand, navigate, and operate a system.

Responsive design: Design that adapts content and interaction to different viewport sizes and conditions.

Authentication: Verification of a user’s identity.

Authorisation: Determination of what an authenticated user is permitted to do.

Data minimisation: Collecting and retaining only data necessary for a stated purpose.

Dark pattern: A manipulative design choice that steers users toward unintended or disadvantageous actions.

Review Questions

Short Answer Questions

1. Distinguish a stakeholder need from a software requirement.
2. Give two differences between functional and non-functional requirements.
3. What information should a persona contain?
4. Explain the purpose of acceptance criteria.
5. Why should accessibility be considered during requirements analysis rather than after implementation?

Long Answer Questions

1. Explain a complete process for transforming stakeholder needs into functional requirements and acceptance tests.
2. Compare interviews, observation, questionnaires, workshops, and prototyping as requirements-elicitation techniques.
3. Discuss how usability principles can influence the design of both a Tkinter desktop application and a Flask web application.
4. Explain how privacy, data minimisation, and authorisation should influence the design of a reservation system.
5. Discuss the benefits and limitations of low-fidelity and high-fidelity prototypes.

Analytical / Application Questions

1. A college wants a Flask application for reporting damaged equipment. Identify three stakeholder groups, write four user stories, and provide at least two Given–When–Then acceptance criteria for one story.
2. A Tkinter form contains twelve fields, uses colour alone to show errors, and loses all entered data after validation fails. Analyse the usability and accessibility problems and propose a revised design.
3. A developer proposes collecting a user’s full academic history to improve room recommendations. Evaluate the proposal using requirements, privacy, ethical-design, and scope principles.

Multiple Choice Questions with Answers

Question 1

Which statement is a functional requirement?

A. The interface shall support keyboard operation.

B. The system shall allow students to cancel their own future reservations.

C. Search results shall appear within two seconds for 95% of requests.

D. Passwords shall not be stored as readable text.

Correct Answer: B. The system shall allow students to cancel their own future reservations.

Question 2

Which characteristic makes a requirement objectively testable?

A. It uses persuasive language.

B. It reflects the developer’s preferred implementation.

C. It defines observable conditions or measurable outcomes.

D. It contains several unrelated goals in one sentence.

Correct Answer: C. It defines observable conditions or measurable outcomes.

Question 3

What is the main purpose of a persona?

A. To replace all user research with an imaginary user.

B. To represent a significant user group and focus design on its goals and context.

C. To specify the database tables required by the application.

D. To document the exact Python classes used in implementation.

Correct Answer: B. To represent a significant user group and focus design on its goals and context.

Question 4

In Given–When–Then acceptance criteria, what does the “Then” section describe?

A. The initial context.

B. The user role.

C. The action that triggers the feature.

D. The expected result or system response.

Correct Answer: D. The expected result or system response.

Question 5

Which feature would normally be classified as a Must-have for a room-booking minimum viable product?

A. Colour themes.

B. Calendar synchronisation with every external provider.

C. Conflict prevention when creating a reservation.

D. Animated transitions between pages.

Correct Answer: C. Conflict prevention when creating a reservation.

Question 6

Which design choice best supports accessibility?

A. Using colour alone to identify invalid fields.

B. Providing visible keyboard focus and meaningful labels for controls.

C. Removing headings to create more visual space.

D. Using very small text so more content fits on screen.

Correct Answer: B. Providing visible keyboard focus and meaningful labels for controls.

Question 7

What is the difference between authentication and authorisation?

A. Authentication checks identity; authorisation determines permitted actions.

B. Authentication determines permissions; authorisation checks identity.

C. Authentication applies only to desktop applications; authorisation applies only to websites.

D. They are two names for the same process.

Correct Answer: A. Authentication checks identity; authorisation determines permitted actions.

Question 8

Why should a booking system recheck room availability when a reservation is submitted?

A. The search page cannot display room names.

B. Availability may have changed between the search and submission.

C. It eliminates the need for user authentication.

D. It allows the system to collect more personal data.

Correct Answer: B. Availability may have changed between the search and submission.

Question 9

Which statement best expresses data minimisation?

A. Collect every potentially useful data item in case it becomes valuable later.

B. Collect only data necessary for a clearly stated purpose.

C. Store personal data indefinitely to simplify future development.

D. Allow every staff member to view all collected data.

Correct Answer: B. Collect only data necessary for a clearly stated purpose.

Question 10

Which prototype is generally most appropriate when a team is still deciding the basic task flow?

A. A paper or sketch prototype.

B. A fully deployed production system.

C. A final visual design with complete branding.

D. A performance benchmark of the database.

Correct Answer: A. A paper or sketch prototype.