Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter 8: Properties of Good Requirements

  • In this article, the authors state that requirements must be nonprescriptive. Give a definition of this term and an example that is different than the one provided in the text.

Nonprescriptive Requirements Describe what the software will do from an external point of view, not how the software will do it.

An example - The software will use the bubble-sort algorithm whenever sorting is called for.
Elizabeth Zehner
Nonprescriptive Requirements should only describe what the software should do from the view point of a user. They should not deal with how the software should solve these requirements. If the requirements specify how something should be done then they are exhibiting design bias.

An example of this would be that we will use the visitor design pattern to perform calculations on a balanced binary tree. This violates the nonprescriptive directive in two ways. it specifies that the visitor design pattern should be used but also that data should be stored in a balanced binary tree.
Jim Clause

Nonprescriptive Requirements describes "the behavior of a system from an external point of view." In short, requirements are specifications of what software must do, not how it can do it.

An example, would be a user requesting an online banking system.

Nonprescriptive Requirements - The system must be able to handle such and such account actions, securely, and communicate these changes to a database.

Prescriptive Requirements - Such and such account actions will be handled by searching through a database using some specific algorithm then performing the actions, the transactions and communications are secure using this specific cryptography algorithm, and we will communicate with the database using this specific protocol. (Prescriptive Requirements are specific in how they want to implement the software to meet the requirements, this is work to be done during the design phase not the requirements phase)

Dan Fiedler

  • What is the difference between a precise requirement and a concise requirement? Give examples of both types of requirements.
Precise Requirements Say exactly what they mean to say without being vague; they are difficult to misinterpret.

An example - Imprecise: Necessary spreadsheet commands will include: "add, "mod," (etc.)
Precise: Necessary spreadsheet commands will include: "add," "mod," (etc.) that are not case-sensitive.

Concise Requirements Deal with the issue at hand and do not ramble on.
An example - Not Concise: "Remote testing methods enable testing between a tester and participant who are not colocated. In this case the evaluator is not able to observe the participant directly, but can gather data about the process over a computer network. Remote testing methods are distinguished according to whether a tester observes the participant during testing. Same-time different place and different-time different-place are two major remote testing approaches." (From an ACM Computing Surveys paper.)
Concise: "Remote testing methods use computer networks to gather data when the tester and participant are not in the same place. Remote testing can either use real-time observations, or recorded for later use observations."
Elizabeth Zehner
A precise requirment is one that is not open to interpretation. Something like "make a sandwich" is not a precise requirement. There are many different ways to create a sandwich. There are about 35 different steps in making a sandwich. A precise requirement would list all of these steps.

A concise requirement is one that maintains the minimal possible amount of verbosity necessary to successfully convey the idea to the intended recipient. It also will not use an excess of jargon to encapsulate concepts into a single word or phrase.

In other words a concise requirement uses as many words as necessary to express the idea and doesn't use technical terms to express the idea.

Jim Clause

A concise requirement is a description of what software must do without any additional superfluous information.

Concise Requirement- A good design for software systems has all tests run at 100%, contains no duplicate logic and states every intention important to the programmers.

Not Concise Requirement- A good design for software system has all tests run at 100% because this is a good way to verify and validate that your design meets its requirements and specifications, as well as showing that your code is correct. A good design does not contain any duplicate logic such as paralell and non-useful inheritance hierarchies. Another example of duplicate logic is additional unneeded, or trivial, methods. Lastly, a good design can use javadoc, commenting, and test cases to state every intention of the programmers who worked on the software, making it clear what they wanted to accomplish and how they accomplished it.

A precise requirement is an elegant and unambiguous description of what software must do.

Not Precise Requirement- I like short labs.
Precise Requirement- I like labs that can be completed in the 2 hour lab period.
Dan Fiedler

Links to this Page