9

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?

1
  • 2
    Why downvotes? Requirements management can be non-trivial. Good software development practices foster good software. Mar 18, 2013 at 13:29

2 Answers 2

9

One strategy:

  1. Consider the SRS ID as just a number, and don't imply any strong notion of consecutive order (The social security number is a reasonable example.)
  2. Don't recycle numbers. When an ID in a sequence is deleted, mark it "Deleted", "Deprecated", etc. I prefer to keep the requirement text in the deleted item so that I have a running record of the requirement evolution. If you choose to do this, mark the deleted text obviously, for example a strike-out font.
  3. #2 implies that new requirement additions will never occur "in place"; rather, they are always appended to the document.
  4. This strategy can become difficult to organize or cluster hierarchically as changes accumulate, so tag each SRS ID with a meaningful label for searching, i.e. [GUI], [DB], etc.

There are other strategies, such as using dotted decimals to cluster requirements, for example:

  • 1.0 GUI
  • 2.0 DB
  • 3.0 Processing

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.

2
  • Requirements that are organized via technology stack area (GUI, DB, Processing) aren't requirements, they are tasks. If anything, technical requirements should be limited to one area discussing technical constraints, e.g. Must run on Windows 7 and above. Delimiting requirements via tech stack is a bad smell. Mar 18, 2013 at 17:32
  • The intent was to provide an example of high-level, logical organization of requirements (i.e. user interface versus storage, etc). There are no technological "stacks" or constraints stated or implied in the post. Mar 18, 2013 at 18:03
2

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#

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.