In his excellent book, Managing the Design Factory, Donald G. Reinertsen, observes that architectural partitioning in product design, reduces risk by segregating variability and thus reducing uncertainty and the necessary buffering in the schedule.

It now seems possible to separate concerns in the requirements stage. Facts, Rules and Tasks have different amounts of uncertainty and are prone to different levels of change. Separating them out allows parallel development with reduced buffering and shorter schedules.

Facts about a domain (Features in FDD or Information in Goldratt's, The Haystack Syndrome) have a very low uncertainty. Facts are seldom likely to change. The only issue at variance is whether a computer system needs to include them or not. Hence, domain modeling and fact identification (Feature Listing) - steps 1 and 2 in FDD - have very low uncertainty. Completing these represents real progress.

The separate identification of business rules allows them to vary independently of facts. Rules are likely to change. Rules represent business policies such as "You must be 18 years of age to contract for a service plan" and "New service plans include a 2 year commitment with penalties for early cancellation". Such policies can be changed by marketing managers at short notice.

Tasks are the least well understood. Often UI designers talk of "a-modal design". The purpose of which is to allow a task to be performed in any order. This prevents introducing a design constraint on usage. Different people like to perform tasks differently. Capturing task descriptions too early or too rigorously risks problems with the user interface design late in the cycle. It may even involve rejection by the user.  Tasks, procedures and UI designs have a high variability and are subject to late change. They need larger buffers. Keeping them separate from the rest of a system is more effective.

The problem with Use Cases is that they encourage the coupling of all three concerns - facts, rules and tasks. Use Cases couple all three types of requirement. This can lead to poor quality architecture. I fear that the mental model encouraged by Use Cases and their coupled approach to requirements leads to problems throughout the lifecycle. Plans based on requirements as Use Cases will need more buffering, will be subject to more late change and will carry greater uncertainty and risk throughout the lifetime of a project.

[I must thank both Martin Geddes and Philip Bradley whose thoughts contributed to this post]