Feb
15
Requirements Modeling Techniques
February 15, 2007 |
Up through version 1.6 of the BABOK, we had piles and piles of requirements modeling techniques (I think I counted 21 in the last version).
Version 2.0 will have a radically different approach. I’m planning on having the following sections (subject to some change–for instance, Security Requirements may be treated seperately):
- Data/Entity Models
- Interaction Models
- Motivational Models
- Non-functional Requirements
- Process Models
- Scenarios and Use Cases
- State and Event Models
Some of those are headers in 1.6, but in 2.0, they will become the entire section. The goal is to focus on what a process is, and how you model one, and what you do with that model, rather than to worry about the detailed differences between a Activity Diagram, BPMN diagram, and a Flowchart. Sure, there are real and important differences between various modeling methods, but they only matter if you’re transitioning between two similar ones. If you’re doing that, you’re better off consulting books specifically on your new method, rather than the BABOK.
You may notice an oddity in the list above–I mention non-functional requirements but not functional requirements. The reason for that is that a functional requirement is a requirement that gets implemented in a software application, according to industry usage. It really speaks to the purpose of defining the requirement, rather than being inherent to the requirement itself.
This is true of non-functional requirements as well–but a process model may or may not be a functional requirement depending on what you plan to do with it, while the things that we call “non-functional requirements” are generally only defined when we plan to implement them in software. And yes, I’ve switched my personal position on the term non-functional requirement. I think it’s a terrible term, but it’s overwhelmingly the standard.
Comments
8 Comments so far
What I'm Reading- Communicating requirements to different stakeholdersBA Rocks!
- Product Management Reader: 13Nov08The Productologist
- Satisficing SprintsTyner Blain
- The Decline and Fall of AgileJames Shore
- Theory is Obsolete and other touchy topicsHerding Cats
- Agile Product Managers and Agile Product Owners Living Together in Harmonyenthiosys agile product management
- Rapid Results and the Big Systems ProjectProject X Discussions
- PMBOK, Agile and the need for TheoryHerding Cats
- A 5th element for the Agile ManifestoOn Product Management
- More on Agile Product Managers and Product OwnersScaling Software Agility
Could you explain in more detail your thoughts about functional and nonfunctional requirements. What are they, in your view?
The most popular view of functional requirements seems to be that they are what the system must do to carry out the steps in a process or use case. A less popular view is that a functional requirement is simply the functional goal that the process or use case achieves (irrespective of the individual steps in the use case).
I understand that the goal is to focus on what a process is, and how you model one, and what you do with that model, rather than to worry about the detailed differences between a models. However, if models are developed to identify gaps in requirements from stakeholders, perhaps as a BA community we should focus more on process by which the models are used to identify gaps in requirements. Furthermore, we might want to expand our sight to how we translate this knowledge to additional requirements. The breadth of requirement literature is scarce on this topic. They all suggest that it should be done, but little information is given concerning how it is done. Maybe this should be a topic for my next book…
Roger,
You answered your own question.
For the purpose of the BABOK, I”m constrained by “generally accepted” views and so have to go with the more common usage of the term. If you want my PERSONAL opinion, I actually think the distinctions aren’t useful except as a checklist to remind analysts of what they need to consider, and that we spend more time arguing over definitions than it’s worth.
Brian,
I agree that there’s a number of weaknesses in standard practice which we as a community have to address. The BABOK itself, unfortunately, can’t fix that–it needs to reflect that standard. Maybe if you write that book we can do something about it in a future editions.
Well, I didn’t really answer my own question, but you did. I wanted to know your personal view. Thanks for sharing your thoughts, even if it was just to question the value of quibbling over definitions.
I have a different view; I believe that uses of the terms are often internally inconsistent, and that the popular definitions reflect substantive and practical problems with the way many BAs and product managers document requirements.
Your question pretty much answered the “official” issue. On a personal level, I tend to side with people likeMichael Jackson in that I think:
a) framing the problem correctly is very important;
b) the distinction between requirements and design is not.
I suspect we agree on a, but not b.
I believe that understanding the distinction between requirements and design is strongly correlated to framing the problem correctly.
I.e., people who fail to understand the distinction between requirements and design tend not to appreciate the value of framing the problem correctly, and vice-versa.
Actually, what I think you’re trying to do is redefine “requirements” so that the word only applies to definitions of the problem space. That’s not the standard usage of the term, and from my perspective we already have a word for the problem, and don’t need to redefine “requirement”.
My personal preferred definition of requirement is Jackson’s: any effect within the application domain that the solution is supposed to create. I’d add to that that it includes any effect that is of concern to the stakeholders.
I’m interested in reading more of Jackson’s thoughts on requirements. Can you point me to some good material?
As for the definition of requirement you cited: it presumes a distinction between a requirement and a solution. Right?
If so, that is precisely that for which I am arguing - requirements that do not contain solutions. The only logically possible way for a requirement not to contain a solution is for it to do nothing more than restate the problem.
Or am I missing something?