May
1
Requirements Types: The 3PI Metamodel
May 1, 2006 |
What follows probably won’t end up as part of the BA BoK. I think it’s good and helpful material, but the problem is that it springs out of my own head and so fails the “generally accepted” test.
There’s no truly useful way to categorize requirements at present, from the perspective of a BA. At one extreme, authors pick out a set of techniques that they like and assert that those techniques, when applied, will generate requirements. At the other extreme, we get a definition and the traditional division between functional/non-functional requirements.
Neither approach really gives a BA the ability to know whether they know enough techniques, or whether the techniques used provide a full coverage. I’ve been thinking about this for a while, and I believe I’ve got the outlines of a useful metamodel for requirements–at least, for business systems. Right now, I call this the 3PI Metamodel. It breaks requirements down into 6 types: People, Process, Policy, Implementation, Information, and Interaction.
People requirements are in many ways the simplest. They’re user profiles in one form or another. Any technique that helps us identify or describe stakeholders in our projects falls into this category. Once we know who will be affected by our solution, what they need it to do, and what they want from it beyond their needs, we have our People requirements.
Process requirements describe how work gets done across the enterprise. They show how individual tasks performed by different people flow into one another to accomplish an enterprise goal. Process requirements can be described with flowcharts, activity diagrams, state machine diagrams, workflow models, and more. (Like I said, this is for BAs–there are lots of domains for which process requirements mean nothing).
Policy requirements also describe organizational goals, but in a timeless fashion. Where a process requirement talks about how to get from A to B, a policy requirement tells us what A and B look like. The most popular way to express policy requirements is through business rules. Other ways of stating these requirements include the CRUD matrix and metadata definitions.
Implementation requirements are typically the last to be developed. This is because they describe how a proposed solution will be made into a reality, and what capabilities the new solution must have to manage old information. BAs are almost never working in a vacuum these days; 95% of business projects replace some existing process and must allow for the transfer of existing data.
Information requirements describe the things the system “knows” about and what the system knows in terms of data and relationships between things. This may be as simple as a data dictionary or as complex as a entity-relationship or analysis class diagram.
Finally, Interaction requirements describe how the solution interacts with each of the stakeholders from the perspective of that stakeholder. Interaction requirements include UI designs, reports, etc. In other words, the inputs and outputs that each person sees.
From this list, it’s easy to see why use cases are such a popular requirements analysis technique: they can express People, Process, Policy, and Interaction requirements (although they do Process and Interaction requirements best).
I’m far from sure that this model is perfect. However, I think it captures something that BAs have been needing for a while, which is why I’m trying to get it out there.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog