Salman_Ahmed_asking_what_is_water

 

FR/NFR are further decomposed into High-Level Requirements or Specifications. “The system shall send electronic mail to agents” would be decomposed into:

-          The system shall allow the Post Office Protocol (POP) for sending e-mail.

-          The system shall allow the Post Office Protocol (POP) for receiving e-mail.

-          Etc…

 

Note that there is a separate specification for sending and receiving. Each requirement or specification should be able to stand on its own. This is to ensure two things:

 

a.       The requirement can be properly tested.

b.      The requirement can be modified individually in case it either cannot be met or is determined to be unnecessary.

 

As high level requirements are decomposed into functional requirements and specifications there is typically a hierarchical matrix created which allows each item to be traced back to its parent. For example:

 

 

This allows us to clearly trace FR 1.1.1 to FR 1.1 which is then traceable to BR 1. Using this technique ensures that all requirements can be traced back to the business need. These requirements are used to build test cases later in the systems life cycle.

 

The Optimality and Design Criterion Principles are foundational to this step and the next. It will most likely be determined at this point what the solution looks like. If the solution is determined prior to this point there is a greater chance of the design being driven by the capabilities of the solution instead of the desired capabilities of the design. In other words, we should not base our solutions on what we have already purchased.