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.”-Buddha
Now that we've got that "whoa...deep" mindset, let's begin!
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:
...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:
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:
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:
10 techniques for gathering requirements:
Requirements Gathering Essentials
Alright, next up we'll be talking about architecture. Hope to see you then!
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?