Tips for BAs: New Paper – What Are Requirements

2 Responses to Tips for BAs: New Paper – What Are Requirements

1. Faith Peterson says:

   March 17, 2009 at 1:47 pm

   Great paper, Geri. This is one of the most clear and concise presentations of this material I’ve seen. I’ve seen first-hand the importance of a meaningful requirements management strategy and requirements plan that accounts for these differences.
2. Willem Van Galen says:

   March 19, 2009 at 9:31 am

   Hi Geri:

   Thanks for the article and for soliciting feedback. I have only limited time available for that, so what follows is out of necessity just “shooting from the hip” rather than something more comprehensive. Nevertheless, I hope it is of some value.

   Regarding “We can look at a definition of requirement from some reliable source such as IEEE or IIBA. But that does not really solve the problem. It is in the practical application of the definition that we find our understanding varies from one stakeholder to another.” You seem to suggest there is a “problem” with the definitions of a requirement offered by these “reliable” sources, but you don’t demonstrate what that problem is. At minimum, you might want to quote those definitions and point out why you believe they pose a problem that needs to be solved. Moreover, what is your own definition of a requirement, such that it applies to the breadth of the requirements you deal with in this article?

   This article strikes me as essentially making the case that virtually everything we articulate during the software engineering process (from identifying the earliest business requirements to deploying the actual software) can be seen as some kind of requirement. In other words, you’re engaged in an exercise of abstracting to a requirements perspective the meaning of activities and deliverables that traditionally have been given more specific names (e.g., use case modeling, user interface design, object modeling, data modeling, gathering non-functional requirements, program design, etc.). In that light, it would be helpful, I believe, if you cross-reference the “abstract requirements” views to the corresponding “concrete deliverable” perspectives, so people can relate the two. It would also underline your point that we “make a fundamental mistake on a software project when we ask all stakeholders to work from the same form of the requirements”.

   Abstracting anything is only useful if the abstraction provides a means for expressing certain principles more easily or clearly than without the abstraction. I believe your abstraction that “everything is some kind of requirement” provides a great opportunity to express that we’re essentially dealing with a requirements hierarchy, where one or more “sub” requirements trace back to one or more “super” requirements (you’re dealing with this in at least one specific context on page 8 when you write you want to “make sure every requirement is being implemented somewhere”). To put it differently, we’re moving up and down a hierarchy of interlocking requirements where a “super” requirement is an “end” and the corresponding “sub” requirements are “means” towards that end. This is another way of describing Alistair Cockburn’s notion of a hierarchy of goals (see his book Writing Effective Use Cases, chapter 5) and would be one way to “show how the different kinds of requirements are related” (page 1 of your article).

   At the top of page 4 you write “until I feel comfortable that I have captured everything the business stakeholders know etc.”. Would an additional check be that those stakeholders also must “feel comfortable” that you “have captured everything” they “know etc.”?

   That’s all the time I have. Take care.

   Regards,

   Willem