@yegor256 on a previous question I asked in regards to Requs (issue #103) you provided a link to one of your other projects that used this SRS syntax to establish the application. You also mentioned that you only used Requs in bigger projects. I noticed that this project was broken down into multiple files.
However when reading the req files in the project I thought it might be easier to have a more structured approach to the process.
Also based on one of your posts about the worst SRSs (http://www.yegor256.com/2015/03/16/technical-glossaries.html) you mentioned the need for glossaries in SRS in order to make it complete. In the example you provided (thinkdeck) you only provide a self contained glossary of User Case specific definitions, but no general one (this may not have been a necessity for that specific project).
In the case of a larger project, there will inevitably be a multi-file SRS for simplicity of reading as the project grows.
File Structure
Having a standardized file structure for such cases would most likely help with the SRS as follows:
1.ToC.req => Table of contents
2.Vision.req => Product vision as defined in http://www.yegor256.com/2014/10/20/how-we-write-product-vision.html
3.Glossary.req => Global glossary for general non-UC directly related definitions (all the definitions required for a general understanding of the application)
N.Grouping.req => File containing a collection of User Cases or NFRs defined by Grouping
The idea behind this request is to know where to start and where to look in order to quickly find the definition for a given feature without having to necessarily browse through the whole SRS file structure regularly to find a feature/user case definition.
ToC
This file is to present the full contents of the SRS for quick access and reference:
1. ToC is referred to 1.ToS.req and defined as "Table of Contents"
2. Vision is referred to 2.Vision.req and defined as "Product Vision"
3. Glossary referred to 3.Glossary.req and defined as "General Glossary"
4. G1 is referred to 4.G1.req and defined as "User behavior with Feature X"
N. GN+1 is referred to N.GN+1.req and defined as "User behavior with Feature Y"
Grouping
Grouping is a collection of user cases related to a feature of set of features that would fall in the same group.
A grouping would be structured as follows:
Group definition
Group Table of contents listing UC and signatures
Group local glossary
Use case or NFR definitions
:G1 is defined as "User behavior with Feature X":
"""
Full definition of grouping briefly describing the general relation between Use Cases, or use keywords/key phrases for quick searches.
""".
G1 describes:
1. UC1 where User (a user) does Something (an action).
2. UC3 where User (a user) receives Something (an object).
User is "
Full user definition
".
Something is "
Full Something definition
".
:UC1 is implemented.
UC1 where User (a user) does Something (an action):
1. ....
2. .....
:UC3 is implemented.
UC3 where User (a user) receives Something (an object):
1. ....
2. .....
I probably missed a lot of details as I am not extremely proficient with the requs syntax yet, but that's the general idea.
davvd
commented
8 years ago
@yegor256 on a previous question I asked in regards to Requs (issue #103) you provided a link to one of your other projects that used this SRS syntax to establish the application. You also mentioned that you only used Requs in bigger projects. I noticed that this project was broken down into multiple files. However when reading the req files in the project I thought it might be easier to have a more structured approach to the process.
Also based on one of your posts about the worst SRSs (http://www.yegor256.com/2015/03/16/technical-glossaries.html) you mentioned the need for glossaries in SRS in order to make it complete. In the example you provided (thinkdeck) you only provide a self contained glossary of User Case specific definitions, but no general one (this may not have been a necessity for that specific project).
In the case of a larger project, there will inevitably be a multi-file SRS for simplicity of reading as the project grows.
File Structure
Having a standardized file structure for such cases would most likely help with the SRS as follows:
1.ToC.req => Table of contents 2.Vision.req => Product vision as defined in http://www.yegor256.com/2014/10/20/how-we-write-product-vision.html 3.Glossary.req => Global glossary for general non-UC directly related definitions (all the definitions required for a general understanding of the application) N.Grouping.req => File containing a collection of User Cases or NFRs defined by Grouping
The idea behind this request is to know where to start and where to look in order to quickly find the definition for a given feature without having to necessarily browse through the whole SRS file structure regularly to find a feature/user case definition.
ToC
This file is to present the full contents of the SRS for quick access and reference:
Grouping
Grouping is a collection of user cases related to a feature of set of features that would fall in the same group.
A grouping would be structured as follows:
I probably missed a lot of details as I am not extremely proficient with the requs syntax yet, but that's the general idea.
Let me know what you think.