Replies

I1nd if I rant? I am not normally one to vent…4744444444444444444444444444444Just getting over a insidious cold. It seems it only got worse over the holiday weekend. I ended up not driving to see virtual family in Chicago because of it. It finally broke over night so back to work for me… Ug. This requirements document is the worst I have ever seen. How do you tell your boss that the requirements he wrote are a steaming pile of… argh… For those that don’t know (or probably care) what and engineering requirement is, it is a contractual statement of what a system is or does. They MUST be unambiguous and verifiable. You can’t have several people read it and think it means different things or you WILL get in to trouble later when your costumer wanted something different than what you built. They have to be verifiable or you will never be able to prove you did what you were paid to do or built what they ordered. Imagine a statement that says “The Plane shall have maximum fuel efficiency.” How do you ever know that you built ‘maximum’. There is no such thing as maximum since you can ALWAYS squeeze in some infinitesimal more. So that is a BAD requirement. It should read the, “The Plane shall get no less than XYZ fuel efficiency over a fight as outlines in table # PDQ). That is a verifiable statement. You can run a test and prove that if the plane flies as specified in table PDQ then it at least XYZ efficiency. Now you have a statement that lets you get somewhere. Also requirements should NOT be to specific. You don’t want to write in constraints that lower level engineers have to follow except in extreme instances. THAT is hard to do. Imagine the statement, “The car shall have 4 wheels.” Why do you want 4 wheels? What other thing dictates 4? That the car might tip over in a turn? But what if an engineer invents something that makes a car stable on 2 wheels? Do you STILL want to require 4? Maybe not. So the REAL requirement might be that they car will be at least XYZ stable in a turn. It is not easy to write these things. One of the tools we use is standardized wording. A good requirement is written like “Something Shall blah blah blah when .” Standardized wording prevents a whole lot of misunderstanding. Another thing you do is keep them as simple as you can. You don’t want to cram several unrelated things into on requirement. Also you don’t want to cram several levels of detail in one requirement. Requirements are written as a pyramid. At the top of a requirements tree for a microwave you might have “the microwave shall have a user interface system that gives information the user on current operations”. At the next level down you might say “The user interface system shall consist of a keypad and display” and the level below that might talk about how the display shows time remaining. All of those requirements are ‘linked’ to the ones above. This forms a pile of layers starting at the top talking of broad terms about the entire system and moving down each level breaking the system in to smaller and smaller subsystems. Below the bottom lay of requirements you have the ‘design’ which dictates the specifics of what you are going to build. Each layer must be internally consistent and all written at the same level. You would not want to talk about how the buttons beep at the highest level unless the customer had already specified that the buttons MUST beep when you push them. Technically that is a low level requirement (should be on a lower layer) but in the real world you often get low level details passed directly from the highest levels. These should be the exception however and not the rule. So, all this explaining leads to my current document. Whoever wrote this (in part my boss) did ALL of that wrong. They did NOT use standard wording. They crammed several levels of details into all the higher level requirements. The paragraphs of text and called them single requirements and specified all kinds of design details at the top level. To top it all of none of these things are clearly verifiable. If they were just poorly worded they might be fixable but this whole damn thing is fundamentally screwed. Whoever conceived of them had a horribly flawed view of what they were doing. It is no wonder that the program the originally came from flopped big time. Now I get stuck trying to deal with stale leftovers of really bad cooking. Weeee fun fun.