Requirements for a Requirements Tool – Top-Down or Bottom-Up?
Before thinking more about this topic, it also strikes me that are at least two well-known ways to structure this analysis: Top-Down, in terms of seeking a generalized model of Requirements Tool requirements, such as the ideas of Concept and Functions I have already described; or Bottom-Up, in terms of looking at specifically how Information Systems are built and operated in one’s own company.
Top-down may provide a more stable set of requirements applicable to many environments, but that wider applicability may be more than you need. Bottom-Up ensures we keep in mind the final product that one does requirements for, but could be too rooted in a company’s current technology and not as adaptable as technology changes. It’s a trade-off, like many things are, so I intend to keep both in mind as I work through my analysis.
- dwright's blog
- Login or register to post comments
- 943 reads
Constant Embellishment
If you've ever seen a (traditional e.g. Constable) painter paint a picture and see all the stages it goes through I think you can liken it to requirements elicitation and organization. I don’t think it's top down, bottom up or middle out. I think it's organizational planning, as input's are thought or and arrive they are constantly organized and associated and structured and re-organized (whether this be in a tool, on paper, on a white board, or just in someone head).
First we 'choose our paletted' : 'choose a methodology' with which to work, so we have a framework with which to work within.
Second we 'mark the white paper' : 'derive some initial statement' to get us off the mark so we are not overwhelmed with the vastness of a task,
Third we may 'make sketches' : 'brainstorm use case' to get some initial organization and plan for the work ahead. At the same time possibly destroying our initial markings.
Fourth we 'embellish the sketch' : 'define initial description of the use cases' adjusting the sketches as we fill in the overall colours and content constantly re-organizing as new information is applied.
Fifth we 'fill in detail' : 'work in one specific area' develop the high priority areas of the work adjusting our initial concepts as we go often organizing based on what resources are actually available.
We continue in this vein constantly organizing, reorganizing, re-planning and re-adjusting as we go.
This sounds very similar to more agile methodologies, wherin if we actually drive to results (code) and can adjust requirements accordingly we are likely to have better results. More formal top down methodologies either do not allow for constant adjustments and re-alignments or heavily frown upon them.
I don’t think this is top down, bottom up or middle out but I think it's what works successfully. We have to be prepared to adjust and collect input when and where it comes.