3

Alistair Cockburn says in Writing Effective Use Cases, that validation requirements should not go into the use cases. However, even after reading the chapter on Missing Requirements (meaning the requirements not covered by Use Cases), I'm not sure where I should put validation and data formats, or how I should structure said document.

Given this brief use case example:

  1. User will enter their Address
  2. System will validate the Address

Obviously we need to specify what "Address means"

Street1, Street2, City, SubCountry, Country, PostalCode. The first 3 fields will be 255 character strings, sub country will be iso 3166-2 validated and stored as just the 2 subcountry characters. country will be iso 3166-1 validated and stored in alpha3 format. iso 3166 codes will be displayed as their long name.

Obviously my text here is a bit meandiering and may miss bits. Where should I document this validation and data format specification? how should I write it so that it's clear? is there any in depth documentation on writing this part of the specification?

Improve this question

1 Answer 1

Reset to default
1

There are lots of ways to structure requirements documents.

In Chapter 1 of Writing Effective Use Cases, Cockburn gives out plausible outline for a requirements document. In this outline, use cases belong in "Chapter 3", while "Chapter 5" captures more information about business rules, performance, operations, security, documentation, maintenance, and so on. Your data dictionary would fit best here, with the other business rules.

But this isn't the only way to structure requirements. In Software Requirements, 3rd Edition by Wiegers and Beatty, there are some example structures for requirements documents along with discussions on different ways to format them. ISO/IEC/IEEE 29148 Systems and software engineering — Life cycle processes — Requirements engineering gives a different outline for a software requirements specification. The arc42 template puts your business rules and data dictionary in Section 8 - Crosscutting Concepts. Your organization may have its own rules, standards, and templates for how to capture requirements that you should consult.

There are also many textual, tabular, and graphical formats to capture data dictionaries. Sometimes, they are not necessarily captured in document format, but as schema definitions or files. Visual Models for Software Requirements goes into several different formats and structures for graphical and tabular data dictionaries and other types of requirements.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.