WDD1 - Analysis: end-user and functional requirements
- I can identify end-user requirements for a website problem.
- I can identify functional requirements for a website problem.
- I can turn client comments into clear, specific requirement statements.
- I can explain the difference between an end-user requirement and a functional requirement.
- I can decide whether a requirement is about a user's task or the website's behaviour.
- I can write requirements that use exact detail from the scenario rather than vague wording.
Answer these before the lesson begins. The aim is to wake up the requirements vocabulary.
Key vocabulary
Analysing a website problem
Why analysis comes first
In Web Design & Development, analysis is where the developer works out what the website is for and what people need from it. A website can be technically correct but still fail if it does not help the right people do the right tasks. Before any page structure, wireframe, HTML, CSS or JavaScript is created, the requirements need to be clear.
End-user requirements - what people need to do
An end-user requirement describes a task from the point of view of the person using the website. It should name the user and the task, not the implementation. A useful frame is:
"The user must be able to [find / view / choose / enter / submit] specific information or content."
Functional requirements - what the website must do
A functional requirement describes the behaviour the website must provide. It still does not say exactly how the site will be built, but it points toward the pages, forms, navigation and interactivity that will be designed later. A useful frame is:
"The website must [display / collect / validate / submit / show / hide] specific information or content."
Ask: what does the person need to achieve?
- Visitors need to find opening times.
- Parents need to submit an enquiry.
- Staff need to update event information.
Ask: what behaviour must the website provide?
- The website must display opening times.
- The website must collect enquiry details using a form.
- The website must provide a page for upcoming events.
Lesson scenario - Meadows Wildlife Centre
For this lesson, imagine a small local wildlife centre needs a new website. The centre runs public visits, school workshops, volunteer days and animal care fundraising. The client conversation below contains the raw material for both kinds of requirement.
Worked examples
Client comment: "Families need to see our opening times, prices and location before they visit."
Client comment: "Teachers should be able to send us a workshop enquiry with their school name, class size and preferred date."
Client comment: "People often ask what volunteer roles are available and how to apply."
The end-user requirement focuses on the visitor's goal. The functional requirement focuses on the behaviour the site must provide.
The centre manager says: "We want to promote three current fundraising campaigns on the home page."
Write both: an end-user requirement and a functional requirement.
End-user requirement: "Visitors must be able to see the centre's current fundraising campaigns from the home page."
Functional requirement: "The website must display three current fundraising campaigns on the home page."
- Writing design decisions too early. "Use a blue navigation bar" is not an analysis requirement unless the client specifically requires it.
- Being too vague. "The website must have information" does not say what information or who needs it.
- Mixing the two viewpoints. "The website must be able to find prices" gives the website a user's task. Say either "Visitors must be able to find prices" or "The website must display prices."
- Using optional language. Requirements should use "must", not "could", "might" or "would be nice".
For an "identify" question, write a clear requirement in one sentence. Use words from the scenario. A specific answer such as "The website must display accessibility information for visitors" is much stronger than "The website must have useful information."
Task Set A - Core questions
Task Set B - Extension
File this in OneNote under:
Higher Computing Science > Web Design & Development > WDD1
Suggested timing: 7 min warm up, 12 min notes and scenario, 15 min worked examples plus now-you-try, 20 min Task Set A, 5 min review or Task Set B.
Scope control: do not drift into site structures, wireframes, forms or HTML tags. Those start in WDD2-WDD5. Keep this as a requirements extraction lesson.
Key misconception: pupils often write implementation details as requirements. Keep asking: is this what the user needs, what the website does, or how the developer might build it?
Assessment link: supports the WDD analysis bullet: identifying end-user and functional requirements.