Challenges and Strengths

Both strengths and challenges were encountered when developing the requirements.

Strengths

The development process revealed the following strengths:

Strength Description
Broad experience The people providing input into the requirements cover a broad base in experience and work function, and their contributions and insights were invaluable for defining what the system should do.
Interest and motivation Participants were interested and motivated, and their engagement added energy and momentum to carrying out this complex task.

Challenges

The key challenges were:

Challenge Description
What level of requirements, in both depth and breadth, are needed before the project team can proceed to design?

Breadth – The project team has taken the view that requirements should address people, organizations, software, and hardware. This is an alternative to the view that requirements should focus mainly on software. Many of the requirements are based on an assumption that the largest challenges of ICM are not in the software but in the successful integration of people and processes. Many essential requirements would be missed if they were to include only software elements.

Depth – It is believed that requirements should be specified to the level that identifies and resolves significant differences in opinion or belief, particularly before design of the proposed system is initiated, where we would prefer not to discover fundamental differences between our stakeholders.  One of the purposes of requirements-gathering is to ensure that the project team has educated personnel on ICM and arrives at real agreement.  This can require in-depth discussions on who or what will perform a function.
What is the difference between a requirement, a design constraint, and a design decision? A traditional answer is that requirements define what the system must do to meet the user needs, design constraints limit the possible implementation methods, and design decisions determine how to implement the requirements.  In practice, it can be difficult to distinguish between a low-level requirement, a design constraint, and a high-level design decision. By its definition, a requirement is something that a person believes is required for the system to function correctly. One person’s beliefs are frequently different from another’s and often related to how a function will be implemented.  For example, if an ICM requirement is to improve traffic in a corridor during an incident:
  1. One person may state that maintenance is required in order to ensure that traffic control elements function during a response to an incident. Another may state that whoever designs the solution must determine if maintenance is important in improving traffic conditions.
  2. One person may state that communication between first responders is needed to manage traffic, while another may state that who communicates information is a design decision related to how information is obtained.
  3. One person may state that a decision support system should model traffic. Another may state that the DSS must only ensure that the best response plan is chosen.

So how do we determine what is a requirement and what should be left as a design decision? We have chosen to apply the following rule: If a specific item that could reasonably be considered a design decision was mentioned by more than one person, this item was then listed as a potential requirement.
Missing requirements Several areas where requirements were missing were identified throughout the gathering process.  To address these missing elements, the following actions were taken:
  1. If, when looking across the process flows we discussed in the user meetings, we saw a missing piece that was at the same level as other requirements, we included it as a requirement.
  2. If a requirement was so high-level that we didn’t know how or who we may ask to implement it, then we broke it down into smaller requirements.
  3. As we brought together source material from different areas, we noted that we did not discuss certain items in our interviews. We used judgment in adding in requirements from other sources.
Unfamiliarity with the ICM concept The concept of ICM is new to many people who were being asked to provide requirements. As such, they looked to us to help define the requirements. We have used our own experiences combined with previous efforts and the opinions of experts to help guide us.