POLDAT should be POLDATE

POLDAT contains the basic aspects of a contract, independently of the nature, environment or magnitude.

It’s an useful tool to enable everybody to work on all aspects of the initiative. For major initiatives, all is included and nobody forgets any of these aspects. For small initiatives, the use of POLDAT as guidance for the definition of an initiative force the person writing it to think about all aspects of the customer needs.

By this reason and others, I would add “E” from experience to the POLDAT. This will enable to have on the first level of requirements the need to understand the “experience” expected by the user or by any stakeholder. These questions need to be done in the beginning of all these processes. This is key value in the Digital Transformation shift we are working on. And “E” should be always in our minds.

You probably will argue that “experience” should be defined as part of the “P” process. But to me, right now this is a limitation that does not give the importance of the experience for the customer.

We should be asking things as:

  • When a customer reach you, how should s/he interact with you?
  • How is the experience today? how should it be tomorrow?
  • Do you know when your customer needs you? How can we make you to be there?

Requirements, the issue

Gather requirements is a science, a process, an art; you require a lot of knowledge to perform it properly.

The first thing to do is to analyze the issues that the industry is recognizes and the specific lessons learned from your customer or environment.

Things like:

  1. “…The Industry average for project Investment in the requirements process is 3% of project cost but….…when 8-14% of project costs are invested in the system life-cycle requirements process, there is a much higher probability of achieving lower costs and improved schedule.  (American Management Association 2001)…”
  2. Poor requirements management accounts for as much as 71% of software project failures (www.compuware.com, 2006)
  3. “…Acme customer never pays attention to security requirements, and we struggle to identify all combinations of access to the different layers. We identified that clear tables with all status and combinations are required to really generate the debate into Acme team…”

If you are involved gathering requirements on a customer you have to ber fully aware about all that is happening around you, due to the fact that this process is highly visible to the customer.

  • It enables the customer to understand their concerns and set priorities.
  • Your customer will see how you are able to move within the different business units of its corporation.
  • It helps the customer visualize the future, in detail, generating a lot of discussions about their own processes.
  • It’s a business process that will serve as basis for: obtaining internal approval to go ahead with the specified initiative, serve as input document for the solution design, serve as basis for UAT phase, or for the analysis of COTS.
  • It builds confidence that the delivered solution will address their real needs, whether they explicitly state them or not – we see the problem from their perspective.
  • Provides a basis for effective budget setting and planning.
  • Tracking changes and gaining agreement, will reduce risks in the following phases.
  • You have to define a completion criteria, as you have limited time and money.

You are not the only one who needs to understand the issues and hurdles you face when you are gathering requirements, all stakeholders have to be aware of them.

Manage requirements

Keep the requirements under control is sometimes very difficult. Continuous changes on specifications, continues changes of direction, quick estimations demanded under weak specifications, etc…
To make the customer to recognize that all changes they are putting in place is even hardest. They just do not care, you are there to handle and be paid by doing it.
I like this part of the deals, it enables me to understand their business in deep, the way the work internally, and gain trust.
frozen_requirementsWalking on water and developing software on some requirements is easy if both are frozen

Online store requirements checklist

I’m evaluating some solutions for and online store, and the first step is to define a requirements checklist:

1.- General overview & look

  • Frame of the main screen can be adapted.
  • Ability to change layouts.
  • Ability to add widgets.

2.- Product form, product classification & product representation

  • Check the aspect of the views of products.
  • Check the aspect of the product sheet: magnifying glass.
  • Ability to decrease number of products.
  • Ability to add features to the products: size, color, model…

3.- Purchase process

  • Notifications for the buyer in each one of the steps given by the purchaser: you have bought, you have paid, your package has been sent.
  • Availability to define discount patterns with different options.
  • Offer methods of payments.
  • Flexible currency availability.
  • Flexible tax assignment.
  • User can purchase as anonymous or as user.

4.- Inventory

  • Check the inventory before sell.
  • Check the minimum levels required.
  • Warn administrator when inventory reach a minimum.

5.- Visualization of products

  • Show products: latest, most sold, newest, featured, searchable.
  • Ability to visualize the products in different ways.
  • Main page configurable.
  • Different type of layouts.

6.- IT requirements

  • Extended platform with a strong community.
  • Payments plugins.
  • Connection through https.
  • available templates
  • Outstanding SEO engine
  • Multi-language availability
  • A solution that the enable the addition of modules or plug-ins

Wabi sabi

I have been some months working on this: http://www.wabisabi.com.es/

Finally I obtained the approval to move to production on 15 September. I write the date, because is something I want to remind, it will be useful for future.

What was the most difficult thing to achieve this web page?

  • To find a convenient hosting service?
  • To learn how to work with Joomla environment?
  • To work on security issues related to the hosting and Joomla?

No, the most difficult thing was to define the detailed requirements from my wife.

Attributes of well defined requirements

List to for reading before define requirements:
  • Unambiguous: Precise and clear with only one interpretation. Consensus agreement.
  • Complete:  Every known aspect is described.
  • Consistent: No contradictions, uniform terminology used.
  • Measurable: In terms of time and cost, can it be estimated? Can it be verified against the implemented solution?
  • Testable: Requirements should be quantifiable.
  • Traceable: Must be able to track from project inception to delivery.
  • Design-free: “What” not “How.”
  • Understandable: Able to be understood by non-technical customers, system users and developers.