Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  SRS and management of conflicting established system requirements
Previous Previous
 
Next Next
New Post 6/15/2011 8:25 AM
Unresolved
User is offline rosscsoft
3 posts
No Ranking


SRS and management of conflicting established system requirements 

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!

 
New Post 6/16/2011 2:18 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: SRS and management of conflicting established system requirements 

 Hi Rosscsoft,

Man, you like a complicated life! Really this stuff can be whatever you want it to be. Don't think there is any standard.

Can't help thinking you have too much text. Why don't you throw away the SRS and develop some use cases, process diagrams, use case diagrams, class diagrams, state charts, rules / validations, etc. Rather than state something like...  FR300: Change main window title text from Company ABC to Company XYZ ... why not mock up the screen and show exactly what you mean.

Pictures and structured definitions like use cases are always better and more precise than words/sentences. Words are easily misinterpreted. As you develop changes you can change your artefacts. 

Perhaps I haven't understood properly what you are doing.

Kimbo

 
New Post 6/16/2011 2:35 PM
User is offline rosscsoft
3 posts
No Ranking


Re: SRS and management of conflicting established system requirements 

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

 

 

 

 
New Post 6/17/2011 8:10 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: SRS and management of conflicting established system requirements 

 Hi Ross,

Sounds like a plan. I use EA. Its pretty good. Plus there is (somewhere) a button to push that generates test cases out of use cases which will help with your testing efforts that you mention.

Didn't say it yesterday but I worked at a site where everything was defined in textual requirements. Hated the place. Tedious to the extreme and hard to visualise what was really happening. Low productivity too.

You're on the right track. Good luck with it.

Kimbo

 
New Post 6/17/2011 6:18 PM
User is offline KJ
243 posts
6th Level Poster


Re: SRS and management of conflicting established system requirements 

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  SRS and management of conflicting established system requirements

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 



 

Copyright 2006-2021 by Modern Analyst Media LLC