Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
What is a good strategy to label software requirements in an SRS?
Typically outline numbering is employed on headers - but these will renumber if a new heading is inserted in the document. To me it seems like a good idea to aim for a more stable designation for each software requirement. This should make it easier to reference a particular requirement even in the face of an updated SRS.
What are your experiences on this?
One strategy:
There are other strategies, such as using dotted decimals to cluster requirements, for example:
As you might guess, the respective requirements should be ordered under the top-level number accordingly: 1.1, 1.2...for GUI, 2.1, 2.3, 2.4 for DB, etc. Note that this strategy will need some form of controlled method for managing deletions and additions.
The key thing to enforce in a requirements document: once an ID has been used for a requirement, it cannot be used again different requirement. In other words, if SRS 1234 was used and then deleted, it cannot resurface later. (Allowing it to do so wreaks absolute havoc on requirements traceability over the course of an evolving project.)
Note that virtually any SRS organization/structure will have deficiencies. Pick the one that suits your development environment and your application needs. (For example, the strategies above work reasonably well in highly-controlled development environments, such as those monitored by the FDA or other governmental bodies.)
Finally, consider using a requirements management tool. There are good ones out there (open source to $$$$$) that will take care of all of this for you.
Best conceptual thinking is that Requirements are distinct items, related to one another in various ways and therefore should be stored in a Database. Using a word processor to store requirements is the wrong way, and leads to many problems as it drives conceptual thinking that "requirements are a document" - hence this question. If you must use a word processor, keep each requirement separate, just as you would if you used Word to store contacts.
Therefore, using Outline numbering to maintain requirements is going to cause problems. Imagine trying to cross reference test and SRS and customer requirements if you change the numbers? Imagine discussing "Requirement 10.2.3.1" only to find that in yesterdays document you sent the customer it was "10.2.2.1"
Requirements are a label, and should convey little meaning. You might have one or a few short 2 to 5 letter prefix to identify the scope or unit, but by the time you have several thousand, any implied meaning should be limited. e.g. in a car you might have EM-FUEL-1234 (Engine Management, Fuel control system, requirement 1234).
Requirements should be able to be reused across projects.
Requirements must be unique, across the scope and life of the project. As a guide, changing a requirement to clarify is the same number, but to chnage it significantly, delete the old one and replace it. Using a version scheme (Append_1,_2 etc to it) can be useful.
If you must use Word to store this database, a good way is to use start and end tokens to identify requirements. If you use a unique font Style for requirements numbering, it becomes easy to highlight, search and extract them using Macros (into a database maybe) . Example Might be
#Req 1234#
Bla bla bla bla
#ReqEnd#
#Req 1234a#
Bla bla bla bla and more bla
#ReqEnd#
