[Year 12 SofDev] Diagrams in the SRS - of which system?

Fitzpatrick, Michael michael.fitzpatrick at carey.com.au
Mon Mar 20 16:02:24 AEDT 2017


The argument is getting confusing with the purposes of both steps not being clear.

The analysis is done to determine the problems that need to be solved in the old system.

The SRS is the solution to these problems and by definition has included all the considerations from the old system that needed to be solved.
It may need to include elements of the old system that were documented in the analysis that are required to be kept or adapted in the new system.

The tools used for both may be the same but clearly different purposes.


From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Mark
Sent: Monday, 20 March 2017 2:04 PM
To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au>
Subject: Re: [Year 12 SofDev] Diagrams in the SRS - of which system?

OK... we seem to be here for the full half-hour argument. (Cracks knuckles).

Let's leave the rarefied atmosphere of VCE IT and set foot in The Real World to see what an SRS contains.

Again: Facts. Not opinions.

http://www.fdot.gov/it/PDM/3_Requirements/Software_Requirement_Specification_Template.docx
No, can't see any references to documenting existing systems or practices there...

https://www.slideshare.net/iamtheuser/srs-software-requirement-specification-template
There is no "Description of existing system" in that template.

https://techwhirl.com/writing-software-requirements-specifications/
(BTW - this is a good SRS summary - you might want to read it!)
It says, "Several standards organizations (including the IEEE) have identified nine topics that must be addressed when designing and writing an SRS:
1.     Interfaces
2.     Functional Capabilities
3.     Performance Levels
4.     Data Structures/Elements
5.     Safety
6.     Reliability
7.     Security/Privacy
8.     Quality
9.     Constraints and Limitations"
There is no mention of a description of the old/existing system...

And, finally, the grand-daddy IEEE SRS template... ieeexplore.ieee.org/document/720574/<http://ieeexplore.ieee.org/document/720574/>
No. I can't find any section that involves describing the old/existing system.

So.

Here's a fun challenge for those of you who believe an SRS should document the old system:
Find any real, reputable SRS that includes any diagrams or other descriptions of the old system.

I'll wait over here.

Regards,
Mark




On 20 March 2017 at 12:49, Adrian Janson <janson.adrian.a at gmail.com<mailto:janson.adrian.a at gmail.com>> wrote:
Me too!! (sorry Mark - that was for you!)

OK - my 2c worth.

By definition an SRS is a tool that is used to lay out the specifications that will be required to be addressed by a new system. It is not a design tool and is the result of analysis that is done to determine the needs of the organisation in regards to their information system. I feel like everyone agrees on this point - so it's probably not necessary to harp on it too much more.

However, the investigation of the existing system - network diagram, UCD, DFDs and other tools that might be used - are all necessary to get a feel for what the existing system does and doesn't do. While I understand where Mark is coming from with his analogy, I feel that coming into an organisation as a contracted IT professional and being handed an SRS and being told to get to work is not realistic. You need to have an understanding of what is in existence.

What elements of the existing information system will be kept and integrated with the new system?
How will the implementation of the new system impact on what is already in place?

Without that understanding (yes - looking back to look forward), I don't see how you can possibly begin designing a new system. Many of us have done LMS changeovers or large scale implementations and have been on staff for years prior - and even in this case, it would be a brave person who would design a new system without strongly documenting the existing system first.

Cheers,
Adrian Janson


 <huge snip>
--

Mark Kelly

mark at vceit.com<mailto:mark at vceit.com>
http://vceit.com

Powered by Mitochondria.



DISCLAIMER:This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the School. Finally, the recipient should check this email and any attachments for the presence of viruses. The School accepts no liability for any damage caused by any virus transmitted by this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20170320/7495c2d8/attachment-0001.html 


More information about the sofdev mailing list