28 January 2009
Object oriented requirements and iterative development
There appears to me to be a tension here between an object oriented approach to requirements definitions and breaking the parts into useful components. It won’t always rear it’s head, but it’s going to be lurking in the vacinity.
You may have a set of generic functions you want a sales website to provide. Examples may be “present products,” “make sale,” “take payment,” “produce order,” “fulfil order” and “produce reports.”
And say you have four products you sell which all require customisation at each leg of the process. They may be presented from different inventory systems, require different payment methods, or whatever.
How do you arrange your releases? Presumably the fastest way to get revenue flowing is to build the end to end process for one of the products.
Then how do you address the way the requirements are focused on functional requirements?
I don’t have the answers to this question. I do have a hunch, which suggests that you as the requirements manager need to put in the extra work to un-abstract the requirements (if you know what I mean) back into a pragmatic application of the system and process. I think this may mess with the BA concept of diving the requirements and solution cleanly.
What do you think?
Photoi by Dey, CC at Flickr