Time is wasted at a point in development when time is of the essence, and developers will find it hard to produce a good software product based on ill-defined requirements. Capturing, validating and verifying functional requirements are major challenges, not only for clients and business partners, but also for managers and software developers. We need clear and usable requirements that can guide the development of a quality software product, and a poor requirements process will not lead to a good requirements product. As mature managers, we no longer expect silver bullets for requirements engineering. They provide the knowledge behind any and every business structure or process.
Business rules are also, therefore, at the core of functional requirements.
The behavior of a claim in a pending lifecycle stage is, thus, dependent upon business rules which govern and guide behaviors. As the essential ingredient of functional requirements, business rules deserve direct, explicit attention. Since business rules lurk behind functional requirements, they are easily missed and may not be captured explicitly. Without explicit guidance, software developers will simply make whatever assumptions are needed to write the code, thus building their assumptions about conditions, policies, and constraints into the software with little regard for business consequences. Rules that are not explicit and are not encoded in software through the guesses of developers may not be discovered as missing or wrong until later phases.