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

[Mark]

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 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
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.html