“The Best Requirements Method” survey

Posted by Erwin Bolwidt mid-afternoon: May 8, 2008

What is the Best Requirements method? That's a mighty big and difficult question to ask, for several reasons. Everyone has a different idea of "best", but also of "requirements method".

While I could try to analyze various methods according to various statistics, it would still only give a one-sided view on the subject. In addition I only know a few methods very well so that would leave out other methods.
A different approach, the one that we take here, is to ask you, the participant in the requirements process.
(more...)

Flex Beyond — eForms

Posted by Balaji D Loganathan at around evening time: March 5, 2008

Around 6 months back me and Vikas Hazrati gave a XTR on Adobe Flex to my colleagues in Xebia India.

We took some resources from Adobe Dev Net site and eventually found a cool article explaining how Flex Data Services works with Spring using Spring Remoting features and so on.
We were quite amazed with the UI capabilities of Flex with its server side integration. If you look at that article now, its start with a disclaimer saying "Effective with the release of Adobe LiveCycle ES, the Adobe Flex Data Services 2 server product has been rebranded as a Solution Component of LiveCycle ES."
(more...)

Is it a Requirement or is it Design?

Posted by Erwin Bolwidt in the late afternoon: January 18, 2008

Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.

That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more...)

Your SOA product choices should be based on the QUINT model

Posted by Viktor Grgic in the early afternoon: January 16, 2008

It is always about well-defined requirements stupid. :-) Building or choosing out-of-the-box software products like an ESB within the company's SOA strategy can be very well supported by a number of requirements distilled from the QUINT2 ISO model:

Functionality: Suitability, Interoperability, Compliance, Security, Traceability
Usability: Operability, Customisability
Efficiency: Time Behaviour
Maintainability: Testability, Manageability, Reusability
Portability: Adaptability, Replaceability

This is the selection from the complete QUINT2 model. It does not mean that other requirements are not important, but usually less than these. If you fill out these requirements properly, which is still a daunting task, then you will have done pretty good requirements gathering. Besides these aspects, there are also security requirements: availability, integrity and confidentiality which should always be considered.

(more...)

Agile Up Front Analysis

Posted by Erwin Bolwidt late at night: July 16, 2007

One of the most visible aspects of agility is making decisions when they are needed, and not making them all up-front, before any development work is done. But some decisions are needed before the rest of the project is executed.

An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.

(more...)

Reality is not plan based - Plans as a communication device

Posted by Gerard Janssen terribly early in the morning: June 11, 2007

When it comes to the contents of plan there is a big difference between prescriptive and criterion based approaches. As we stated before the idea behind a plan is to provide guidance to the activities on the project. In that sense it is a sort of communication device. However, the way we use the plan determines its effectiveness.

A plan should describe how to realize the business case on which the project is based. In the criterion based approach to project management this means that the intention of the project is described, but not all activities on how to materialize the business case are specified. The essence of the plan is to explain or to translate the business case into practical guidelines and criteria on how realize the business case. Put differently, it specifies the high level requirements for the project that need to be met for the project to be deemed successful. Tom and Kai Gilb for instance like to state that approximately 10 high level requirements should be enough to give direction to a project. These requirements then are the criteria used to measure the progress and success of the project.

(more...)

Top 10 recommendations when defining B2B services

Posted by Viktor Grgic in the wee hours: April 5, 2007

Requirements engineering and design of services that your company need to provide to other companies is quite different from reqs. engineering for an interactive website, or other systems where an actor is a real person. In case of B2B services, the actor is always another system. Mostly you also know who your actors / other companies will be, unless you are Amazon or Google.
These recommendations will give you some tools and ideas how to deal with requirements engineering and design of B2B services.

(more...)