Requirements, UX and Application Planning

Introduction

A full-stack application succeeds when it solves a real problem for identifiable users, not merely when it contains modern frameworks or attractive screens. Application development therefore begins before database schemas, APIs, and interface code. It begins with understanding stakeholder needs, expressing those needs precisely, exploring how people will use the system, and deciding what can reasonably be delivered first.

Requirements, user experience (UX), and planning are closely connected. Requirements describe the value and capabilities expected from a system. UX design investigates how users will achieve their goals. Planning determines the scope, order, resources, risks, and technology required to create a usable product. Weakness in any one of these areas creates predictable problems: unclear features, unnecessary development, user frustration, scope growth, and expensive rework.

This chapter presents a practical foundation for translating stakeholder needs into user stories, acceptance criteria, workflows, wireframes, and a minimum viable product (MVP). It also introduces lightweight scope estimation and technology-stack selection appropriate for certificate-level full-stack development.

Learning Objectives

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

• identify stakeholders and distinguish business, user, functional, and non-functional requirements;
• convert needs into well-formed user stories and testable acceptance criteria;
• model user workflows and identify normal, alternative, and error paths;
• create low-fidelity wireframes that communicate structure and interaction;
• define and prioritize an MVP;
• estimate development scope using relative sizing and capacity;
• select a technology stack using explicit project criteria;
• recognize ethical, accessibility, privacy, and governance responsibilities in planning.

1. From Stakeholder Need to Product Requirement

A stakeholder is a person or organization affected by the product or able to influence its success. Stakeholders may include customers, end users, business owners, administrators, support staff, regulators, developers, and integration partners. A stakeholder request is not automatically a complete requirement. For example, “We need a dashboard” describes a proposed solution but does not explain who needs it, what decision it supports, what data it requires, or how success will be judged.

A useful discovery process separates four questions:

1. Who experiences the problem or benefits from the solution?
2. What task or outcome is required?
3. Why does the outcome matter?
4. Under what constraints must the system operate?

The “why” is particularly important. If a manager asks for a dashboard, the underlying goal may be to identify overdue work quickly. A dashboard is one possible solution; a filtered task list, alert system, or scheduled report might solve the same problem more effectively.

Types of requirements

Requirements should be understandable, necessary, feasible, verifiable, and traceable to a stakeholder or outcome. A requirement that cannot be tested is likely too vague. “The application should be fast” is weaker than “The appointment search results should appear within three seconds for 95% of requests under the agreed test load.” The latter includes a measurable condition, although the performance target must still be agreed and tested.

Discovery techniques

Common discovery techniques include interviews, observation, workshops, surveys, document analysis, support-ticket review, and prototype evaluation. Interviews reveal motivations and exceptions. Observation reveals workarounds that users may forget to mention. Workshops expose disagreement between departments. Existing forms and spreadsheets often reveal important data fields and business rules.

The analyst should record assumptions separately from confirmed requirements. An assumption is a belief used for planning that still requires validation, such as “most users will access the service on a mobile phone.” Unchecked assumptions are a major source of project risk.

2. User Stories and Acceptance Criteria

A user story is a concise description of a capability from the perspective of a user role. A common form is:

As a [role], I want [capability], so that [value or outcome].

For example:

As a registered patient, I want to view my upcoming appointments, so that I can confirm the date and time before travelling.

The story is not a complete specification. It is a conversation starter that identifies the user, need, and value. A well-formed story is often assessed using the INVEST qualities: independent where practical, negotiable, valuable, estimable, small enough to implement, and testable. These qualities are guidelines rather than rigid rules.

Stories should describe outcomes rather than implementation. “As an administrator, I want a PostgreSQL table called appointments” is a technical task, not a user story. The underlying user need may be “As an administrator, I want to manage appointment availability so that patients can book valid time slots.”

Acceptance criteria

Acceptance criteria define the conditions under which a story is considered complete. They make expectations visible to stakeholders, developers, and testers. Criteria should cover the successful path and relevant alternatives or failures.

A useful format is Given–When–Then:

• Given a known starting context;
• When the user performs an action;
• Then an observable result occurs.

Example:

• Given a patient is signed in and has an upcoming appointment,
• When the patient opens “My appointments,”
• Then the system displays the appointment date, time, location, and clinician.

Additional criteria might state that cancelled appointments are clearly labelled, unauthorized users cannot view the record, and an empty state explains what to do when no appointments exist.

Acceptance criteria should be observable, unambiguous, and independently testable. Avoid words such as “user-friendly,” “appropriate,” or “quick” unless they are defined. Criteria also provide a bridge between product planning and automated tests, but they are not a substitute for exploratory testing or usability evaluation.

From epic to implementable stories

An epic is a large outcome that must be divided. For an online library, “Manage borrowing” may be divided into stories for searching books, viewing availability, placing a hold, cancelling a hold, and receiving a notification. Splitting by user outcome is preferable to splitting only by technical layer. A story should ideally deliver a thin, demonstrable slice through interface, server logic, and data storage.

3. Workflows and Interaction Design

A workflow represents the sequence of activities and decisions needed to accomplish a goal. It helps the team understand what happens before, during, and after a user action. Workflows should include:

• entry conditions and the user’s starting point;
• normal steps;
• decisions and branching conditions;
• validation and error handling;
• completion state;
• cancellation, retry, and recovery paths;
• system actions such as notifications or audit logging.

For example, an appointment-booking workflow may be:

1. The user searches by location and date.
2. The system displays available slots.
3. The user selects a slot.
4. The system temporarily validates availability.
5. The user confirms personal details.
6. The system reserves the slot transactionally.
7. A confirmation is displayed and sent by email.

The workflow must also answer what happens if two users select the same slot, required details are missing, payment fails, or the user loses network connectivity. These are not merely technical details; they affect the user’s trust and ability to recover.

A simple flowchart can be drawn using standard notation, but clarity is more important than formal symbolism. Rectangles commonly represent activities, diamonds decisions, and arrows sequence. For complex processes, separate the user’s actions from system responses using swimlanes. This reveals responsibilities and integration points.

Information architecture

Information architecture organizes content, features, and navigation. Designers should group items according to users’ mental models rather than the internal organization of the development team. Labels should be familiar and consistent. Navigation should answer three questions: Where am I? What can I do here? How do I return or proceed?

4. Wireframes and Prototyping

A wireframe is a visual representation of page structure and interaction. A low-fidelity wireframe may use boxes, labels, and placeholders rather than colors and polished graphics. Its purpose is to test hierarchy, content, navigation, and task flow cheaply before implementation.

A useful wireframe identifies:

• page or screen purpose;
• primary action and secondary actions;
• input fields and required information;
• system feedback, validation, and empty states;
• navigation and orientation;
• responsive behavior at different screen widths;
• accessibility considerations such as labels, focus order, and error messages.

Wireframes should be evaluated with representative tasks, not only visual preference. Ask a user to find an available appointment, correct an invalid form, or cancel a booking. Observe hesitation and errors. A prototype is a hypothesis about interaction, not proof that the final application will be usable.

Usability and accessibility foundations

Good UX reduces unnecessary cognitive load and supports error recovery. Controls should have clear labels, related fields should be grouped, and destructive actions should require appropriate confirmation. Feedback should be timely and specific: “Password must contain at least 12 characters” is more useful than “Invalid input.”

Accessibility is a quality requirement, not an optional enhancement. Planning should consider keyboard operation, visible focus, sufficient contrast, meaningful headings, alternative text where needed, accessible form labels, captions for important media, and compatibility with assistive technologies. Teams should consult applicable standards such as the Web Content Accessibility Guidelines (WCAG) and test with both automated tools and human users.

5. Defining the Minimum Viable Product

An MVP is the smallest product that can deliver a meaningful outcome to an initial target group and generate evidence for further decisions. It is not simply the smallest number of features, nor does it justify poor security, inaccessible design, or unreliable data. “Viable” means that the product can be used responsibly for its intended purpose.

A practical MVP process is:

1. define the target user and problem;
2. state the measurable outcome or learning goal;
3. map the essential journey from entry to successful outcome;
4. identify capabilities required for that journey;
5. separate essential capabilities from enhancements;
6. identify risks, legal obligations, and quality thresholds;
7. test the concept with users or stakeholders;
8. release, measure, and revise.

A prioritization matrix can classify features by value and urgency. The MoSCoW categories are Must have, Should have, Could have, and Won’t have for this release. “Won’t have” is a commitment about current scope, not a permanent rejection.

Another useful approach is to score features against agreed criteria. For example, a team may rate user value, risk reduction, and implementation effort on a small scale. The numbers do not create objective truth; they make assumptions discussable. A high-value feature that is legally required may be a Must even if it is technically difficult.

The MVP boundary should include non-functional essentials. Authentication, authorization, backup, privacy controls, error handling, monitoring, and accessibility may be invisible features, but omitting them can make the product unsafe or unusable.

6. Estimating Scope and Capacity

Early estimates are uncertain because requirements, technical difficulty, and dependencies are not fully known. They should be expressed as ranges or relative sizes rather than false precision.

Relative estimation

Story points are a relative measure of effort and complexity. Teams compare a new story with reference stories rather than assigning hours directly. A point value may reflect complexity, uncertainty, and testing effort. Story points are meaningful only within the team that defines them; they are not universal units of productivity.

If a team has completed 24, 28, and 26 points in the last three comparable iterations, its average historical velocity is:

This average is useful only when iteration length, team composition, definition of done, and work type are reasonably comparable. It should not be used to compare individuals or pressure a team to increase a number.

If the remaining backlog is 78 points and the planning velocity is approximately 26 points per iteration, a simple forecast is:

The forecast assumes stable capacity and comparable work. A prudent plan adds contingency for uncertainty, dependencies, defects, leave, and discovery. It is better to communicate “approximately three iterations, with risk around integration and accessibility testing” than to promise an exact date without evidence.

Three-point thinking

When uncertainty is substantial, teams can discuss optimistic, most likely, and pessimistic duration estimates. A commonly used weighted estimate is:

This is a planning heuristic, not a guarantee. Its use assumes that the three estimates describe the same work, use consistent units, and are made with reasonable independence. It should not conceal major unknowns; unknown work should instead become a research task or spike.

Definition of Done

A Definition of Done is a shared quality agreement. It may require reviewed code, passing automated tests, completed acceptance criteria, security checks, responsive behavior, accessibility checks, documentation, and deployment to a test environment. Without such a definition, “finished” may mean merely “the developer stopped coding.”

7. Selecting an Appropriate Technology Stack

A technology stack is the set of technologies used to build, run, and maintain an application. It commonly includes:

• Frontend: browser technologies and a UI framework;
• Backend: server runtime, web framework, and API style;
• Data layer: relational or non-relational database and data-access tools;
• Infrastructure: hosting, networking, storage, deployment, and monitoring;
• Development tools: version control, testing, automated integration, and documentation.

Technology selection should follow requirements rather than fashion. Important criteria include:

A small CRUD-oriented business application may be well served by a relational database, a mainstream backend framework, and a component-based frontend. A real-time collaboration product may require different communication and data strategies. The correct choice depends on workload, constraints, team skills, and risk.

Prefer boring, well-supported technology when it satisfies the need. Adding a framework, microservice, or cloud service introduces operational and learning costs. A monolithic application can be an appropriate starting architecture because it is easier to test and deploy. Services can be separated later when justified by scaling, ownership, or isolation needs.

Architecture decisions should be recorded in short decision records stating the context, options considered, decision, consequences, and revisit conditions. This prevents accidental dependence on undocumented choices.

8. A Complete Applied Scenario

The following is a fictional illustrative case.

Background

A community learning centre currently registers courses by telephone and spreadsheet. Staff spend considerable time answering questions about places and schedules. Learners often miss registration deadlines.

Problem analysis

Interviews identify three primary groups: learners, centre staff, and instructors. Learners need to find courses and reserve a place. Staff need accurate enrolment information and the ability to close registration. Instructors need a reliable participant list. Privacy is important because learner contact details are collected.

The initial business outcome is to reduce telephone registration work while preserving accurate enrolment records. The team identifies an assumption: most learners can complete registration using a mobile browser. A prototype must validate this assumption.

Initial stories and criteria

Story 1: As a learner, I want to browse upcoming courses so that I can choose one that suits my interests and schedule.

Acceptance criteria include:

• the learner can filter by subject and date;
• each course displays title, schedule, location, and available places;
• a course with no available places is clearly marked;
• the empty result state explains how to change the search.

Story 2: As a learner, I want to reserve an available place so that I can attend the course.

Acceptance criteria include:

• required contact details are validated before submission;
• the system prevents reservation when no place remains;
• successful registration produces a confirmation reference;
• the learner receives a clear confirmation message;
• staff can see the new enrolment.

Story 3: As staff, I want to create and close course listings so that published information remains accurate.

Authorization criteria specify that only staff accounts can create or close listings, and that a closed course cannot receive new reservations.

MVP decision

The MVP includes course browsing, availability, learner reservation, confirmation, staff course management, authentication for staff, basic authorization, audit information, responsive design, and privacy-conscious data storage. It excludes payment, learner reviews, recommendation algorithms, native mobile applications, and automated marketing campaigns. These may be evaluated after evidence is collected.

Workflow risk

A race condition exists if two learners attempt to reserve the final place simultaneously. The backend must validate and commit the reservation as one controlled operation, rather than trusting the availability displayed earlier in the browser. The interface should explain failure clearly and invite the learner to select another course.

Technology decision

The team selects a conventional web stack already supported by the organization: a component-based frontend, a mainstream server framework, a relational database, version control, automated tests, and managed deployment. The decision is based on team familiarity, transactional enrolment data, maintainability, and the need for a quick pilot—not on a claim that the stack is universally best.

Outcome and learning points

The prototype reveals that learners need schedule filters and that staff require bulk export for instructors. The team adds the filter to the MVP and records export as a high-priority follow-up. This demonstrates why requirements, workflows, and prototypes must be validated together. The most valuable discovery was not a visual preference; it was a change to the essential user journey.

9. Governance, Ethics, and Contemporary Practice

Planning decisions can affect privacy, fairness, access, and safety. Teams should collect only data needed for a legitimate purpose, explain how it will be used, restrict access, protect it in transit and storage, and define retention and deletion processes. Applicable data-protection law and organizational policy must be identified early rather than after implementation.

Authorization must be distinct from authentication. Knowing who a user is does not determine what that user may do. Every sensitive server operation must enforce authorization; hiding a button in the interface is insufficient.

Analytics and experimentation should avoid dark patterns—interfaces that manipulate users into choices they did not intend. Consent, transparency, and the ability to withdraw where applicable should be planned. AI tools can assist with brainstorming, test-data generation, documentation drafts, or code suggestions, but generated material requires human review. Teams must not expose confidential stakeholder data or personal information to an unapproved AI service. AI-generated requirements may also reproduce ambiguity or bias and therefore cannot replace stakeholder validation.

Contemporary development increasingly uses design systems, automated accessibility checks, continuous integration, cloud deployment, observability, and privacy-by-design practices. These tools are valuable when connected to explicit quality goals. Automation does not remove the need for user research, judgment, or accountability.

Challenges and Limitations

Requirements are often incomplete, contradictory, or politically influenced. Different stakeholders may optimize for different outcomes. User stories can become vague if teams treat them as tickets rather than conversations. Wireframes can create false confidence when tested only with colleagues. Estimates become misleading when teams count points as individual performance. Technology choices can be distorted by vendor marketing or personal preference.

The response is not to produce more documentation indiscriminately. It is to create the minimum shared evidence needed for a decision: validated assumptions, clear stories, testable criteria, visible workflows, an understandable prototype, and an explicit MVP boundary. Uncertainty should be recorded and reduced through research, prototyping, or incremental delivery.

Best-Practice Checklist

Before implementation begins, the team should be able to answer the following:

• Who are the primary users and stakeholders?
• What problem and measurable outcome justify the product?
• Which assumptions remain unvalidated?
• Does each MVP story express user value?
• Are acceptance criteria observable and testable?
• Have normal, alternative, and failure workflows been considered?
• Does the wireframe include empty, loading, validation, and error states?
• Are accessibility, privacy, security, and authorization included in scope?
• Is the estimate based on comparable evidence and stated assumptions?
• Is the technology stack appropriate for the requirements and team?
• What evidence will determine the next product decision?

Chapter Summary

Requirements work translates stakeholder concerns into outcomes and capabilities. Effective analysis distinguishes business, user, functional, non-functional, regulatory, and technical requirements. User stories express a capability from a user perspective, while acceptance criteria make completion observable and testable. Workflows expose normal, alternative, and failure paths, and wireframes allow teams to test information structure and interaction before expensive implementation.

An MVP is a responsible, usable first product that delivers a meaningful outcome and creates learning. Prioritization must include quality, security, privacy, and accessibility—not only visible features. Scope estimates are uncertain planning aids; relative sizing, historical velocity, and three-point discussion are useful only when their assumptions are explicit. Finally, a technology stack should be selected according to product constraints, team capability, maintainability, security, cost, and integration needs. Good planning is iterative: evidence from users and delivery continually refines requirements and scope.

Key Terms

Stakeholder: A person or organization affected by or able to influence a product.

Requirement: A needed capability, quality, constraint, or obligation of a system.

User story: A concise user-centred statement of a desired capability and its value.

Acceptance criterion: A testable condition used to determine whether a story is complete.

Epic: A large outcome or body of work that must be divided into smaller stories.

Workflow: A sequence of activities, decisions, and responses used to achieve a goal.

Information architecture: The organization and labelling of content, functions, and navigation.

Wireframe: A structural representation of a screen or interface.

Prototype: An experimental representation used to investigate a product idea or interaction.

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

Accessibility: Designing so people with diverse abilities can use the product.

MVP: The smallest responsible product that delivers value and supports learning.

MoSCoW: A prioritization scheme using Must, Should, Could, and Won’t categories.

Story point: A team-specific relative measure of effort, complexity, and uncertainty.

Velocity: The amount of relative work a team completes in a comparable iteration.

Definition of Done: Shared criteria describing the quality required for completed work.

Technology stack: The collection of frontend, backend, data, infrastructure, and development technologies.

Authentication: Verification of a user’s identity.

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

Assumption: An unverified belief used to guide design or planning.

Review Questions

Short Answer Questions

1. What is the difference between a functional requirement and a non-functional requirement?
2. Write a user story for a learner registering for a course.
3. What purpose do acceptance criteria serve?
4. Why should an MVP include security and accessibility considerations?
5. Distinguish authentication from authorization.

Long Answer Questions

1. Explain how interviews, observation, and workshops can reveal different types of requirements.
2. Describe the process of converting an epic into implementable user stories.
3. Explain how workflows and wireframes complement one another during UX planning.
4. Discuss the criteria that should guide technology-stack selection for a small full-stack application.
5. Explain the limitations of story points and velocity as estimation tools.

Analytical / Application Questions

1. A team proposes a course-booking MVP containing recommendations, reviews, payments, browsing, reservations, and staff management. Use MVP and MoSCoW reasoning to recommend an initial scope and justify exclusions.
2. Design three user stories and acceptance criteria for a library hold system, including at least one error or alternative path.
3. A team’s last three comparable iterations delivered 18, 22, and 20 story points. The remaining backlog is 60 points. Estimate the average velocity and likely number of iterations, then identify at least three assumptions or risks that could make the forecast unreliable.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a user story?

A. A database table specification written for developers

B. A user-centred description of a capability and its value

C. A complete project schedule with assigned hours

D. A visual style guide for interface colours

Correct Answer: B. A user-centred description of a capability and its value

Question 2

Which item is an acceptance criterion?

A. The system should be modern

B. The developer will use a framework

C. Given an available course, when a learner reserves it, then a confirmation reference is displayed

D. The product team prefers a blue interface

Correct Answer: C. Given an available course, when a learner reserves it, then a confirmation reference is displayed

Question 3

What is the primary purpose of a workflow model?

A. To define programming-language syntax

B. To show activities, decisions, responses, and error paths for a user goal

C. To calculate database storage requirements

D. To replace all usability testing

Correct Answer: B. To show activities, decisions, responses, and error paths for a user goal

Question 4

Which feature is most appropriate for a responsible MVP?

A. A decorative animation with no user benefit

B. An essential authorization check for staff-only actions

C. A future recommendation algorithm unrelated to the core problem

D. A second mobile application before the web journey is validated

Correct Answer: B. An essential authorization check for staff-only actions

Question 5

A team completed 24, 28, and 26 comparable story points in three iterations. What is its average velocity?

A. 24 points

B. 25 points

C. 26 points

D. 28 points

Correct Answer: C. 26 points

Question 6

If a comparable backlog contains 78 points and planned velocity is 26 points per iteration, what is the simple forecast before contingency?

A. 2 iterations

B. 3 iterations

C. 4 iterations

D. 26 iterations

Correct Answer: B. 3 iterations

Question 7

Which consideration most directly supports selecting a relational database for course enrolments?

A. It guarantees that no usability testing is needed

B. It is appropriate for structured data and transactional consistency

C. It automatically designs the user interface

D. It eliminates the need for authorization

Correct Answer: B. It is appropriate for structured data and transactional consistency

Question 8

Why is hiding an administrative button in the frontend insufficient security?

A. Users cannot read button labels

B. Frontend code can be bypassed, so the server must enforce authorization

C. Buttons cannot be tested automatically

D. Administrative actions never require authentication

Correct Answer: B. Frontend code can be bypassed, so the server must enforce authorization

Question 9

Which statement about story points is correct?

A. They are universal units that allow direct comparison of developers

B. They always equal a fixed number of hours

C. They are relative measures meaningful within a team and comparable context

D. They measure user satisfaction directly

Correct Answer: C. They are relative measures meaningful within a team and comparable context

Question 10

What is the best response to an important unvalidated assumption?

A. Hide it from the project plan

B. Treat it as a guaranteed fact

C. Create research, prototyping, or testing to reduce the uncertainty

D. Increase the number of interface features

Correct Answer: C. Create research, prototyping, or testing to reduce the uncertainty