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:
Business Context
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 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.
Business Functions
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.
Business Processes
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.
Mind Maps
Another useful tool for analyzing the system is a mind-map. In this type of diagram, you start with the main concept and draw lines to smaller and smaller items as you break down each idea and concept into smaller parts.
Operational Architecture
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.
| Artifact | Description |
| OV-1: High-Level Operational Concept Graphic | The high-level graphical/textual description of the operational concept. |
| OV-2: Operational Resource Flow Description | A description of the Resource Flows exchanged between operational activities. |
| OV-3: Operational Resource Flow Matrix | A description of the resources exchanged and the relevant attributes of the exchanges. |
| OV-4: Organizational Relationships Chart | The organizational context, role or other relationships among organizations. |
| OV-5a: Operational Activity Decomposition Tree | The capabilities and activities (operational activities) organized in a hierarchal structure. |
| OV-5b: Operational Activity Model | The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs; Additional data can show cost, performers or other pertinent information. |
| OV-6a: Operational Rules Model | One of three models used to describe activity (operational activity). It identifies business rules that constrain operations. |
| OV-6b: State Transition Description | One of three models used to describe operational activity (activity). It identifies business process (activity) responses to events (usually, very short activities). |
| OV-6c: Event-Trace Description | One of three models used to describe activity (operational activity). It traces actions in a scenario or sequence of events. |