Understand the need.
Define the software.

Why do requirements matter?

If we do not spend sufficient time and effort identifying and documenting requirements, there is a mismatch between what the user expec…

Who should we ask? Stakeholders and users

When a software system is introduced it influences different types of users — from your own organisation, other organisations or end us…

Requirement analysis: spotting problems

During requirements analysis, we analyse the gathered requirements to form a clear understanding of the exact customer requirements and…

Five ways to gather requirements

Users identified for the Seller Portal: independent sellers, sales team/manager of companies, advertising department, logistics/shippin…

Questionnaires and interviews

A series of questions designed to elicit specific information from users. Answers can be yes/no, a choice from a set of answers, or a l…

Focus groups, observation and existing documents

Drawback of interviews: they offer only one perspective. Alternative: get a group of stakeholders to discuss issues and requirements. A…

Practical guidelines and sample portal features

After requirement gathering, the Seller Portal could contain the following features.

Functional versus non-functional requirements

Captures a functionality required by the users from the system: the user performs actions/gives inputs and the system provides an appro…

Reliability, robustness and other quality requirements

Reliability is the extent to which a program behaves the same way over time in the same operating environment. E.g. the software should…

What is an SRS?

In the Plan and Document perspective, requirement gathering and analysis is usually done by a system analyst, with other members of the…

What kinds of interfaces appear in an SRS?

Broad high-level functions, each with its functional requirements. For the Seller Portal:

Why use an SRS?

Plan and Document versus Agile requirements

The SRS serves as an agreement between customers and developers. But in many projects customers are unsure of the requirements, and the…

Behaviour-Driven Design (BDD)

Behaviour Driven Design (BDD) asks questions about the behaviour of an application before and during development, so that stakeholders…

The user-story template

User stories are short, informal, plain-language descriptions of what a user wants to do within a software product, which is of value t…

Why are user stories useful?

SMART user stories

A good user story should be SMART: Specific, Measurable, Achievable, Relevant and Timeboxed.

SMART: how to improve a story

Vague: “User can search for a product in the catalogue” → specific: “User can search for a product by title in the catalogue”.

User-story limits and choosing an approach

1. Continuous contact with customers may be difficult or too expensive — customers may not want to participate or may not be available…