Constraints

We should probably talk about constraints, and how they affect certain aspects of business analysis, namely requirements documents. The context of this discussion will be software application development.

A constraint is “a limitation or restriction.”

Typically, as a business analyst, there is a section of each document that is called “Constraints” and it has a list of items that the audience of the document needs to remember as they read it because they have a direct impact on the application that will be developed. This article is not about those constraints.

I do believe there are some constraints that get forgotten about, and those are the ones around the documents themselves.

In my opinion, which I invite you to counter, certain documents have constraints which are necessary to ensure that the document fulfills its purpose. As an example, a constraint of a requirements document is that it is not a “living” document. Design, by comparison, is a “living” document.



To further expand this example, when managing a software application, there will be multiple requirements documents – one for each release, with definite boundaries. The boundaries of the requirements document are tied to the scope of the release. There will be one design document, the boundary of which is the application in its entirety.

Standard naming conventions can add to the confusion around requirements vs. design, and how they relate to each other, simply because a requirements document is generally written for each release of the application, and a new version of the design document is created for each release of the application.

It ends up looking something like this:

Digging into the versions of the above documents a little more looks something like this:

The reason I bring this up is that my development team is constantly asking me to revise my requirements based on their design decisions. There are two problems with this scenario, the first is that I might be writing requirements that are crossing the line into design, and the second is that the requirements document becomes a living document.

The problem with having a living requirements document is that it is signed off and approved by the business, and every revision of a finalized requirement document requires a change request and business sign-off.

Requirements should be a guide for design, but should not cross the line into specifying design details. A fine line which I am still exploring with my development team.

Who asked me again today to update my requirements based on their design.

The answer, for anyone still wondering, is “No.”

...

or

"NOOOOOOOoooooooooooo"

(echoing off the walls)

... just in case a simple "No" didn't quite convey my sentiments clearly enough.

The impact that all of this has on testing will be explored in a future article. Included in that article will be an exploration of “How necessary is a Traceability Matrix?” and “Is testing a function of the business analyst?” The answer to the last question, I’m afraid, lies in whether you are certifying people as either business analysts or quality analysts, or paying people to do a job.