Often during system development we become very focused on making sure we meet all of the functional requirements for a system. Although functional requirements are indeed very important, they are not the only way a system will be evaluated by end users and business owners. If a user can indeed retrieve a credit card statement, but it takes five minutes to do so, the user will likely not be happy with the product.
Consider this example. In a book called “Angle of Attack” by Mike Gray he discusses the impact of requirements on the development effort to send the first man to the moon. He mentions two non-functional requirements that came from President John F. Kennedy. First, was that the astronauts were returned safely. (Seems reasonable to me. Who would volunteer to go if that weren’t a requirement?) Second, that the project would be completed within the current decade. Reading this book made me realize how a simple requirement like “during this decade” can change the entire scope and focus of the development effort. In this case, instead of going through normal system engineering practices and performing risk analysis, all of the development efforts were focused on finding a solution quickly through rapid trial and error. The entire process changed based on that single requirement. The requirement to bring the astronauts back safely resulted in a whole new project which involved getting the astronauts off the moon and back into the spaceship to return home.
I have my own example of the impact of non-functional requirements. When working on a weapon control system we had a reliability requirement. When we began looking at the reliability we needed to achieve we found the only way to achieve the required reliability was to add a second processor as a backup. It seemed like a reasonable thing to do. In the end it became a nightmare. The effort involved in backing up data and processes, and keeping track of the exact state at the time the processes and data were offloaded was very tricky. Testing this was a whole different problem. There were so many possible permutations of the situation that it was impossible to test them all. The effort required to support this single requirement was much more than any of us anticipated.
The more non-functional requirements there are in a system, the more expensive to both develop and test and the higher the risk. In particular the requirements that affect the entire system have the biggest impact on schedule and cost.
So what do we do with all of those non-functional requirements? It just isn’t feasible to just throw them out, of course. The best we can do is look at each non-functional requirement carefully. When users specify non-functional requirements ask them why this is important. Verify that the requirement is really necessary by understanding its importance to the end users. Verify that the pass/fail criteria are valid. In some cases users will say something like the system must be available 100% of the time without thinking about what they are saying so ask if this is a hard number or what the user would like to see.
When users state non-functional requirements like “user friendly” don’t just let that little requirement slide into your document without understanding what this means to the user. Ask how the user will test the system to determine it is user friendly. With the user, create criteria that can be used to determine if the requirement is met. Documenting these criteria up front with users will make sure everyone understands the intent of the requirement.
In short, make sure you know why the non-functional requirement is important to the user and how success will be measured. Getting this information up front will help you create a better solution.
By: Marcia Stinson
No comments:
Post a Comment