The meaning of analysis and the importance of models

The basic definition of analysis is to break things down into smaller pieces to aid in understanding. In an organizational setting, it is useful to have a shared understanding of what processes the organization performs.

The best practice approach to communicating processes is with models. For the activities themselves we use process maps, aka process models. For the data collected before and during the execution of the those processes, we use data models. These are needed for any sort of functional specification. Every requirements effort should be centered on these two crucial techniques. No practitioner can be successful unless they leverage some sort of process and data models to consolidate and present functional requirements to all stakeholders. This most basic truth about functional requirements is that represent what processes are in scope and what data is associated with those processes.

The stakeholders need to be sure that their functional requirements are understood. Models do that. Paragraphs or lists of sentences that start with "the system shall" are dull, not concise, ambiguous and poorly accepted.

If the stakeholders insist on text based requirements, use models to create unambiguous, non-repetitive assertions. Most CASE tools can create these statements. For example, SADT/IDEF0 models can be written in the form: The Activity [Activity Name] transforms the input(s) [Inputs List] into the output(s) [Output List] according to [Controls List] using [Mechanisms List] as resources. Similar language may be adpated for DFDs, UML Activity Diagrams or other approaches. For Data modeling, the tried and true "Each [Entity Type Name 1] is [Relationship Name] [one and only one | one or more] [Entity Type Name 2](s). But for most of us, the models will contain 80% of the message of what is functionally required.