<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div id="compose-container" itemscope="" itemtype="https://schema.org/EmailMessage">
<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name" content="Outlook Mobile for iOS"></span></span>
<div>
<div>Hi all</div>
<div>Seeing as we are throwing money 💰- here goes.</div>
<div><br>
</div>
<div>Mark is correct about the real world being different from VCE however I feel the intention of the study design is clear. The SRS is the culmination of the analysis work. It is completed before the design work begins. Seeing as I have not begun any design
of the new system yet, the SRS must therefore contain documentation of the existing system.</div>
<div>Many of the tools could be used as analysis and design tools. </div>
<div><br>
</div>
<div>Andrew Pate </div>
<div>Mentone Grammar<br>
<br>
<div class="acompli_signature">Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>
<br>
</div>
</div>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Mon, Mar 20, 2017 at 4:03 PM +1100, "sofdev-request@edulists.com.au"
<span dir="ltr"><<a href="mailto:sofdev-request@edulists.com.au" target="_blank">sofdev-request@edulists.com.au</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<pre>Send sofdev mailing list submissions to
sofdev@edulists.com.au
To subscribe or unsubscribe via the World Wide Web, visit
http://www.edulists.com.au/mailman/listinfo/sofdev
or, via email, send a message with subject or body 'help' to
sofdev-request@edulists.com.au
You can reach the person managing the list at
sofdev-owner@edulists.com.au
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sofdev digest..."
Today's Topics:
1. Re: Diagrams in the SRS - of which system? (Mark)
2. Re: Diagrams in the SRS - of which system? (Fitzpatrick, Michael)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Mar 2017 14:04:24 +1100
From: Mark <mark@vceit.com>
Subject: Re: [Year 12 SofDev] Diagrams in the SRS - of which system?
To: "Year 12 Software Development Teachers' Mailing List"
<sofdev@edulists.com.au>
Message-ID:
<cacu=8z1sndqa0gvj=jrshj6v7und8+mz2gmdy9l2_oca-eh53w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/
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@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@vceit.com
http://vceit.com
Powered by *Mitochondria.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20170320/67ee2e4c/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 20 Mar 2017 05:02:24 +0000
From: "Fitzpatrick, Michael" <michael.fitzpatrick@carey.com.au>
Subject: Re: [Year 12 SofDev] Diagrams in the SRS - of which system?
To: "Year 12 Software Development Teachers' Mailing List"
<sofdev@edulists.com.au>
Message-ID:
<7067F557BEA5BF4E950778A9B7FAB0310247DAB258@CGKEWMB10.kew.carey.com.au>
Content-Type: text/plain; charset="utf-8"
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@edulists.com.au [mailto:sofdev-bounces@edulists.com.au] On Behalf Of Mark
Sent: Monday, 20 March 2017 2:04 PM
To: Year 12 Software Development Teachers' Mailing List <sofdev@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.orgdocument720574="" />
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@gmail.com<mailto:janson.adrian.a@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@vceit.com<mailto:mark@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.html
------------------------------
_______________________________________________
sofdev mailing list
sofdev@edulists.com.au
http://www.edulists.com.au/mailman/listinfo/sofdev
End of sofdev Digest, Vol 144, Issue 32
***************************************
</mailto:mark@vceit.com></huge></janson.adrian.a@gmail.com<mailto:janson.adrian.a@gmail.com></sofdev@edulists.com.au></sofdev@edulists.com.au></michael.fitzpatrick@carey.com.au></huge></janson.adrian.a@gmail.com></cacu=8z1sndqa0gvj=jrshj6v7und8+mz2gmdy9l2_oca-eh53w@mail.gmail.com></sofdev@edulists.com.au></mark@vceit.com></pre>
</div>
</blockquote>
</div>
</body>
</html>