December 05, 2012
Technology Solution Delivery

Making a List and Checking it Twice

With Thanksgiving in the rear-view mirror, the holiday season is in full swing.  The time has come to decorate the house, bake cookies and start thinking about all of the presents you want to give and receive.

For me, this is an exciting year, as this is the first year any of my kids are old enough to articulate what they want for Christmas.  So on the Sunday after Thanksgiving, Connor (my 2½ year old son) and I sat down, put pencil to paper and began to create his very first Christmas list, which we will then add to a brief letter to Santa addressed to the North Pole.  I kicked the conversation off by asking, “Connor, what is the first thing you want to ask Santa to bring you for Christmas?”   Without a moment’s hesitation he responded, “a bike”.   My brain immediately started translating his request onto paper. I began writing B-I-C-Y-C. Then it occurred to me, a 2½ year old might be too young to ride a bicycle.  So I asked him, “Connor, do you want a small bicycle with training wheels or do you want a big wheel?”  Connor’s next gesture was a cute, but universal sign of confusion. With his palms upward, he shrugged his shoulders and gave me a look of bewilderment.  It quickly occurred to me that while he knew exactly what to ask for, he wasn’t really sure what he wanted. It was at this point that I began to feel an eerie sense of familiarity.

I wasn’t going to let his uncertainty prevent me from creating this list, or prevent him from getting what he wanted for Christmas.  So I began to ask probing questions. “Do you want to sit close to the ground or high above the ground?” “Do you want one big wheel and two small wheels, or two big wheels and two small wheels for balance?”  As Connor began to answer my probing questions, I was not only able to get a better understanding of what it was Connor wanted for a present, but I was also able to isolate my feeling of Déjà vu.  It turns out that Connor’s first Christmas list was a case study in the exercise of Requirements Definition, and the value that the exercise brings.

What is Requirements Definition?

Requirements Definition is the art of taking a vision of a process, a product or a new technology and translating that vision into clearly defined components in order to solve a business problem.  Once you have a definition, you can break the requirements down further into the functional requirements that form the foundation of your final solution. In theory, requirements definition is a no brainer, but in practice it is a step in the Software Development Life Cycle (SDLC) that is rarely given the time or attention it deserves.  Well written requirements will form the foundation for all phases of a successful project, while poorly written requirements could force a project into an endless cycle of “finger pointing”, “blaming” and “he said, she said” culminating in a final product that does not meet the needs of the business or fully resolve the original business problem.

Good business requirements are:

  1. A collaborative effort that involves all the right organizational stakeholders
  2. Clearly written and understood by all parties who will use them to  take action
  3. Traceable throughout the lifecycle of a project
  4. The foundation of numerous key project deliverables throughout the SDLC
  5. Measured by how well the final product solves the originally defined business problem

Identifying the right resources to perform Business Analysis

The most important step in the requirements definition process is to ensure the individual(s) writing your business requirements have the necessary skills to create a deliverable that will become your project’s foundation.  At Kenway, our Business Analysis service offering adheres to three basic guidelines when helping our clients write requirements:

  1. Let your requirements define your solution, and you will always solve your business problem. If you let your solution define your requirements, there is merely a chance you will solve your business problem.
  2. Decent requirements depict what is requested; good requirements depict what is needed.
  3. Requirements can come from anyone, from anywhere and at any time, so always be looking and listening for them.

Tips for writing good requirements

The first step in writing good business requirements is ensuring that all necessary individuals and organizations are represented in the requirements definition process. This starts by considering all stakeholders who will touch or be impacted by the end solution. Too often, requirements definition is limited to the business stakeholders who have identified the problem that is being solved, or the individual(s) who can envision a solution.  Comprehensive business requirements include, but are not limited to, the front end users of the technology, the individuals who have a business problem being solved, the individuals who might benefit from reporting and/or data created by the new solution and those individuals responsible for integrating the solution with existing technologies.  Stakeholder identification for requirements definition also becomes an excellent starting point for your communication planning activities.

As you begin to document requirements, it is important to consider the perspectives of all stakeholders.  Well written business requirements become the foundation for system requirements, technical and functional design documentation and test scripts.  This means that there will be a number of individuals interpreting and taking action based on the requirements.  Since so many people will be consuming these requirements, it is important to be concise, yet thorough with each requirement, avoid acronyms or statements that can be left open for individual interpretation and avoid building or defining the solution in your business requirements.

Once business requirements have been completed, it is important to trace them throughout the software development lifecycle.  It is good practice to use a traceability matrix to guarantee that all requirements are satisfied in each phase of the project, up to and including the final solution. If a requirement is not met in subsequent phases or documented properly, it is crucial that key stakeholders accept that there may have been a change in scope or simply that the documents need to be edited to incorporate all of the in scope requirements.

Kenway believes that once a project is completed and the identified business problem has been resolved, business requirements become a good measure of the success or failure of a project.  If the delivered solution meets all of the documented, in-scope business requirements and solves the identified business problem, you can be confident that your business requirements satisfied their needs.

Much like requirements definition, the creation of Connor’s Christmas list took significantly longer than I had expected.  But when I looked back at the experience, I was proud of what we had accomplished.   More importantly, I was confident that on Christmas morning, Santa would deliver Connor the presents that he wanted and not what he requested.

How Can We Help?