Both strengths and challenges were encountered when developing the requirements.
The development process revealed the following strengths:
|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.|
The key challenges were:
|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:
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:
|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.|