Number of Alerts != Number of Events

The number of alerts you receive is not always indicative of the size and scope of the attack. As an example, I received an alert about an old DoS tool, the Shaft SYN Flood tool. 

I don't know if that was the actual tool in use or not (doubtful, and it's not relevant enough to spend time finding out), but when I looked at the packet data I found over 3.6 million packets had been sent over a two hour period. It's easy to miss a single alert when you're busy, or an inexperienced intrusion analyst might see this alert and think it was generated by a single packet. 

It's important to know as much about the rules that generate alerts as possible to have the best chance of making an accurate analysis of the event. Some rules use thresholding to avoid overwhelming the alerting system and the analyst, and may generate one alert for say, every 100 events in a sixty second period. If you're not aware of that, you'll miss the scope of the event.

It's also why it's so important that the IDS you use has an open rule or signature set. You need to be able to see the parameters of the rule, what it triggers on, to be able to look at the packet and determine if it a true positive or a false positive, and if it's a true positive, if it's relevant to the destination of the event.

Being able to modify the rule is even better. You may have a case of recurring false positives from one source or a header parameter, but other cases are valid. You don't want to disable the rule but you don't want the false positives, either.

If your system allows you to modify the rule and create a new one out of it, you can mitigate the false positives while maintaining  the coverage. And being to able to create a whole new rule for some event specific to just your organization is a best case scenario. If your company has in house apps they use, there obviously won't be any rules to cover them in the rule set that ships with your IDS.