Day 1 :: The Idea… Gathering our Software Requirements Specification (SRS)

I want to build an application that can track my and potentially other’s professional experiences.

Every application is started by an idea. Someone, somewhere wants to do something with some device for some purpose. All these ambiguities need to be fleshed out at some point, and often this can be called the process of gathering requirements. There are some very formal methods of gathering requirements as well as documenting them in either human and/or machine readable formats. The rigor used will largely be dependant on your sponsor’s needs. If you’re your own sponsor, we all love the freedom and power of being our own sponsor, choose a method that works for you. For some help, consider checking out a veteran’s suggestion by reading Joel Spolsky’s blog post: “Painless Software Specifications Part 3 – But How…”. I would actually recommend all of Joel’s articles, but for a different view do continue…

As the sole benefactor of my project, I’m not going to write up any specifications, but I do intend to do some brainstorming and white boarding activities. Let us think about the goals of this application… Why would I need to track my professional experiences? I want to be able to reference experience for professional opportunities. I also want to be able to generate resumes easily by picking and choosing pertinent data and applying a format. Perhaps my relatives want to be nosey and keep an eye on my progress, they may not understand it, but at least they’ll see I’m doing something. Lastly, I want to show boat my development skills through the blogging and implementation of this project.

All of these reasons for wanting this application lead to one high level goal: Make available my experiences to potential employers, friends, and family.

What is the core of professional experiences? Experience is often measured in time at a particular job, but more accurately it is the projects you’ve worked on. Let us think about our experiences in the form of well defined projects. These projects are often sponsored by an employer at a particular job role, so we can think of jobs and employers as additional entities describing the projects I have worked on. During some of my projects I’ve even given presentations or published written works, perhaps some method of linking publications and presentation events to projects will be useful…

As you can see, I often start thinking at a very basic data level. This is almost concurrently working with what I’m envisioning user interfaces to be, as they are what drive the data requirements. This makes me think of two famous approaches to software architecture: top down, and bottom up. I cannot recall the original authors who coined these two strategies, but I can tell you both thought processes working together can give you an amazing visualization of how your software might work. I compare top down thinking to interface visualizations, sometimes called “Screens”, that you can draw up to show some how you want your software to look at snapshots in time. This type of visualization helps solidify the micro requirements to accomplish each screen given a set of actions to reach it. This is where the bottom up thinking comes in. What are the smallest components that will be needed to accomplish this high level task? How can we make these components into their own silo that can be reused and basically independent from the actual project. This reminds me of a quote from one of my Software Engineering professors, “I remember back when the debate over inline and component based software architectures where a hot topic, inline programing would allow for highly optimized systems very specific to their tasks, component based software would allow reuse and separation… component based software architecture won” (Mats Heimdal). Now, I am paraphrasing from memory so please do forgive any incorrectness, but the take away is: problem solved, build your software in components from the bottom up.

My top down visualizations are drawn primarily from my current website and the various resume’s I’ve tweaked through out the years. The data employers seem to be interested in has been documented in resume templates all over the interwebs. With this in mind as well as the experience and self documentation I have to capture about myself, I decided to do a little white board action.

Whiteboarding activity capturing some of the important data elements required for this application.

At this point I feel I’ve made some good progress. I’ve documented an initial database design, and thought through some of the goals and requirements of my newly minted software idea. I think a beer is in order, tomorrow I’ll spend some time fleshing out more of the project details.