Requirement: Have a Plan. Check!

Ok, that sounds cheesy, but after thinking about the Arquillian posts I thought I’d better tell you where I’m going. As Eric Raymond wrote, many developers write software to “scratch” a “personal itch”. My itch causes me to write also, but not just software; i’ll blog about it as well.

I have several pet projects, and most actually connect in some way or other. A major itch I’ve felt over the past years has to do with the way we decide the functionality of a piece (or collection, if you like) of code: requirements.

Why Requirements Management?

If I look at the projects I’ve been involved with, Requirements Management per se only crops up in the really large ones. If you take small projects, the requirements are mostly expressed in the form of a functional design, and the project just targets implementing it. Even if we have a formalized Project Initiation Document (a PID), it will tend to express the project’s goal in the form of deliverables, stories (if we’re Agile), or one or more Functional Design (FD) documents. Requirements are never mentioned as such; instead, we talk about clarifying the story, removing ambiguity from an FD, or getting the scope clear. Determining the critical success factors tends to be part of the project, but if you propose to build a formal list of requirements, people frown and ask you why.

Why indeed? Aren’t we doing all right? We’re Agile, we listen to the customers, involve them in our development process, give regular updates on progress and demo the work-in-progress. Why bother with keeping long dull lists and have fruitless discussions about the wording and punctuation when we’re doing smallish projects? The time spent on that is better used on actual coding, right?

I think this is cutting the corner too tight. Numerous are the discussions we have, even for the smallest of jobs, where we have to refer back to the ‘greater picture’. Keep the project small because we don’t need to save the world. But we easily lose track of what is important for the context of our project. Granted, no need to drag in DOORS when we’re using left-over budget to add a single dialog to an existing application, but if you think about it, there will be one or two people on (or near) your project that will help you answer scoping questions from a helicopter view.

Bert’s Holistic Requirements Agency

So why do I think requirements are important? Basically, I think they’re underrated by most people, simply because they have too narrow a view on them. Take the different disciplines of architecture we have in IT, starting with the all-encompassing Enterprise kind; as e.g. TOGAF learns us, we have certain principles that guide us in how we implement an architecture. These principles provide a way to express what we think is important and the implications tell us how to apply them for specific undertakings. With TOGAF, we start with the Business Principles and the example set shown here, have “Maximize Benefit to the Enterprise” at the top. Ok, ok, it’s nr 2, but the first just establishes that the principles shall rule all. Anyway, this principle nr 2 voices a requirement, even if it isn’t called one.

If we go on and study Project Management, we get to the Project Objective Statement and Critical Success Factors. More requirements! Having these lists available for easy use and reference is surely beneficial. Sure, we have our senior developers to keep us on the straight path, but even the most informal projects are peppered with spreadsheets, action item or issue lists, and so on. If we can ensure that the amount of work involved with building and maintaining these lists is as small as possible, we can get rid of these informal lists and make them visible. We also get another benefit that should interest Agile teams: a history of countable things that can be linked to actual time spent implemented. Invaluable for getting better estimates, I’d say.


Well, I’d like to have an app for that. Allow me to quickly jot down clarifications, mark critical things to get right, expectations of project sponsors, and trace what I did to why I did it. I can do that with a spreadsheet, but hey, it’s a definite itch, so I’ll scratch it and write an app for it. Ok, that’s the plan. Just write an application to collect lists of things and relate them to each other. Now if it only stays that simple, that shouldn’t be too hard, right?

Well… I want to get my app to collect requirements for more than one project, so I need to be able to keep collections separate. There’ll be a hierarchy and relationships, so here come the metadata: I’ll want to record what kind of things I record, and how they relate to each other. The app can then give me a customized page to add information.

An inkblot of sorts

So, we need metadata about classes, attributes, relationships. Do I need security? Hell yes! Of course I’m going to let others use my app, so we’ll need users and roles. I’ve been doing some fun work with SAML 2 based Single Sign On. Is that a bridge too far? No, of course not. Read some things about JBoss PicketLink and that is rumored to work out-of-the-box. Cool, we’ll look into that. Could use that in the future. Going recursive a bit; JBoss out-of-the-box stuff tends to have lots of XML configuration files. I’m not too happy about that. Might dig a bit into the difficulties of writing my own Identity Provider.

Ok, back to the app. We got users and roles covered by JEE, but is that enough? Nah. Whatever kind of thing we have, it’ll get a state. Want to define transitions and roles required for performing one. Actually, I want to be able to protect groups of requirements. Give someone control over part of the hierarchy or maybe just a single one. Might be a nice bit to look at, could even add in a look at scripting by allowing an expression to decide if you’re allowed access. Maybe even resurrect my Modula-3 parser for it! 🙂

I wrote an application once for managing Web applications. Is that so much different? Nope, if I add screens to edit the metadata, I can get me a complete Configuration Management DB that would blow the socks off that previous thing. Cool. Then I want to use HTML 5 and JQuery. Lastly, let me add in something about the storage; I have PostgreSQL on my server, but perhaps I can use this to do something with a NoSQL database. Having received a book on the subject (thanks to the gracious folk at Trifork), my reading so far suggests MongoDB might be a good match here. Let’s see how that works out.

Ergo Conclusio

So, the plan is to learn about interesting technologies and blog about them, within the context of a Requirements Management Web Application. So expect me to blog about security, SSO, JBoss 7 security in particular, MongoDB, a dash of HTML JQuery, and anything else that bugs me while having fun. Hope you’ll like the result.

This entry was posted in Requirements Management, Software Engineering. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s