Functional Analysis / Requirements Analysis
Once you have gathered your initial set of requirements, scenarios and assumptions, before formalizing these into a detailed requirements definition you need to take a step back and perform a high-level business functional analysis to make sure that you have considered the entire business context, and that there are not areas of functionality that have been missed.
There are several tools and techniques that can be employed - business context diagrams, functional decomposition, business process flows and an operational architecture. Each of these is described in more detail below:
The business context diagram is a block diagram that outlines all the major internal entities in the organization and the relationships between them, together with the the various external entities that the organization interacts with and the relationships and information flows that occur.
Sometimes you can create a single business context diagram for the entire organization (in which case it is an enterprise business context diagram), other times you may decide to create separate context diagrams for different components or divisions in the organization.
Another key activity is to perform an analysis of the different functions that exist in the organization (e.g. in our library example, it might include: lending, research, purchasing) and examining the existing information systems and information flow requirements that exist between the different functions. This is important to understand because the requirements for a new system are inevitably influenced and affected by the existing systems and necessary information requirements that will need to be supported by the new system.
Once you have a high-level understanding of the main entities, business functions and information flows in the organization (which are essentially the static attributes), you need to consider the dynamic aspects that will influence the requirements. Developing a set of representative business process flows is a critical aspect of detailed requirements gathering. Often as you consider how the different entities interact to conduct specific transactions, additional details will emerge that would not have been conceived from a traditional top-down requirements laundry list.
You can document these process flows in a variety of ways, including UML use case diagrams, flowchart diagrams, or even UML sequence/event trace diagrams. The key is to discover the interactions that occur between the different entities and use those to discover missing or implied requirements. Note that this is not the same as the formal system design phase where you will be defining all the process flows in the system. In the requirements phase, you just want to focus on a handful of representative cases to make sure that there are not implied requirements that have not been accounted for.
When designing military systems, you may come across the DOD Architectural Framework (DODAF) and its various architectural views. The Operational View (OV) or Operational Architecture (OA) is equivalent to the activities described in this section, comprising requirements analysis, information flows, business process analysis and activity models.