Requirements and Specifications

Focus on the Product, Not the Code: How I Build Software for Clients

How to write requirements

1. As Agile Terms:

As a <role or persona>, I want <goal/need> so that <why>

Example:

As an architect

I want to have up-to-date information about Gitlab issues

So that I can overview and track the issues' progress

2. As gherkin language. Behaviour driven development (Cucumber)

Common paterns

Requirements mus tbe correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, and traceable.

Use consistent language. Define specific terms. Build a glossary. Consider the fact that the same term might be understood differently in different situations and contexts. Use the same words for the same entities.

Don't mix your goals with user's goals. Our goals is to please them making their needs value more than ours. How do we know what user wants? We don't. We need to consult real users or make a hypothesis.

Remove technical details. There is a clear separation between user's goal and technical ways to achieve them. Leave only important information, implementation details must be stripped away.

Clarify roles. These roles can form depending on the way or goal of why our product is used. These roles must be defined as terms.

Ranks requirements with MoSCoW method.

Link everything together. Without proper care, you will soon end with a mess of user stories, tests, source code, and documentation.