The Skinny

Your one-stop shop for an intro to all things dev that I can cover. Go ahead-get in on the conversation

An Introduction to ALM- The Series, Part 1-Gathering Requirements

An Introduction to ALM- The Series, Part 1-Gathering Requirements

Rate This
  • Comments 1

Hello everyone, and welcome to the first part of our ALM Series! If you're just joining in on this series and you want to know more about ALM, check out my introduction post here. Let's go ahead and get started with  the first phase of ALM.

But first, a strategically placed philosophical quote to provoke thoughts on the following content:

An idea that is developed and put into action is more important than an
idea that exists only as an idea.

Now that we've got that "whoa...deep" mindset, let's begin!

Gathering Requirements

Computers are a wonderful thing. They have given mankind the ability to advance in many fields: science, entertainment, education, productivity, the list goes on and on. However, these miraclulous technologies didn't create themselves; they began as an idea.

It could be someone's bright idea to make connecting with the people you love easier, or it could be a necessary tool within an enterprise to help the business meet their objectives on time. Either you, your business owners, customers, etc. come up with the initial idea. While having that first stroke of genius is a great motivation to get coding, that's almost always never enough-the devil's in the details, and this is especially true when you're figuing out what your application is going to do.

At the start of the Application Lifecycle, we do just that- figure out just what it is our new little app is going to do and really understanding what our end users want out of it. Gathering Requirements, or any other synonym out there for this phase or group of phases, boils down to understanding what it is that we want our applicaiton to do, and usually writing it down in some sort of official document.  How we go about getting these requirements depends on method to method, but there are some general steps.

First off, you find out more about what your app should do. You can get that information in a lot of different ways:

  • Brainstorm with yourself, friends, or teammates
  • Meet with the business group or with customers to get their requirements for the application
  • Try out or read documentation on an application that does something similar to what you want to develop
  • Send out surveys or questionnaires to company employees or other similar groups of people
  • Speak to experts that may know something about what you're trying to accomplish with your app
  • Policies that your application may need to uphold to be compliant
  • Look into a crystal ball and read the minds of your end users
  • Etc.

...ok so maybe the second to last one is a bit unrealistic, but I'm sure you'll find yourself at some point wishing it was possible-if you haven't already :).

But you can pretty much understand how this works-since gathering requirements sits in the Governance aspect of ALM as Chappell described (go here to understand what he's talking about), it makes sense that we're constantly keeping up communication with others in this phase.

Regardless of how you get your information, you need to keep a few things in mind:

  • Look for requirements or needs that a lot of people have in common or are frequent. While you can't make everybody absolutely happy, hitting those basic desires or necessities is important to satisfy the general population.
  • It should make sense to you what it is that people are looking for; you don't have to agree, but you should understand what they want well enough to relay it back to them or to someone else.
  • If it seems vague or general to you what it is that people are looking for, still note it down; you'll be focused on clearing the fog in the next step.

Once you've got a good list of things your application should do, you write them down. Now here's the tricky part: how you write down your requirements is crucial to the success of your application. Here's some best practices:

  • Make the requirements clear and understandable. If you don't, you may wind up having coded something fantastic, fast, and snazzy-that nobody will ever use because they find it pointless. Ouch.
  • Your requirements should be doable. While it's great and all to list out all the awesome things you want your app to do, don't forget; you or your team is the one writing it. Don't try to turn lead to gold, or make everyone happy; set the expectation with yourself, your team and your end users/stakeholders what is possible with the time, tools and budget given to you. 

If this is your first time doing something like this, don't sweat it if you don't get it right-just keep up constant communication with the people around you to make sure you're getting what it is people want-ask others if it makes sense-repeat back to your business group what it is they want to make sure you get it, and don't be afraid to ask questions to be clear. While it may be tedious work now, I deeply assure you it will pay off in the long run!

I'd like to leave you with some links that describe this phase of ALM a little better, as well as some tips for getting requirements:

Wiki Page:

10 techniques for gathering requirements:

Requirements Gathering Essentials


Alright, next up we'll be talking about architecture. Hope to see you then!


Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post
  • Our requirements docs are 50-65 page word documents that are extensive and heavy on the use of formulas and formatting, pictures are great....but in complex financial applications you need to be explicit with text and calculations in the requirements. Will you finally be able to capture requirements in Word like DOORS and have them integrated seamlessly into TFS?

Page 1 of 1 (1 items)