Avoiding Prescriptive Requirements


Core Requirements

Requirements should be given as the Core Requirement, and avoid the common pitfall of providing Prescriptive Requirements

As an example, a core requirement in an insurance system may be:

As a user of the Broker system, I want to create a Settlement Batch of Eligible Documents across Insurance Policies

This is eminently testable, is clear and unambiguous, and has real business value, and it meets the general INVEST principle of good user stories (which is also a good maxim for any form of requirements):


  • It is Independent of other stories
  • It is easily Negotiated as to priority and value
  • It has real business Value
  • It is small enough to easily Estimate with some degree of certainty
  • It is of an appropriate Size for easy estimation, planning and prioritisation
  • It is able to be Tested both manually and in an automated fashion with clear and unambiguous pass or fail criteria, you can either do it or not


The stated requirement is not prescriptive, it does not specify how the user triggers this action, what data they need to provide, how they select the documents, nor does it specify what a "user of the Broker System" is within this context, nor what a Settlement Batch is, nor what an Eligible Document is. This means the requirement can be documented very early on, with little analysis work needed, allowing very quick comparison with other requirements, and very quick verification from the business as to the validity of the story.

Later this placeholder can be expanded in discussions between the technical teams and the business to include the actual definitions and scenarios that define its acceptance criteria:


  • The user must have the “Batch Creation” permission
  • Eligible Documents are those which are awaiting Settlement
  • A Settlement Batch is a group of Documents that will be dealt with together by the Claims Settlement system, so as to save managing on an individual policy level


This would lead to a requirement with maybe a dozen test scenarios giving all the variations of user and statuses that would allow or not allow the story to pass the test. All of these stories and scenarios are now easily tested with automated and repeatable testing.

At this point it would probably be obvious where within the UI this functionality should surface, and the design of the UI interaction can be worked out. This UI work is actually a very specific development skill within its own right - there is significant complexity in designing UI interactions that mirror both the technical system and the user’s mental model.

Through all of these steps, the original core requirement has not been changed, though its implementation and business logic may have evolved, changed and adapted to line up with other functionality.

Good requirements are merely a placeholder for a later conversation. Their level of completeness or accuracy only dictates your certainty in implementing them accurately and efficiently, but does not preclude moving forwards, and does not hold development up waiting on “complete requirements”.

As granularity increases, so does complexity required to understand, verify and implement, but oddly so does instability. By starting with core stories, you maintain a fairly stable set of requirements, and only deal with complexity when you need to, and suffer the instability only on individual scenarios.

Which brings us neatly to development

It is fairly well established now that development must be iterative within short cycles to increase its chance of being successful. Early feedback and revision saves massive amounts of time and effort correcting incorrect assumptions and poor translation.

The sooner a story enters development, the sooner a basic version of it can be demonstrated to business users, to verify against their assumptions, the faster it can be revised and the more accurately it will reflect the actual requirements. In addition it will expose underlying technical constraints and limitations earlier on.


Posted 02-09-2012 3:50 AM by Jak Charlton



Nick wrote re: Avoiding Prescriptive Requirements
on 02-09-2012 12:43 AM

I agree, I've started using SpecFlow http://www.specflow.org/ for this. It has the concept of Features that describe your core requirements, and Scenarios which describe the detailed implementations/flows.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)