While each project is different, there are several general guidelines to follow when creating a matrix of functional requirements.
At the core of any successful initiative is a thorough and objective assessment of the needs of the customer, buyer, or user. These needs are translated into a set of functional requirements that are the baseline for the process or software that you are improving. While each project is different, there are several general guidelines to follow when creating a matrix of functional requirements.
The functional requirement matrix example begins with format. Most often, a list of functional requirements will be constructed in some form of spreadsheet software, with Microsoft Excel being the most popular among everyday users. The advantage of a spreadsheet format is that each requirement can be given its own line and set of columnar data that describes it. For instance, you may be doing a project whereby you construct a building. Each identified requirement may be categorized by 1) the room of the building which it impacts, 2) the 'system' (electrical, plumbing, HVAC, etc.) to which it applies, or 3) an expected cost, based on past experience. These requirement definitions may apply to some or all of the requirements, and they may be dependent or independent of each other. A spreadsheet allows for efficient filtering and sub-categorization of needs.
A Functional Requirements Matrix Example
Requirements should be given a unique identifier of some sort. This may be a simple letter or number scheme (1,2,3 or A, B, C) or it can be an identifier that has unique meaning (RAK10292010a). Doing so enables all involved parties to reference a single field to ensure that they are referring to the same requirement.
Also, each need should have a person of responsibility assigned, typically the individual who came up with the requirement originally. This allows future users of the document to refer back to that person if there are questions about whether or not the requirement has been understood and properly met.
Requirements should simultaneously be detailed and brief. The aim here is to be as specific as necessary to ensure that any individual joining the project or reviewing its results will be able to determine without question whether or not the need has been met. A vague description such as "supports system" can mean so many things that it can be interpreted in different ways by different people, including project personnel. A better approach would be something like "can support adding up to 10 audit records to the package record each time a shipping-related events occurs." This is specific and measurable, easily understood by all readers. When considering your requirements descriptions, be sure to review your lists of project constraints and assumptions. Colors, deadlines, sizes, weights, and locations are all details that should be included in the requirements when possible. Remember, the more specific your requirements, the more likely you will get exactly what is needed.
Some requirements documents are simply a listing of detailed needs. To be more effective, however, it is best to stratify those needs. There are two ways to do this, and I like to use both together. First, give the requirement a numerical weighting that corresponds to its priority to the customer, buyer, or user (1, 2, 3 or 1, 5, 9). I like using the latter combination, and will explain why in a moment. There should also be a designation assigned by the vendor or individual using the matrix to demonstrate whether or not the need has been met. I like this to be a numerical value (1, 5, 9 to mean "no", "partially", and "completely"). The advantage of the numerical classification is that it can be multiplied by the weighted priority to give a concrete value of what has or will be met vs. those requirements that need more attention. Using 1, 5, 9 creates a larger gap between the met and the unmet requirements for all users to see.