<< Back to Requirements Management Home
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 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.
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.