Lenny Roberts has been the MIS Director for the Seattle Fire Department for the last 17 years. He’s been involved with IT roles in Seattle for over 25 years. He has seen a lot. I interviewed Lenny recently and we talked about a number of things. I wanted to share some of that conversation with you around the role of the IT department.
Lenny says the role of the IT department in any IT or software project is “to be a consultant and advisor” to the operations people. He is very clear that operational needs should drive the solution and operational people should define the needs.
“Before you write a check”, Lenny added, “make sure the end user has confidence in the solution and buys into it.” Lenny says you should let people beat the tar out of it before you write the check, because that is what they will do the day it goes in. Lenny is a wise man.
Any IT project will include requirements. The following are general characteristics of good software requirements statements (from processimpact.com). This might be helpful if you are not familiar with developing software requirements statements for a project.
Characteristics of Quality Software Requirement Statements
Correct. Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could itself be incorrect).
Only user representatives can determine the correctness of user requirements, which is why it is essential to include them, or their close surrogates, in inspections of the requirements. Requirements inspections that do not involve users can lead to developers saying, "That doesn’t make sense. This is probably what they meant." This is also known as "guessing."
Feasible. It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other tradeoffs.
Necessary. Each requirement should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard. Another way to think of "necessary" is that each requirement originated from a source you recognize as having the authority to specify requirements. Trace each requirement back to its origin, such as a use case, system requirement, regulation, or some other voice-of-the-customer input. If you cannot identify the origin, perhaps the requirement is an example of "gold plating" and is not really necessary.
Prioritized. Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation.
There are three levels of priority. High priority means the requirement must be incorporated in the next product release. Medium priority means the requirement is necessary but it can be deferred to a later release if necessary. Low priority means it would be nice to have, but we realize it might have to be dropped if we have insufficient time or resources.
Unambiguous. The reader of a requirement statement should be able to draw only one interpretation of it. Also, multiple readers of a requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective words like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Words that are clear to the SRS author may not be clear to readers. Write each requirement in succinct, simple, straightforward language of the user domain, not in computerese. Effective ways to reveal ambiguity include formal inspections of the requirements specifications, writing test cases from requirements, and creating user scenarios that illustrate the expected behavior of a specific portion of the product.
Verifiable. See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether it was correctly implemented is a matter of opinion. Requirements that are not consistent, feasible, or unambiguous also are not verifiable. Any requirement that says the product shall "support" something is not verifiable.
Regards,
Bob
Leave a comment
Latest Blog Posts 
Does social media monitoring belong in Planning or PIO?Darwin pretty much proved it - life evolves. All things change over time, relentlessly moving forward, adapting to new environments and new circumstances. Except fire departments. The fire service is two hundred years of tradition, unhampered by progress. A friend of mine once said that the biggest changes in the fire service have been the internal combustion engine, radios, and women in the fire service. Too many fire departments are content to stand still, to resist change, to stay in their caves to keep using the clubs they have become so fond of. I was in the fire service and I've seen this.
The fire departments that will survive the current economic squeeze will be the ones that seek new and innovative solutions to the problems they face and will seek fundamental change in how they do business. They will use technology to support their operational mission and use it in new and innovative ways. Everyone else in public safety is moving forward. The theory of relativity says that if you are standing still and everything else is moving forward past you, then from the perspective of the people moving forward, you look like you are going backwards.
Here are a few key areas where fire departments could move forward:
- Performance measurement and management.
- Situational awareness and common operating picture for daily use.
- Multi-agency information sharing (FD, PD, utilities, power, transportation)
- Interoperable and integrated communications.
Now is the time for fire departments to step up to the challenge, to change for the better, to explore strange new technologies, to seek out new solutions and new services, to boldly go where no fire department has gone before.
Leave a comment
Knowing what issues your colleagues are facing can be helpful, or at least interesting. I have set up a short survey of the top 5 technology related issues you face. Please complete the anonymous survey here and I will share the results in a future post.
Regards,
Bob
Leave a comment
It seems that every discussion of major disasters eventually turns to the problem of critical infrastructure being down. Networks go offline, cell phones won’t work, how will we communicate? AT&T has just announced a new solution - a cell site in a box. The Remote Mobility Zone is a portable cell tower about the size of a suitcase. They have another option that can mount into a vehicle.
According to the AT&T web site:
“Whether they are part of the federal, state, or local government, or part of law enforcement or homeland security, first responders can benefit from the highly portable aspect of AT&T Remote Mobility Zone and deploy it as part of their first-line response team. AT&T Remote Mobility Zone can be installed on the roof of a command vehicle, or deployed on the ground, in a matter of minutes.”
More at the AT&T site here.
How about this - add a radio interoperability solution that can turn every cell phone or computer into a radio and let every cell phone, radio (no mater the type or frequency), land line, and computer all talk to each other and you are in business. Later this week I’ll have an interview with a company that can do that. Stay tuned.
Leave a comment
Latest Emergency Management News
Experts in emergency management say Albert Ashwood’s long experience and innovative thinking have helped ease those recoveries.
Students at the Oklahoma State University Department of Mechanical and Aerospace Engineering designed preliminary storm drones that could someday gather data that saves lives.
The test program equips SWAT officers with computers and cameras so when out in the field, trauma surgeons can help them respond to critical injuries.
