Requirements gathering, possibly the most crucial step in software development, is often times the first “real” step a company takes in developing an application. That’s not to say that Scope Definition and problem analysis don’t happen. Its just that Requirements Gathering is often time considered the “kickoff” point from the perspective of most business users.  The goal of requirements gathering is to create a definitive description of exactly what the solution must do in order to resolve the business problem and be considered a success.   It is during this phase that we work most closely with the system users to derive these requirements. 

One reality about Requirements gathering that many don’t realize is that it is more likely that your business users and system owners don’t know their own business processes than it is that they do.   As surprising as that sounds it really isn’t bazaar,  many users are far too busy to analyze what they do plus get a strong understanding of how they fit into the organization as a hole.  And while system owners may have a strong high level understanding of what their business does, the minutia of the process that achieves that is often abstracted from them.

If this sounds like an uphill battle, that’s because it is. But if you assemble the right team,  excute the right tasks (often times over and over and over again), and diligently develop and manage the right artifacts;  then you can come out of requirements gathering with a solid foundation. Often times this leads to the requirements gathering team to have a better understanding of what the business does, then even the business users or the system owners do. 

The Team:

Project Manager:  The project manager acts mostly as a facilitator during requirements gathering, they will be working to get the right people together in the right room so that requirements can be acquired thru interviews, observation or other techniques.

 Business Analyst:  It is the responsibility of the Business Analyst to capture the requirements. They will work with the users to understand what they do, what they need, and how to put the system together to get them where they need to go.  Business Analysis is part art and part science and requires exceptional people skills as you help lift the fog surrounding what the system needs to do.

System Users:  System Users are the Business Analysts primary contact. The Business Analysts will meet with System Users as many times as it takes to get a solid and complete understanding of what is needed.

System Owners:  Often times there will be gaps in understanding between the various System Users; the System Owners are the best place to start to either fill these gaps or find out who will be filling these gaps. They are also an excellent “sanity” check. Its surprising how often one can hear “they do/want what?”  from a System Owner when a BA is explaining the process they have obtained thru their interaction with the  System Users.

The Tasks:

The tasks involved are really a cycle of specific tasks. Thinking of it like a mini process helps, below are the tasks involved in requirement gathering.

• <!--[if !supportLists]-->Requirements Identification – Learning of a requirement and defining it in as much detail as possible.
• <!--[if !supportLists]--><!--[endif]-->Prioritizing – Define how important the requirement as it relates to other requirements in the system
• <!--[if !supportLists]-->Project Impact – New requirement means a new project plan. Fit in the new requirement and evaluate its impact on the entire project.

<!--[if !supportLists]-->·         <!--[endif]-->Update documentation – Once we have a full understanding of the new requirement we have to serialize it into documentation. To do that we must update our requirements documents and models. These documents are how projects are defined and the center of communication. It is crucial that these documents stay as up to date as possible.

The Artifacts:

The artifacts are those documents that are the center of communication between the different members of the project team. The key is to make these documents as throe as possible, while making sure that all members of the team understand them.  There are many different types of artifacts that can be used, and it is best to view different types of artifacts like tools rather than items that must exists. After all the goal of these artifacts is for communication, if an artifact isn’t successful with your team, don’t waste cycles using it.

Example Artifacts:

• <!--[if !supportLists]-->Requirements document – A hallmark of this state. Often times these documents are hundreds of pages long and provide very detailed descriptions of each function of a solution. Sometimes this document is called the Functional Requirements document.
• <!--[if !supportLists]--><!--[endif]-->Business Process model – A series of workflows and state or status diagrams and descriptions that act as a high level overview of how the different requirements interact
• <!--[if !supportLists]-->Business Data Model – This document describes the data that the solution must capture and work with. It is often times that this document acts like a dictionary. Its description of different objects helps users understand what the other documents and models are describing.
• <!--[if !supportLists]-->Screen shots or UI Model – These documents work to help describe how screens will function. Often times they include descriptions of every field that will be viewed or edited on a screen along with mapping information to specific points in other documents like Requirements or models.
• <!--[if !supportLists]--> <!--[endif]-->Stories – Stories are used in Agile development and are like mini versions of all the above documents. The specifies of a story are much more laxed leaning more on the idea of the bear minimum to make a requirement understandable rather than a ridged and in-depth description.
• <!--[if !supportLists]--><!--[endif]-->Acceptance Testing document – Sometimes it is easier to describe a piece of functionality by describing the test that validates it. In these cases, writing a few tests cases early is worthwhile. After all, any project worth its weight in salt will have one of these anyways.
• <!--[if !supportLists]-->Use Case Models – These are often very high level graphical representations of requirements, defining all of the actors of the process and what the process will do.

References:

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design. New York: McGraw-Hill Irwin.

To analyze the current CMM level of an organization I would conduct a series of tests, interviews and sample for evidence. Based on the results of those I would be able to evaluate an organization’s CMM level with some level of accuracy.

Interviews: the goals of these interviews would be to evaluate both internal and external perceptions on what methodologies and tracking processes are in place for the organization.

-          An Executive that is not related to IT

-          A Business user not related to IT

-          Executive in charge of IT (could be a CIO or Director of IT)

-          Manager of Network Operations

-          Software Development Manager

-          Software Development Project Manager

-          Software Development Techical Lead

-          Software Developer

-          IT Support Desk Rep

Tests: The function of these tests will be to evaluate how competent the users are of their process. These tests may include further interviews asking specific questions about the organizations processes and comparing those to the documentation obtained. These test may also extend into watching users of the process actually enact tasks in the process.

Evidence: It’s one thing to talk the talk. But only with evidence can you prove that the organization is in fact using the process. Evidence will be asked for with little to no warning and will need to be pulled from the system with the evaluator present. The sample set for evidence to be pulled from will include all projects for the last 18 months plus at least 6 completed projects. We will be sampling for evidence that the software process is executed consistently and documented as such.  Evidence may include documents, emails, helpdesk tickets, reports derived from any in use Methodware, meeting notes and Groupware archives of scheduled meetings.

Evaluation: Once all of the data is received we would evaluate the results comparing interview notes, tests & evidence against the organizations published process. We would also compare the organizations published and actual process against industry best practices below is what we are looking for to reach a specific CMM level.

1)      Initial :

a.       The organization has completed at least one project and it has been deployed to production.

b.      The project includes at least basic documentation to validate that the application was requested and meet the business users needs

2)      Repeatable:

a.       The organization has demonstrated at least 60% of their projects use the same basic methodology.

b.      The organization has demonstrated that both the internal and external users are aware of the organizations endeded software development methodology and its general process as it affects them

c.       The organization has completed at least 3 projects that follow the accepted methodology with minimal deviation without documented explanations for deviation.

3)      Defined :

a.       Specific process documentation and or Methodware was delivered to the Review team at the beginning of the evaluation.

b.      The organization has demonstrated that all project have used the methodology since its approval date or documentation is provided with excepted explanations as to which projects deviated and why.

c.       At least 50% of all projects demonstrated execution of the documented process.

d.      All users of the process know where documentation is stored in the organizations systems and have a strong knowledge of its methods without referring to the documentation.

e.      The documented process has been in effect for at one quarter (3 months)

4)      Managed:

a.       The documented process has been in effect for at least 4 quarters (one year)

b.      Process evidence is primarly provided by a single system rather than a mixture of emails, meeting notes and other ancillary evidence.

c.       The organization has reports that demonstrate quantifiable details regarding a projects success or failure. This should include estimates vs. actual for man hours, cost, schedule, administrative overhead, defect tracking, customer feedback.

d.      All current projects are presented in the organizations tracking systems and are accurate to within a reporting period.

e.      At least 5 now complete projects used the tracking system from kickoff to completion of the project

f.        All users of the tracking system have logins to the system.

5)      Optimized:

a.       The documented process has been in effect for the entire sampling period

b.      Process evidence is provided solely from the organizations tracking system.

c.       Evidence is provided that the organizations process has been evaluated in accordance with IT policies.

d.      All users of the tracking system demonstrate consistent and repeated use of the system.

e.      The tracking system has enough data to provide baseline reports for comparison.

f.        The process includes a lessons learned and these are archived in the tracking system for every closed project

g.       Evidence is proved that lessons learned from all closed projects have feed into validate-able changes to the organizations processes (if applicable).

h.      Tracking System metrics & reports are ties to individual and organizational reviews not just process reviews.

Comparing the tests results to the above level qualifications would allow us to know which phase an organization is currently in and how close they are to the next phase of CMM.

So ya, I’ve been thru a few SOX audits (4 to be exact) so I am leaning a lot on how they test our IT department to make sure that we were meeting Sarbanes-Oxley controls as they relate to IT (and there are a surprising number of them that do!).

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design.New York: McGraw-Hill Irwin.