Software Requirements: Gathering, Analysis & Specification

Requirements Gathering & Analysis

Before writing a single line of code, we must answer one question: what exactly does the customer need? This lecture introduces the two-step process of first gathering requirements from users, then analysing them to remove problems.

1.1 The running example: Amazon Seller Portal

Throughout the week, the professors use one case study — a seller portal (like Amazon's), where sellers list and sell products online. Every concept (users, techniques, requirements, SRS, user stories) is illustrated on this same system, which makes it a very likely source of exam examples.

1.2 The three types of users

Requirements come from users — but "users" is not one homogeneous group. The course divides them into three categories:

1.3 Requirements Analysis — three classic problems

Since requirements are gathered from many stakeholders and many sources, the raw collection is messy. Analysis means forming a clear understanding of the exact customer requirements and weeding out problems. Three problems dominate (and they are exactly what assignment Q1–Q3 test):

Identifying Users & Requirement-Gathering Techniques

We know who the users are. Now: how do we actually collect requirements from them? Do we just tap users on the shoulder and ask? The lecture gives five systematic techniques.

2.1 Technique 1 — Questionnaires

A questionnaire is a series of questions designed to elicit specific information from users. Questions can be yes/no, multiple choice, or longer comments.

• Best for: getting answers to specific questions from a large group of people spread across a wide geographical area.
• Example: send questionnaires to sales-team managers of many mobile companies — "What percentage of your inventory do you sell online?", "What are the main difficulties you face selling online?"
• Caveat: should be used in conjunction with other techniques — it only answers the specific, predefined questions you thought to ask (this exact limitation is assignment Q14).

2.2 Technique 2 — Interviews

An interview is asking someone a set of questions — often face-to-face, but telephonic or online works too.

• Classified as structured, unstructured, or semi-structured, depending on how rigorously the interviewer sticks to a prepared list of questions.
• Best for: exploring issues — questions we don't yet know the answers to.
• Drawback: offers only one perspective at a time — which motivates the next technique.

2.3 Technique 3 — Focus groups (and workshops)

Instead of one person, get a group of stakeholders together to discuss issues and requirements.

• Best for: collecting multiple viewpoints.
• Helps gain consensus — if several stakeholder groups raise the same issue, it's clearly a key requirement.
• Also useful for highlighting areas of conflict or disagreement — giving a nuanced picture of different stakeholders' needs. (This dual purpose — consensus + conflict — is exactly assignment Q4.)

2.4 Technique 4 — Naturalistic observations

Go and watch users doing their actual work in their actual environment.

• Best for: understanding the context in which users perform a task.
• Example from the slides: observe how people sell in physical shops — shopkeeper/customer recommendations, customer feedback — which yields requirements like "recommendations for what other items to sell" and "getting timely customer feedback".
• Assignment Q5 uses this: a team visits medical shops to observe the process of selling medicines → naturalistic observation.

2.5 Technique 5 — Studying documentation

Many tasks are governed by manuals, written procedures, standards and regulations.

• Best for: procedures, regulations, standards.
• Example: bank regulations for the seller portal — how to add sellers' bank accounts, how frequently money can be deposited, what practices other online marketplaces follow.

2.6 Summary table (memorise this)

2.7 Basic requirement-gathering guidelines

1. Focus on identifying stakeholders' needs.
2. Involve all stakeholder groups — primary, secondary and tertiary — because each type has different needs.
3. Use a combination of techniques — different techniques serve different purposes.
4. Run a pilot session if possible — especially for questionnaires (a missing question or wrong options is hard to fix after users have already responded).
5. Be pragmatic — data gathering is expensive and time-consuming; compromises are often necessary.

Functional vs Non-Functional Requirements

Not all requirements have the same character. Compare: "A seller can add or delete items from their catalogue" versus "When a new product is added, it must show up within 5 seconds." They are fundamentally different kinds of requirements.

3.1 Functional requirements — what the system does

Example: "A seller can add/edit/delete their catalogue" — the add/edit/delete actions are inputs; the updated catalogue is the output.

3.2 Non-functional requirements — how the system behaves

Example: "The product update should appear in the catalogue within 5 seconds" — no new functionality, just a constraint on behaviour.

3.3 The main categories of NFRs covered

The SRS Document — organising requirements (Plan & Document)

We've gathered and categorised requirements. Now: how do we organise them? In the Plan-and-Document process model, the answer is the Software Requirements Specification (SRS).

4.1 Context and who writes it

• In the Plan-and-Document model, significant time goes into planning and documenting the whole process.
• Requirements gathering and analysis is usually done by a system analyst, in consultation with the software team.
• After gathering everything, the analyst organises the user requirements in a structured form — that document is the SRS.

4.2 Standard structure of an SRS

4.3 Advantages of maintaining an SRS

1. Forms an agreement between customers and developers. The SRS goes to customers, is iterated on, and finally accepted — setting both sides' expectations.
2. Reduces future rework. It forces stakeholders to rigorously think through all requirements before design and development, reducing later changes.
3. Provides a basis for estimating costs and schedules. The SRS lets you estimate software size (a function of all requirements) → effort → cost → schedule.
4. Facilitates future extensions. Serves as the basis for planning future enhancements.

4.4 The drawback — and the bridge to Agile

Behaviour-Driven Design & User Stories (Agile)

When requirements keep evolving, the Agile process — working closely with stakeholders, building a prototype, refining it in sprints of ~1–2 weeks — replaces the SRS with something lighter: user stories.

5.1 What is BDD?

5.2 What is a user story?

5.3 The Role–Feature–Benefit template

Every user story follows one pattern:

The two worked examples from the lecture:

5.4 SMART — the checklist for good user stories

5.5 Benefits of user stories

1. Lightweight version of requirements — versus heavyweight SRS documentation.
2. Help stakeholders plan and prioritise development — e.g. the client wants catalogue & inventory first, so the team commits to "view inventory in 2 weeks".
3. Behaviour over implementation — because stories say nothing about how features are implemented, misunderstanding between stakeholders is reduced.
4. Facilitate conversations between users and the dev team — e.g. seeing the feedback story, a client realises they'd also like email notification for products rated 1–2 stars. Such modifications are natural in Agile.

5.6 Drawbacks of user stories

• Continuous contact with users may not be possible — customers may be unavailable or unwilling to participate throughout development, and it may be too expensive.
• Doesn't scale to very large projects or safety-critical applications — those need extensive planning and documentation upfront, with no room for error or refinement.

All 14 Questions — with answers and the "why"

Every question below maps directly to a concept above. The correct option is highlighted, followed by the reasoning you should be able to reproduce in an exam.

One-page cheat-sheet