7.2 Requirements Document

   

A detailed description of what the customer wants, written in his or her own words, is generally called the Requirements Document or Specification. We can't emphasize enough how important this document is, and without it you'll not know what the project needs to achieve. Your project is finished either when you've met the customer's requirements or when your customer pulls the plug!

We can use an easy analogy here. Imagine you commission a builder to build you a house. He has built plenty of houses in the past, so all you need to do is give some loose requirements that you want the house to meet. You tell him or her you want a four-bedroom house with a garage. Off he or she goes and six months later he or she calls you to tell you that the house is ready. You arrive to view your new house, and what a shock . You wanted a two-story house; it's a single story. You wanted a double garage; the builder has built a single garage. You expected a full bathroom; the builder has put in a single shower room. This may seem a bit far- fetched , but just look at how many software projects are delivered, only then to find out that it is not what the customer wanted. The requirements document should mean everyone is aware of what is to be delivered.

A very high percentage of projects fail because of poor requirements gathering, and you will be put under pressure to accept loose requirements. Don't do it! Loose requirements are a big pain and can kill a project and your reputation. Finishing a project with poor requirements is a bit like chasing the end of the rainbow.

And here lies another fairy tale. The customer must write the requirements specification in its entirety before the project starts. Once written the requirements are not allowed to change. Therefore, when you start the project, the customer will have already written a full and detailed requirement specification for you. WRONG! What you will have to do is help gather the requirements. A customer cannot ask for requirements that he or she is not aware of, especially if there are related issues to some of the requirements the customer is asking for. Note the following statement:

"I know you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant ."

A Customer

We stated previously that the requirements would already be written. Where there is communication between parties in the software creation process there is scope for misinterpretation and confusion. Your program may be the most elegant, robust, and clever piece of software in existence, but if it isn't what the customer wants it's a waste of time and money.

Requirements gathering is the process of extracting requirements from your customer, and it is also a good initial opportunity for you to impress your customer and to start managing the customer's expectations. Even if the customer already has a comprehensive requirements document, don't believe it. Study it, probe, ask lots of questions, and gather the requirements that aren't mentioned.

There are plenty of studies that prove that poor understanding of a project leads to disaster, and that mistakes made at this stage are the most difficult and expensive to rectify.

The customer needs to have done at least some work up front; it would be ideal if the customer knew exactly what he or she wanted in great detail and had the ability to communicate this to you with no ambiguity. This is RARE! Conversely, your customer expects you to be able to translate the woolliest requirements into a concrete and precise interpretation (that's what he or she is paying for after all). Again, this happens often. The other problem is that customer and developer often speak a different language. These problems are reduced by LabVIEW but not eliminated.

The customer expects the following of the developer:

  • Understands what he or she has been told

  • Communicates his or her design ideas

  • Communicates any problems

  • Keeps to schedule

  • Keeps promises

  • Asks the right questions

  • Leads the project

The developer expects the following of the customer:

  • Knows what he or she wants

  • Communicates his or her requirements

  • Is aware of any pitfalls

  • Is consistent in stating views

Here are some important points to establish before attacking the problem.

Who is the Real Customer?

This is important because quite often you can be doing work for a customer representative who you think is the design authority, only to have his or her decisions overridden by the manager or another project engineer. If it's possible, get the design authority formalized ; it will save grief and finger-pointing later on. Sometimes the manager who has final approval isn't available until right at the end of the project. This is a recipe for a large amount of aggravation.

What Constraints Are There?

Constraints are often overlooked, but they are important and could again create all sorts of problems. Constraints are customer-enforced requirements such as operating system, language, speed, and so on.

How Do You Manage Expectations?

There are numerous myths surrounding software, which can lead to customers expecting more than they will receive. A disappointed customer won't be back! It's a good idea to offer up a few truths beforehand.

  • Software isn't easy.

  • Design up front is far less expensive than problem solving at the end.

So you've asked the right questions, and your customers are aware of potential pitfalls in the software process. Let's go gather requirements.

Before we start, a couple of quick points:

  • Gathering requirements well is not easy!

  • Any effort put in here is worth it.

Requirements gathering is all about problem evaluation; it is not about solution synthesis. You need to separate functionality from implementation, concentrating on the WHAT not the HOW.

Another good question is WHY. Question the requirements themselves . It's amazing how requirements can disappear into thin air when the person requesting the feature has to justify the reasoning behind it.

What is the Big Picture?

A basic approach to gathering requirements is that if you understand what the customer wants the software to achieve, you may be able to influence the design process rather than being influenced by the design process. You will also be in a stronger position when the customer changes his or her requirements.

You need to anticipate and identify these changes as much as possible. If you understand what the customer wants your software for, you'll be in a good position to comment intelligently and plan appropriately.

Another major aspect in gathering requirements is sorting out the MUSTS from the WANTS. Often projects fall way behind and costs skyrocket due to the bells and whistles that your average "techno sheep" like to munch on. "Techno sheep" was a term learned from a project manager; he used it to describe the difficulty in getting his programmers to stick to core problems on the project when all they wanted to do was wander around munching on the interesting bits. Identifying and satisfying the requirements that are pivotal to the problem domain are often key to perceived success.

This next point is probably the most difficult to manage. Don't always believe the customer's requirements. Sometimes the customer doesn't have a complete view of the problem and, therefore, may need to be led gently in the right direction. The only other way to manage this is to put flexibility in the system, which will allow for late requirements changes.

Identifying requirements that haven't been asked for is also extremely powerful. A customer once informed us that they wanted all the results in flat files; they would sort out the data later. Their decision was based on lack of knowledge of databases. They added the requirement when the pitfalls of not using a database and the power they would gain from using one were pointed out.

Another example is to make a system totally self-sufficient with respect to the network. You may have experienced systems that die if the network fails because they are using networked servers for information or storage. If the network dies the system stops, which could mean entire production lines coming to a halt. However, if we make the systems independent of the network this will never be the case. We can make them intelligent enough to recognize that the network has failed, so they can default to their own hard drives . This has huge payback, but we have never known a customer to ask for it, even though we have always persuaded them to do so.

It's hard for a customer to request something that the customer does not know exists. It's part of our job to offer requirements for consideration. Another thing to bear in mind is the fact that the only constant in software engineering is change.

If your project is a test system or it has hardware of some sort you're in luck. A test specification can act as a blueprint of sorts. Hardware usually has easily definable states and attributes, which again can be an advantage (keep an eye out for constraints though, and ask WHY).

Using LCOD has resulted in the identification of patterns in software; these patterns can be reused and can help in the formulation of questions to ask. They also allow prior knowledge from old projects to be applied to new projects.

For example, there are questions regarding the User Interface that will need discussing such as Data Handling, Reporting, Hardware, and Tests. All of these can be brought to the table and specific questions asked. You can apply a checklist to ensure that all likely areas have been covered. Do sketches of screens and reports . Identify the different actions and attributes required for the User Interface. Similarly, list all the actions and tests for the Hardware and Tests components .

In an ideal world enough information should come from these meetings to allow an accurate evaluation of system complexity, which will enable you to provide a decent quote. STOP!

We advise the provision of a prototype that allows the customer and users to get a hands-on feel of the system. You would be amazed at the amount of information that comes from doing this. LabVIEW and LCOD give you a huge advantage. You can rapidly provide a prototype that emulates the customer's requirements, and doing this doesn't compromise the software design. You can then sit down with your customer and modify it to his or her needs, usually on the spot (this generally impresses the customer a lot!). Finally, you can take this prototype and build your software from it. This is a technique that we employ for all but the simplest projects.

Another useful requirements gathering aid is writing the Instruction Manual and getting that approved first. We must confess that we have never used this, but it seems a logical idea and may be applicable to more complex systems.

As we have said before, requirements will change to a greater or lesser extent no matter how much time you have spent nailing them down. Be prepared to accept changes as the project moves on, and make sure the requirements document is kept up to date. This document could save you if it is pointed out that a requested feature is not in the software, because if it's not in the requirements then the customer has no argument. Of course, this also means it could be used to beat you over the head if a feature is not in the software but is in the requirements.

Do not accept changes without looking at the impact on your timescales. If the deadline cannot move then something has to give, like other features. The worst thing you can do is not have the requirements written in a formal document and all concerned agreed on them, even if they are changing (which they certainly will). If they are not written down then the requirements are completely fluid, and even worse , they are whatever the customer decides that day, hour , or minute.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net