Xebia Blog

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...)

Filed under: Requirements Management
No Comments

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...)

Filed under: Architecture, Flex, Java, Requirements Management, Spring
No Comments

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...)

Filed under: Quality Assurance, Requirements Management
3 Comments

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...)

Filed under: Requirements Management, SOA
1 Comment

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...)

Filed under: Agile, Requirements Management
2 Comments

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...)

Filed under: Agile, Project Management, Requirements Management
No Comments

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...)

Filed under: Requirements Management, SOA
No Comments