Why is that requirement there?

Have you ever been working on a project and read a requirement and thought, “Why’s that there?” or “What’s that supposed to mean?” I know I have.

I’ve worked on Department of Defense and commercial programs and seen requirements that make me pause. I vividly recall working on one software consulting effort in the early days of the Customer Relationship Management business space.

At that time, I was working with an organization defining what a customer service agent’s screen would look like and how it would capture information critical to resolving customer interactions. We used to call these customer interactions “trouble tickets.”

This particular project happened as the Windows operating system was becoming an industry standard. The lead systems engineer on the project took issue with the automatic generation of the customer interaction number by our application, asserting that he needed to be able to format the number based on the specific case.

I asked him why the number was such a critical feature. He explained that the number—when properly formatted—provided users with all the critical information.

Trouble ticket numbers looked something like this: XXXXYYYYZZMMYYAAA. (I was glad I didn’t have to memorize all of this data.)

I asked the systems engineer how long it took for new agents to become fully trained and able to work independently. He said the learning curve was something around three to six months because they had to memorize quite a bit of information to be able to effectively help the customer. I then asked how the code became a requirement. My systems engineer said the command line systems they were replacing presented that number as the database key, and that without that number they could not resolve problems.

I then showed him the Windows-based software we were planning to install. I started off with an initial contact screen containing a mix of text entry, a multi-layered/dependent pull-down value, and subordinate screens containing conditional data. On this screen, the trouble ticket number was simply a sequential number where all of the formerly cryptic data was now presented in plain, readable text. The systems engineer, after seeing the new, simpler way of doing business, said, “Yeah, this will work.” When I asked how long it would now take for a new agent to become productive using the new screens, he said, “days.”

On a recent Department of Defense project I worked on, a legacy technology that was rapidly becoming obsolete was being replaced by a current technology. Both technologies involved sensitive electronics and extremely short response times in order for the electronics to change from one state to another. The older system had quite a few requirements specifying pre-conditioning circuitry. The current team didn’t understand why those requirements existed, so during the development of the new technology design, the team assumed the pre-conditioning circuitry was a by-product of really old technology, and removed it from the design.

As you might have guessed, the preconditioning circuit was important to both technologies, as it was critical to generating the signal of the exact waveform required for the system to meet systems performance requirements.

A word here. Please don’t mistake my discussion above as criticism of the people involved. My objective is simply to point out that, in one case, the situation contained requirements carried over needlessly from an old to a new project, and in the second, a critical requirement was omitted in the new design. In neither case were the design teams incompetent. What I mean to convey is the importance of understanding not just what the requirement explicitly says, but also why it exists.

As systems engineers, we need to understand both of these scenarios and avoid jumping to conclusions without performing the requirements analysis. We should also be aggressive in our challenges to the all-too-frequent response, “Well, that’s the way we always do it.” There may be a reason, or a constraint that drove a designer to do things a certain way. As systems engineers, we need to understand whether that condition still applies, and if not, show the willingness to make that change.

As an aside, we now live in an age where we need to be able to change what we do and how we do it in extremely short periods of time. I’ve spoken to a number of people in the Department of Defense who describe mission engineering scenarios where stakeholders say what they want a system to do without regard to how the system will do it. The how is our job as system design engineers and architects. In order to be able to meet aggressive times to deployment, we can’t repeat the sins of the past and disassociate the design from the decision journey we have made. We need to capture the design and the journey, and these both need to be tightly coupled so those who follow us don’t repeat the errors we have made.

So why is that requirement there? I suggest we find out.

Happy engineering!