4

I have a few requirements of the type

  • "the system shall be as modular as possible (to allow distributed installation and reduce cabling)"
  • "to reduce development and maintenance costs, the same hardware shall be used for different subsystem's when possible"

I see these as ambigous. Can anyone think of a way of writing them unambigously?

  • You may wonder yourself, is it the wording that is ambigous or the requirments that is too vague ? On your first point I think the requirement seems really vague, while the second point seems very clear to me, so maybe change the wording. – Walfrat Feb 22 '17 at 13:52
5

Requirements can be checked objectively.

  • Functional requirements specify a capability of the system and can be tested fairly easily. E.g. the requirement “As a user, I can click a button to get a funny cat picture” can be tested by assuming the role of a user and clicking the button. Did I get a cat pic? If so, the requirement has been fulfilled by the system.

  • Non-functional requirements specify a quality of the system, but this quality must be measurable or verifiable too. One quality is performance of the system. A wish “the system should be fast” isn't a requirement because it can't be tested, measured, verified. What is “fast”? A requirement like “The system can handle 200 funny cat picture requests per second” can be verified objectively through a load test, and therefore is a valid requirement.

If you are dealing with vague wishes that can't be verified, it's the job of a software developer to clarify them. Often, there is a more fundamental requirement underneath these wishes. Why is distributed installation important, why should cabling be reduced? Is there perhaps a hidden reliability requirement? What if you can satisfy the real requirement better by not using a distributed system? What is the maximum acceptable amount of cabling? Every feature is a trade-off: Can we trade in more cabling for some more important features?

While requirements should not generally prescribe implementation details of the system, it is often sensible to impose some design constraints, especially if they touch on an organization's strategic decisions. E.g. if a company decided to standardize on hardware from a specific vendor, the system will have to live within these constraints.

But not every requirement is equally important. Techniques like the MoSCoW method allow us to grade their importance (must, should, could, or won't) (compare also RFC 2119). Certain capabilities or qualities are desirable but not absolutely necessary. Your “as much as possible” requirements could be reformulated to be measurable, but have a middle priority. E.g:

  • The system MUST continue to operate even when any one server fails.
  • The system SHOULD use the same hardware and operating system for all servers.
  • Ok. I get the idea that there must be an underlying reason to want to do something in a certain, and That is the requirement. It's just tricky to find this in some cases. – Paul Feb 22 '17 at 15:28
  • 2
    It might also be worth keeping track of the "why" of these contraints. Why should the same hardware be used on all servers? Having that traceability allows better decisions whenever a requirement is examined way after its creation and possibly contested. – leokhorn Feb 23 '17 at 8:24
2

No. Rule one of requirements is that they should be verifiable. Neither of these are so they should be thrown out or refined.

Both requirements contain the word "possible" which itself should be defined. One man's "possible", is another man's "impossible".

These are better (although they would still need refining):

  • The system shall be modular
  • Common hardware shall be used across subsystems
1

The first requirement is untestable and unverifiable, as Robbie Dee correctly points out. When carried to the limit, you end up with jar files containing only a single class.

The second requirement is nearly so.

"to reduce development and maintenance costs, the same hardware shall be used for different subsystem's when possible"

Does this mean that when the hardware is extremely underpowered for the task, that it should still be used but requires rewriting the software to optimize it? A better word would be "feasible", as that is clearly an economic qualifier that allows justification and reasoning based on relative costs and benefits.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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