I've read in multiple places that the requirements must not be influenced by solution and must not contain solution. So in the below example , please can you help in letting me which is correct -

Application A is interacting with Application B to install a new service / change the service type and disconnect a service. There 3 different service types 1,2 and 3. Application B does not support changing service from 1 to 2 or 1 to 3. Hence 1 must be disconnected and then 2 and 3 must be added. However service can be changed from 2 to 3 or 3 to 2 directly.

In the above case , changing the service from 1 to 2 or 1 to 3 is a system level contraint. However from an end user's perspective this is a service change.

In the above case , should I have a single system requirement stating system shall allow service to be changed for all the service types supported or should I have 2 different system requirement - 1 stating which all services can be upgraded directly and the 2nd stating in which cases service needs to be disconnected and installed?

  • Unless you're doing a homework assignment, it doesn't really much matter. What's important is clearly documenting what needs to be done & important restrictions on how it gets done. Don't bury important details in footnotes or in the middle of big lists of minor specifications. Feb 11, 2013 at 22:11
  • Thanks Sean, it is not a homework assignment. Shouldn't requirements focus only on "what" needs to be done? I thought requirements in general should not specify "how" something needs to be done. Feb 11, 2013 at 22:16

1 Answer 1


Requirements are that and only that: what is the required outcome for the system in question?

In this case, the System Requirements appears to be:

Application A must be able to:

  • install a new service of type 1, 2, or 3
  • change the service type of an existing service of type 1, 2, or 3
  • disconnect a service of type 1, 2, or 3

in Application B

Requirements should be stated positively whenever possible, and phrased so as to be testable.

The specific implementation problems described are not part of the requirements. They are part of the design constraints.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.