Skip to main content
24 events
when toggle format what by license comment
Nov 25, 2019 at 2:18 audit Suggested edits
Nov 25, 2019 at 4:05
Nov 8, 2019 at 9:00 history tweeted twitter.com/StackSoftEng/status/1192728557816029184
Nov 7, 2019 at 22:45 history protected gnat
Nov 7, 2019 at 20:08 answer added Blido timeline score: 1
Nov 7, 2019 at 15:47 comment added OwnDevise I removed the question about testing from the original question as it's seemingly diverting the discussion in a direction that's not helping to determine where the specification of the OS parameters should be defined. Testing of the required funcionality shall happen regardless of where the specification is documented.
Nov 7, 2019 at 15:46 history edited OwnDevise CC BY-SA 4.0
Removed question about testing. Testing of the requirement shall happen regardless.
Nov 6, 2019 at 22:07 comment added 17 of 26 @00Zero It probably makes sense as a system specification rather than an application specification. Blocking updates is a property of the operating system configuration, and isn't something that your application actually needs to do (or worry about).
Nov 6, 2019 at 22:05 history edited OwnDevise CC BY-SA 4.0
Expanded spec to specifications in Title.
Nov 6, 2019 at 22:02 comment added OwnDevise @17of26, yes! No doubt it shall be documented. The various responses seem to converge on it being documented as a system specification and tested in the system domain, not as a specification for the application. My question arises from an unclear separation of domains in my project. Hence, I'm reaching out to the community for some guidance.
Nov 6, 2019 at 20:09 comment added 17 of 26 @00Zero This should absolutely be a documented requirement somewhere. Without knowing your company's process setup, it's hard to say which document it should be in.
Nov 6, 2019 at 19:49 comment added 17 of 26 Furthermore, the Windows embedded family of OS has a feature called EWF which can prevent data from being written to the hard drive. We use this feature to block any modifications to the boot drive. So, automatic updates would be discarded even if they were enabled.
Nov 6, 2019 at 19:44 comment added 17 of 26 @Flater In the medical device industry, every change to a system must be evaluated, documented, and tested. Automatic updates are a huge risk because they have the potential to break something. In the world of medical devices, this can literally cause injury or death.
Nov 6, 2019 at 19:22 history edited OwnDevise CC BY-SA 4.0
Where I wrote software requirements I clarified I meant software specifications
Nov 6, 2019 at 14:39 history edited OwnDevise CC BY-SA 4.0
added 102 characters in body
Nov 6, 2019 at 13:08 answer added Bart van Ingen Schenau timeline score: 1
Nov 6, 2019 at 7:42 comment added Flater Enforcing that updates are disabled sounds dodgy. Not just because updates often bring security patches (and it initially comes across as wanting to avoid those security updates), but also that you've developed an application tied to not only an incredibly precise OS version. I would consider prohibiting OS updates to be a quality and regulatory concern in and of itself. That being said, it's perfectly possible that there is a good reason for this that I am not aware of.
Nov 6, 2019 at 6:37 answer added Jakob Busk Sørensen timeline score: 2
Nov 6, 2019 at 5:06 answer added Jeff S timeline score: 4
Nov 5, 2019 at 23:32 comment added OwnDevise I understand, but my question is regarding adding the system configuration settings as software specifications.
Nov 5, 2019 at 23:15 comment added Cloud Cho I think OS is essential for application configuration. For your program, will you plan to use PowerShell DSC (to lock down)?
Nov 5, 2019 at 23:08 comment added OwnDevise We are using Windows. Do you think that is an important consideration?
Nov 5, 2019 at 22:58 comment added Cloud Cho What OS do you in mind?
Nov 5, 2019 at 22:55 review First posts
Nov 6, 2019 at 21:09
Nov 5, 2019 at 22:54 history asked OwnDevise CC BY-SA 4.0