Requirements, Constraints, and Acceptance Criteria

Learning Objectives

• Separate functional requirements from non-functional requirements.
• Write user stories and acceptance criteria.
• Identify assumptions, constraints, and risks before designing.
• Turn vague feature requests into design-ready requirements.

Lecture Notes

Many bad software designs begin with a vague request. “Build a student planner” sounds clear until you ask what the planner must actually do. Does it support multiple schools? Does it need reminders? Can tasks repeat? Is data stored locally or online? Can students share tasks with a group? Each answer changes the design. Requirements are the bridge between an idea and an implementable system.

A functional requirement describes behavior: the system shall let students create assignments, edit due dates, mark tasks complete, and filter tasks by course. A non-functional requirement describes quality: the system should load in under two seconds, work offline, protect private data, or be easy to maintain. Both matter. Students often focus only on features, but non-functional requirements heavily influence architecture and design.

A useful format is the user story: As a type of user, I want some capability so that I get some benefit. User stories are not enough by themselves, because they can still be interpreted in many ways. Acceptance criteria make them testable. For example: “Given a task due tomorrow, when the student opens the dashboard, then the task appears in the Upcoming section.” This level of detail helps developers know when the feature is complete.

Constraints are limits the design must obey. A class project might require Java, a local file instead of a database, or no external libraries. A real business might require HIPAA compliance, integration with an old payment provider, or support for low-bandwidth users. Ignoring constraints leads to designs that look good on paper but cannot be delivered.

Assumptions are things you believe but have not proven. Good designers write assumptions down. “Assume one student account per device” or “Assume courses do not overlap names” are dangerous if false. By documenting assumptions, you make design risk visible. When an assumption changes, you can see which part of the design may need revision.

Worked Example: Turning a vague request into requirements

Build a food ordering app.

Functional requirements:
1. Customers can browse menu items by category.
2. Customers can add items to a cart.
3. Customers can change quantity before checkout.
4. Customers can choose pickup or delivery.
5. Staff can update order status.

Non-functional requirements:
1. Menu pages should load in under 2 seconds on a normal connection.
2. The system should keep payment details out of application logs.
3. The cart should remain available after a page refresh.

Acceptance criterion:
Given a cart with two items, when the customer removes one item, then the cart total updates immediately and the removed item no longer appears.

Lab: Requirement Recovery

Scenario: A client says: “I need an app for managing campus events.”

Steps

1. List stakeholders: students, organizers, admins, visitors.
2. Write at least 12 functional requirements.
3. Write at least 6 non-functional requirements.
4. Write 5 user stories with acceptance criteria.
5. Identify 5 assumptions and 5 constraints.

Deliverables

• Requirements document
• Acceptance criteria table
• Assumptions and constraints section

Assignment

Create a requirements document for a library system, inventory system, or student planner. Include at least 15 requirements and 8 acceptance criteria.

Discussion Prompts

• What happens when teams skip requirements?
• Can too many requirements hurt a project?
• Which non-functional requirements are easiest to forget?

Week 2 Quiz

Use these as quick checks after the lesson.

Student Notes

Saved in this browser only.