Shared Vision Of The System
There are hundreds of Requirements in mid-size and small software products. All Requirements are defined in a textual format based on the terms from the Glossary. A Glossary is used in order to avoid misinterpretation of key terms and definitions inside the Specification.
Key terms, data units, and concepts are taken from Requirements and entered in the Glossary. This is a proven method to avoid ambiguity.
Consider the following example of two simple functional requirements:
| # | Requirement |
|---|---|
| R1 | User can send a [Request] for new account registration, System shall validate provided information and create a new [Account] for the user. |
| R2 | User can send a [Request] for [Password] change in their [Account], System shall change database records for the user. |
The following is an example of the Glossary terms for the Requirements shown above:
| Term | Definition | Used in |
|---|---|---|
| [Request] | Web form completion and submission operation performed by the user. Process is completed when the 'Submit' button is clicked. | R1, R2 |
| [Password] | 6-20 characters connected with the user account. It must contain at least one numeric symbol and one capital letter. | R2 |
| [Account] | Database record associated with the user, includes: Login, Password, Name, Phone, and Email. | R1, R2 |
As evidenced by the example, the Glossary helps to define shared concepts of the system scope and work with it independently of the Requirements.
A Glossary is created for all projects, regardless of the project size. The Glossary is a section of the SRS.
