Systems Home | Introduction | Needs Assessment | Requirements Specification | Requirements Analysis | Preliminary Design | Detailed Design | Implementation | Testing

Systems Development: Requirements, Design, Implementation, Testing

Requirements Specification

Tangible Versus Intangible Elements

How does one measure what one cannot see?

In elementary economics, we learned there are two types of work output: goods and services. Goods, we learned, are tangible products that we can feel, see, and in some cases taste. Services are intangible items that have none of these characteristics.

Consider, for example, a shoe repair service. It's an intangible: we would pay a cobbler to replace the heel of our shoe. The parts, or the heel and nails, are goods. But the cobbler's effort, knowledge, and skill used to make the repair are part of the intangible service.

Now we can measure the output of an intangible service. We can look at the repaired shoe and decide if the quality is poor, fair, good, or excellent. We can also determine if the service cost was reasonable or not. So while we may not be able to measure something intangible directly, we may be able to measure the tangible output of an intangible element.

Software: Tangible or Intangible?

Consider how a software product is different from hardware: software has no physical form (although disk space consumed could be a measure of size). It has no weight. Its quality is not directly observable. We can say a disk drive, for example, has low, medium, or high quality based solely on physical inspection. But we can't do this for software.

High quality software must be engineered. Because it is so intangible, and software development can ebb and flow like no other type of product, we have to insure our software meets some engineering ideal or model that allows measurement of tangible outputs from an intangible process.

Process Activities

In our needs assessment, we mentioned the benefits of being open with customers and capturing subjective ideas. We also mentioned the necessity of transforming those ideas into engineering requirements at some time. Well, now is that time! We will use the outputs of our needs assessment assignment as inputs to the requirements specification assignment. We then perform the following tasks:

• Define requirement characteristics: Identify the features of an engineering requirement: what it contains, how it is written, how we can measure it. It's not really circular logic, but before we specify requirements for our development project, we must specify requirements for a requirement!

• Develop a collection method or model: Determine how we capture requirements. We might do this with a simple tool, like a word processor. Or we may use something more complex, like a data base or spread sheet. Regardless of our method, we must use a uniform format for requirements capture or collection so that all requirements look the same.

• Transform needs into requirements: Once these two tasks are in place, we can change a statement of need derived from a customer into a specified requirement captured by our method or model. The result is customer needs are now stated in a common format or language, making it easier to perform analysis and engineering--which we will do in the next unit.

Exercise

The next step, the second sub phase of the requirements phase, is to translate the outputs from needs assessment into engineering requirements. Pay particular attention to the assignment requirements. Do the work requested well, but do not perform extra, needless work.

• Armenian
• English

Study Guides

Use the following study guides to focus concepts from the readings:

• Armenian
• English

Lecture Slides

Here are copies of the lecture slides presented during class:

• Armenian
• English

Readings

As before, each of the listed links will open in a new browser window:

Systems Home | Introduction | Needs Assessment | Requirements Specification | Requirements Analysis | Preliminary Design | Detailed Design | Implementation | Testing