Implied & Aggregate Requirements

Implied Requirements

• Not all conformance flows have corresponding requirements flows in the Context Data Flow Diagram. The flows conform to implied, or hard coded, requirements. They should be challenged to see if the implied requirements are stable over the life of the system.

• Implied requirements aren't necessarily bad in and of themselves. What is bad is that if we don't recognize that the implied requirements exist explicitly, we end up hard coding them into our systems implicitly. This is fine until those implied requirements change and the system needs to be overhauled or replaced to meet the new requirements.

• An Aggregate Data Flow is one which contains multiple external events. When present, they will always be split below the context level into multiple flows, each of which contains a single external event.

• An Aggregate Data Flow at the context level represents high risk to the project under analysis. It forces context level issues to be deferred to later analysis at lower levels of detail. Recommendation: Immediately split the diagram into multiple context diagrams. Each new diagram will define a single requirement/conformance context with a single event.

• Whenever we draw a data flow diagram, we should be specifying which type each flow is. Usually it will be easy, and obvious. However, sometimes it'll be tough. Often the most difficult are those we first think are obvious, only to learn that it's the opposite of what we thought.

• For example, in the travel context, a flight or hotel "reservations" flows is a good case in point. Reservations are a conformance flow from the carrier/hotel to our customer. On first glance, however, this is less than obvious. Many students first state that reservations are a requirements flows from the customer to the carrier/hotel and that the flight/room is the conformance. This simple misconception, if not caught early, would completely confuse further analysis until the error were detected.