3

Our application needs to run in a locked-down operating system. Due to quality and regulatory concerns, all updates shall be prevented or blocked. Therefore, our deployment includes the pre-configured operating system. To make any changes to the OS, admin credentials need to be used.

Some teammates think the "updates blocked" requirement fall in the same domain as the application. I think they are out of scope for the application.

Should system configuration settings have a specification assigned to them? On what document? Should this be part of the SRS with the rest of the application's software specifications or should this be recorded as specifications in another domain?

Testing of the requirement shall happen regardless of where it is documented.

Thanks in advance for your time.

Improve this question
11
  • What OS do you in mind? Commented Nov 5, 2019 at 22:58
  • We are using Windows. Do you think that is an important consideration? Commented Nov 5, 2019 at 23:08
  • 2
    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. Commented Nov 6, 2019 at 7:42
  • 3
    @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. Commented Nov 6, 2019 at 19:44
  • 2
    @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). Commented Nov 6, 2019 at 22:07

4 Answers 4

Reset to default
4

To me, testing is about validating the required functionality, testing is not about how a requirement is implemented.

Since disabling updates is required functionality, it should be tested. That's no different than any other requirement.

The fact that implementation is managed through configuration is incidental and should not be used to decide what is tested.

Improve this answer
8
  • I agree that it should be tested, as with all requirements. Should this be part of the SRS with the rest of the application's requirements? It's not a functionality of the application; it's a specification of the system, of the environment where the application will run. Commented Nov 6, 2019 at 14:35
  • Yes, this should be part of the requirements because it is part of the application. How it's implemented does not determine what is a requirement. Commented Nov 6, 2019 at 15:42
  • I agree that how it's implemented does not determine what is a requirement. It would be part of the system requirements specifications, not the software requirements specification. Does that make sense? Commented Nov 6, 2019 at 19:09
  • I'll remove 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. Commented Nov 7, 2019 at 15:42
  • Yes, this needs to be part of the specification. It's a requirement; if it is not in the specification, how else would you know about the requirement? Commented Nov 8, 2019 at 15:20
2

It sounds like you need a seperate program[1] (or script) which checks if the system requirements are met. I would not consider this a test thing. However, if you have some behavior in the program, which causes it to shut down if the requirements are not met, well that's something you can test.

[1] It can also be build into the main program. It doesn't really matter, the important part is that it is an isolated part, which can be run independanty of the remaining program.

Improve this answer
1

You state that the environment in which the application runs is so important for the company that you only deploy a combination of application and pre-configured OS. Furthermore you mention that this is at least in part due to regulatory requirements.

Regulatory requirements imply that you must provide some kind of proof that the system as you deliver it to your customers satisfies the requirement and the notified body checking the requirement doesn't care who created the relevant part of the system. The onus is on you to provide the required proofs.

This means that it doesn't matter if the "updates blocked" requirement is in scope for the application or not. You will have to test it anyway.

Improve this answer
3
  • I agree that it should be tested, as with all requirements. Should this be part of the SRS with the rest of the application's requirements? It's not a functionality of the application; it's a specification of the system, of the environment where the application will run. Commented Nov 6, 2019 at 14:40
  • @00Zero, that depends on your project setup and, for example, what your testers use as input for specifying the tests. There must be a trigger in the process somewhere that for each release of the deployment package it must be checked if retesting this requirement is needed. I don't know your processes, so I can't tell if it is needed for that trigger that the requirement is in the SRS. Commented Nov 6, 2019 at 15:36
  • 2
    @00Zero, looking at it from another perspective, it might not be a requirement for the application, but it is a requirement for the software you will be delivering. Commented Nov 6, 2019 at 15:37
1

I think the assumption that there is only one SRS document is incorrect. If more than 1 Software Configuration Item (SCI) exists then those system requirements further get mapped to each relevant SCI.

Your OS configuration and application will almost certainly be versioned independently of each other. Thus, at a minimum your system should contain 2 SCIs. The OS requirements get mapped to the OS Baseline SCI and the application requirements get mapped to the application SCI.

You then test each SCI separately to verify it meets the software requirements mapped to it.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.