Salman_Ahmed_asking_what_is_water

 

There are many ways to generate Functional Requirements (FR). One of my preferred methods is to start with a Mind Map or Structured Hierarchy. This artifact, which we introduced to illustrate the Principle of Subproblems, allows us to identify the problems and subproblems that we need solve in order to satisfy the business need. This specific example is from our On-Premise Private Cloud Proof of Concept (POC). Our Operational Need in this instance was to enhance the provisioning of servers in the Data Center. The information derived from that artifact is then used to document and track the requirements.

 

Remember the example provided last week of our Business Requirement (BR):

 

“We need to be able to send a message to individual agents”

 

This is a pretty generic, but powerful, requirement. The next step in the process is to decompose  this into Functional and Non-Functional Requirements (FR/NFR) . This is where the design starts to take shape. Continuing with the messaging BR, a possible decomposition of this BR would be that:

-          The system shall send electronic mail to agents

-          The system shall send SMS text messages to agents

-          The system shall send Voice messages to agents

-          The system shall identify agents individually

-          The system shall identify agents by agency

-          The system shall allow individuals to be associated with multiple agencies…

 

And so on until all of the use cases have been satisfied.

 

Non-functional requirements are typically somewhat generic and geared toward the “ilities” of a system. Reliability, Quality, Availability, etc… These tend to be the same from one system to another with varying degrees of implementation (e.g., 99% vs. 99.999% availability). Chuck Weindorf developed a suite of NFR which are systematically being applied to systems as time and/or needs arise.

 

The output of this step is the Requirements Document (or Requirements Traceability and Verification Matrix (RTVM) ) which will be updated throughout the process. A common form is a spreadsheet like our example and/or textual document. Mature organizations will typically have a vendor provided requirements management tool (Doors, Caliber RM, …) which makes the traceability much easier. (If you look closely you can find some mistakes in our traceability example which I had not noticed until I started writing this blog installment, these kinds of mistakes can be avoided by using a better tool). The Requirements Document can be split up into FR and NFR or combined into one document depending on the system’s needs. When we get into the Test step discussion we will see how this document can be used during testing to ensure all of our business requirements are being met.

 

The FR in this example are the items with an “Assoc ID” in the form of X.x, where X is the BR and x is the FR in order of appearance. I’ve worked with some analysts that like to use the ”x” to represent priority also but find that causes issues if the priority changes later in the process.

 

It is very common at this step to generate a conceptual solution design including high level component and logical network diagrams describing the interfaces to and from the proposed design. If a reference architecture exists the components can be associated with it to make sure nothing has been left out.