Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have a few requirements of the type
I see these as ambigous. Can anyone think of a way of writing them unambigously?
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.
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 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.
