Posted by Viktor Grgic in the early afternoon: January 16th, 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.
Posted by Erwin Bolwidt late at night: July 16th, 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.
Posted by Gerard Janssen terribly early in the morning: June 11th, 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.
Posted by Viktor Grgic in the wee hours: April 5th, 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.