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.