Most Requirements Aren’t

To my ultimate embarrassment, we’re still largely a waterfall development organization. So, I read a lot of requirement definitions, and I’ve come to conclude that there are three types:

1 Requirements that are actually necessary for the product’s success. There is probably a relationship between these and the minimum viable product, but that is another post.

2 Requirements that are desired by someone, but not actually necessary.

3.Prescriptive requirements that define how something should be done rather than what should be done.

 

Now everyone knows (with the apparent exception of our business analysts) that the third type has no business being stated as a requirement.  Personally, I knew this early on from having it beaten into me by someone who had had it beaten into him in the early days of his career. It was part of the oral tradition of software development.  Maybe it had something to do with job protection.

It turns out that it actually has nothing to do with job security and there are at least two good reasons why proscriptive requirements are dangerous: one for each of the major audience groups — developers and testers.  For developers, a prescriptive requirement says “You must implement it this way.”  Even if the developer can see a better way, they must still implement the lame design that has been defined and signed off.  Moreover, the proscribed design is difficult to iterate, and we all know that your first idea is rarely the best one.

The best design comes from working through all the scenarios.  We used to think we could do this on paper, but the reality is there is always an unanticipated scenario that turns the design on its head. Test Driven Development and Refactoring are as much an acknowledgement of this reality as they are of changing requirements.  What’s the developer to do if they still have to satisfy the original design requirement?  That’s right, they hack it, and we take on technical debt.

For testers, prescriptive requirements are impossible to test.  How can you tell how something was built without looking deep inside and verifying that it works that way?  At best, they can have the developer place an inspection point in the process somewhere to verify that certain steps comply with the requirements, but why are they doing that?

Last year, we completed a project with a strong prescriptive requirement: files received in one region would be combined into a single file and sent to another region where they would be burst and fed into a processing system.  Not only did the requirements document state that this would happen, but it also defined the format of the combined text file!  The intent was to satisfy a non-functional requirement that 100% of the received files be fed into the processing system.  There was a huge review team for this requirements document, most of whom could not have understood the implications of one design choice or another with regard to this file, and the developers were forced to take on an inefficient design for the non-functional requirement.   The testers were able to verify that the stated requirement was met by inspecting the file; interestingly they never did verify the actual non-functional requirement, because it was never stated.  Altogether, the amount of time wasted by the business, analysts and testers reviewing what should have been implementation details is truly staggering.

Fortunately, while the developers had to create this huge text file, they had tools on the AS400 that make text file manipulation a doddle.  Unfortunately, we were already planning to shut down the AS400.  The result?  We may need to rewrite this component that combines the files (depending on the order in which a few things fall).  If we do indeed rewrite it, we will have incurred 100% interest on the technical debt in one year.  Awesome.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: