I am a software developer trying to formalise a requirements process for a small software development company via a new project I am working on.  I have some confusion over the scope and purpose of the SRS and requirement management. I'd really appreciate some advice from established system/business analysts!  Apologies for the essay, this question seemed to grow and grow...

1) I am intending to use a Software Requirements Specification (SRS) as the basis for agreement with the client as to exactly what work we will carry out.  The business requirements and user requirements have been been handled and I am currently deriving system-level requirements to put in the SRS.  Am I on the right track with this?

2) My understanding is that the SRS is a project-scope document.  Once the project is over, the SRS is never modified again regardless of future developments to the same software product.  Any new modification project would require a new SRS.  The SRS belongs to a PROJECT, not a PRODUCT. Do I understand this correctly?

3) In my project, the user requirements specify changes to an existing and mature product (currently at version 3.0). There is a requirements database of system-level requirements for this product that I have built up from previous projects (currently baselined at v3.0). Regression tests have been defined against these baselined requirements.  Therefore, these requirements are at PRODUCT-scope - they define the behaviour of the whole product in absolute terms as at v3.0 regardless of originating development projects.  Is this is a reasonable way to maintain requirements?

4) My confusion arises listing system requirements in the SRS, derived from the project user requirements. Because the user requirements specify changes to existing features, the system requirements I derive will conflict with those existing in the database (which specify the original behaviour).  This is a problem because I don't want differing schemes of system requirements between the SRS and the database.  E.g. requirement FR147 in the SRS should be the one-and-only FR147 in the database, with numbering defined by the database, not the SRS.  Is this a sensible aim or would I be better off inventing a new numbering scheme for each project and migrating requirements (and resolving conflicts) to the product database at the end of the project?

5) At present, the only way I see to reconcile this in the SRS is to list not only new system requirements, but existing ones from the database that should be ammended or deleted also. Is this a common/acceptable approach?  If not, how does everyone handle this issue?

6) Another source of confusion is the manner in which user and system requirements should be expressed when referring to modification of an existing feature.  For example, the user requirement UR1: "Change all references to Company ABC to Company XYZ instead".  This requirement has been expressed in relative terms.  However, presumably I shouldnt write system requirements in these terms, e.g. "FR300: Change main window title text from Company ABC to Company XYZ".  The system requirements should be absolute e.g "FR300: The main window title shall state Company XYZ".  Am I correct with this?

Any insight as to how you all handle these issues would be much appreciated!  Many Thanks!

Hi Kimbo

Thanks for the feedback - much appreciated!  I was hoping that someone would say that these concepts were flexible!

I would like a less complicated life but sadly this seems to be the result when a bunch of simple ideas collide.  I am trying to address the following simple-ish company needs:

1. The need to have a documented agreement I can hand to a client (at technical project manager level) that states "this is what we are going to do in this project".
2. The ability to test/verify that the contents of the above document have been fulfilled and that the software meets requirements.
3. The ability to arbitrarily (at any point in the future) test/verify that the software product STILL meets all requirements that have accumulated over many projects/years. 

(1) is satisfied by using an SRS, (2) can be achieved using tests based on requirements listed in the SRS.

I think it is really (3) that causes the complexity.  For example, in 3 years time (and many unrelated modifications later) I want to test that the requirements laid down in todays project are STILL met. Therefore any system requirements must be constructed in such a way that they are still coherent (both in content and numbering) in 3 years time, outside the context of this project.  Matters are further complicated by projects that change requirements introduced by previous projects. These need to be managed so that there is only one "correct" view of all the requirements for the latest version of the product.

I've been running with the system I suggested yesterday and it seems to be working nicely:

I have a project SRS that lists the features of the existing product to be added or modified.  Each feature has a "Description" section that lays out in plain english (more or less taken from user requirements) how the product is to be modified in project-context language. E.g. "The system currently does XYZ but we are going to change it slightly so it does WXYZ". 

Then, in a sub-section I am listing "Amended Existing Requirements". This section states any conflicting system-level requirements that already exist in the requirements database using their existing numbers e.g. "FR140: The system shall do XYZ". The modification to the requirement is shown and is in ABSOLUTE terms (not project context) e.g. "FR140: The system shall do XYZ WXYZ".

A further sub-section lists any new system requirements, again in absolute terms (no use of the word "change"). The numbering system is coherent with the requirements database and not related to the project or SRS.

With the above process, I end up with a verifiable SRS document where both new and amended system requirements will end up in the main requirement database ready for regression testing in the later life of the product.

I think you are absolutely right to suggest we lean away from formally-stated requirements and more towards diagrams.  It would seem you can express requirements in many ways in an SRS e.g. use cases, use case diagrams, flow diagrams.  All nicely verifiable too! I am going to use Sparx Enterprise Architect as the repository for all product requirements. This way I can easily introduce use case diagrams etc and manage them in the SRS in exactly the same way as formal requirements detailed above: "Description of feature, Amended Existing Use-cases, New Use Cases".

Hopefully this should give the best of both worlds!

Ross

Ross,

This is intense: you have an SRS sitting between a BRS and URS. Wow! Now you know why AGILE with its "lack" of documentation is becoming flavour of the month.

Your project very much reminds me of our very successful and paper laden project we did almost 30 years ago! We had to have SRS, BRS and URS, and TDS (Technical Design specs) before program specs were written. The upshot was, when the SRS, URS and BRS were completed (took 18 months), we did not need 35% of what was written. Yep. We only implemented 65% of what was originally asked for. the remainder or new things were managed through a Change management system (CRs - Change Requests). The reason for all these machinations and deliverables was "fix price contract!". And, three and half years later with 250 programmers, we delivered! Some of the code was written in BCPL, a fore runner to C! (I think thats why Kenigham and Richie called their language C). Since then we've had variations on C --> C++ and C#.  That was a long time ago. Our guiding light was ANSI/IEEE SRS Standard 830-1984 for our SRS. 

There are heaps of tools and newer methodologies and techniques available TODAY. EA is an excellent choice; it allows you to capture all BRS, URS, SRS including CR information. The Matrix function EA allows you to track the changes (original SRS and CRs).

All the best!

K