The objective of the Seamus project is to build a requirements management system in Ruby. Seamus takes a document-centric approach to requirements – treating requirements as “content” to be managed within an Enterprise Content Management (ECM) system.
There are a couple of reasons for doing this and for doing it this way. Firstly I want to improve my Ruby skills – in my day job I work mostly in Rails and want to go a bit deeper into Ruby than website development typically requires. Building an ECM isn’t a trivial exercise – I’m not even confident I can do it, at least not on my own. Going through the process of building this system is going to teach me more about Ruby than I’m used to – as well as give me a chance to flex those architecture and design muscles that have atrophied over the past few years.
Secondly I want to build a requirements management tool that is useful to a broad set of stake holders. Most tools or systems I’ve seen for managing requirements tend to support the needs of one group of users over another – e.g. satisfy a business’s legal needs but fall short of guiding the day-to-day efforts of developers, or vice versa. The ECM will provide multiple representations of the same underlying content – allowing the same set of requirements to be used by different groups of people working on the same project.
There’s a third ancillary reason: to learn more about the process of requirements management. And a fourth “nice to have” – that building a specific-purpose ECM will lead to a system that can be repurposed for the management of other types of content. Neither of these are driving reasons for the project, but will be kept in mind as we go.
I’m in a bit of quandary over how to jump-start the project. In an earlier post I said I wasn’t going to start until I had a full set of requirements. I’m being guided by Karl Wiegers excellent More About Software Requirements, in which Karl suggests defining a baseline set of requirements and then engaging in a iterative process for further refining the needs of the project (he’s clearly not adverse to agile methodologies). Given I already have part of the problem domain laid out for me – in the structure of the CMIS data model – I’m inclined to lay down a very brief set of requirements and then use the model to explore how these requirements can be mapped into the ECM domain.
I plan on documenting what I do as much as possible, so I have a record of what mistakes I make – both in terms of technical choices and also the actual approach. I have to say, as a developer I’m just keen to start cutting some code.
