on target

« Web Analytics: Grain... | Main | Dashboard for Monito... »

Tuesday Apr 06, 2010

6 poor ways to design requirements

Writing no application requirement is a bad practice, but the common approaches are costly and far from perfect. Discover why and find a simple, better alternative.

Application requirements always exist. They can be written, spoken or even thought, but there is no way to produce any kind of application if you do not know what user needs. Requirements, based on those needs, shall define what application will do (and not how it will work!).

In classic (waterfall) methodologies requirements shall precede everything else. Modern, incremental approaches provide more agility through an iterative sequence of requirements and delivery cycles (releases). No matter the approach, method or techniques: written requirements improve communication.

Since clear requirements are recognized as a key success factor, many techniques have been developed along time to produce them. Some overlap or extend development activities, as shown in this table that contains many known “celebrities”:

Technique	Motivation	Issues
No written requirements (maybe just a list of functionalities)	Usual excuse: requirements take time (that's wrong – see below). The only advantage: no requirements = no error = no guilty.	You can't even assess project success or failure: you don't know if you reached your goals if there is no goal!
Pages and pages of narrative text	Typical of corporate culture where page count was sometime confused with rigor and completeness.	Lot of effort and time to write. Almost nobody will read. Usually imprecise.
Diagrams and Flowcharts	Invented as an alternative to narrative (an image worths a thousand words). Are useful to illustrate some aspects of the application.	Not enough to define requirements. Lot of time & effort to produce. UML diagrams, for example shall be complemented by OCL or Action Semantics. UML (the standard) poorly supports multidimensional information.
Test Cases	Test cases are a need, but they do not replace requirements and specification. Techniques and tools like Fit and FitNesse can improve testing but are not enough to define an application.	Test cases do not define user interface Test cases do not define transformation rules.
Story boards, Screen-shots, prototypes & Scenarios	Useful to “give a tangible feel” to users.	Lot of effort and time to produce. Too detailed to represent requirements. Usually used too early: you can't make a prototype unless you know which information user needs. Often abused: trial and retrial generates poor architectures at high cost.
Use Cases	Great to model, with user application detail and interface in actual business procedures.	Too detailed to represent requirements.

As you can see none there is not an easy and systematic solution even if you try to combine all techniques.

An alternative approach

And now, after pointing all those problems I shall obviously show you the promised approach with many benefits:

Intuitive – both developers and users easily understand
Effective – focus what matters: information!
Synthetic – few words not pages and pages
Manageable – no special tools: any text editor can do the job!
Fast – time to write = time to think
Precise – avoid conflicting meaning
Incremental – can be complemented / refactored with great ease.
Integrable – can be auto-verified and integrated with other tools.

I am not suggesting you to avoid the techniques shown in previous table. They are all useful for their original intent and motivation but, obviously, using them to define requirements is at least an overkill.

In addition many tools supporting those techniques can be automated to import requirements in the format I am suggesting. Many UML diagrams, for example, can be automatically produced from that format.

I have refined this strategy along time using principles of Structured Analysis and Functional Programming. It worked pretty well in many actual projects, including complex information system and modern Business Intelligence applications.

The system principle

The basic principle is simple: any application is a system that can be defined as a stimulus – response engine. To create application requirements you shall only define its inputs and outputs. So all what you need is a simple systematic way to define data and information flow between application and external environment.

How to define elementary information

Let's define elementary information first. Say c is a Client, here is how to define some elementary information about it:

address(c),balance_due(c),transactions(c)

The “classic” functional notation is better than the traditional “dot” notation (single argument):

c.address, c.balance_due, c.transactions

In fact information is a function of possibly many arguments. Dot notation can't represent, for example, a common multidimensional information like this one:

sales(c,widgets,january_2008)

How to define a data (information) flow

Now that you have a notation for elementary information, you can define with ease logical groups of information that flow between application and user:

Sales_summary_request=

/* Parameters supplied by user */

year

Sales_summary=

/* produced in response to Sales_summary_request */

each(r: Sales_rep) {

name(r),each (m:month(year)) {

sales_quota(r,m),

sales_amount(r,m),

rep_performance(r,m) =sales_quota(r,m) /sales_amount(r,m)

}

An information flow is generalization of any group of information like input forms, reports, diagrams, windows and so on transmitted or received by application.

You can see that few lines are enough to define a report and the parameters to be supplied by user. You can write those lines in seconds and your user can also, in a snap, spot the information she will get and confirm it will fit her needs.

The definition is “implementation independent”. User input, for example contains a year, but how data is actually entered (combo box, text box or calendar) is delayed to a later decision, possibly a use case. The same applies to output: sales quota, amount and performance can be shown as number or in a graphic, output can be paper, PDF or an interactive dashboard. What actually matters is the information content, not how it is represented.

That's all! Maybe too simple to require complex theories, books or even a single row of the celebrity table, but – believe – it works.

Try it in your next project!

Interested in partnership?

Would like to try or coach this technique with your clients, do you need any additional or technical detail? Please let me know! Component Bases Solutions has great interest in partnership with consultants. We can help you automate your proposed solutions in a very short time. We can also help to increase your visibility through links from many management tools we make freely available on the Web. Please contact for more detail.

Did you like this post?

Please, spend a few seconds and click on button below to socially bookmark it or tweet it. It will help to promote this blog and improve its content, Thank you!