Functional Team

From ADempiere
Revision as of 07:18, 21 July 2015 by Mar cal westf (Talk) (20120510 (together with Technical Team))

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.



Everybody can become a team member, unless 2/3 of existing members disagree.


As described and voted in the Software Development Procedure

  • ensures that all contributions meet functional requirements in respect to quality
    • requirement makes sense
    • feature is needed in trunk or to be kept as optional extension
    • requirement is solved
    • acceptance criteria are defined
    • test cases are complete
    • user documentation is sufficient
    • system documentation is sufficient


  • The Functional team has got the final decision on which feature is accepted and merged from development to stabilization branch.

Concept Template

As starting point to be discussed for further/ future usage. The Functional Specification Style Guide intends to be a brief document to explain how to create well formed documentation for all the projects developed by the ADempiere Community.

Please see below for an explanation for each section of the template. This Template suggestion is based on the Contributions Template from Openbravo, which can be found here


User, Date Status Description Points
Mo 11:15, 30. Jul. 2009 (CEST) In Development ... Further Information ...
Mo 11:42, 12. Jul. 2010 (CEST) Technical Team: Approval ... Further Information ...
Mo 14:46, 23. Nov. 2010 (CET) Functional Team: Approval ... Further Information ...
Ts 18:55, 26. Nov. 2010 (CET) Other Status ... ... Further Information ...


Sponsoring: <contributor name(s)>

Concept: <contributor name(s)>

Implementation: <contributor name(s)>

Testing: <contributor name(s)>

Documentation: <contributor name(s)> ...


The overview/ short description for the project will be a brief summary outlining the goals and reasons for the project.


Go into more detail here on how the implementation of this project will be used and why it is required in the business.


Any references that may be required for extra knowledge or information in regards to providing an accurate estimation on the completion time for the project.

Design Considerations

This section of the specification covers anything that may affect the development or implementation of the solution. This is the place to put any potential problems or requirements that are not necessarily stated elsewhere in the specification.


With all projects there will be certain assumptions made regarding the development or implementation of the solution. Examples of these would be that all components should be translated into Spanish, or ??


In the project there may be elements of the solution which will have a dependency on outside issues. In order to implement or develop the solution these dependencies will need to be resolved or removed. e.g. resolving a licensing issue with a dependant library


Highlight here any issues which will restrict the development or the implementation of the solution.


Please explain any specific terms relating to the project that may not be understood by all involved. This would include industry specific terminology or abbreviations used in the specification document.

Functional Requirements

This is the main section into the Functional Specification document and it should be treated with an special care.

User roles & profiles

Explain the different roles that can use the new functionality and their knowledge related with computers.

Examples of possible user roles:

Warehouse workers
Typically these users do not have a high level of professional education and might not be computer literate. They tend however to spend a number of years with the same employer and after hiring they go through a few days of training to learn the processes within the warehouse. These users, therefore, need to be able to learn how to use the product in a few hours.
Purchase managers
Typically these users have a high level of professional education, are computer literate and receive training in the product and business process. These users perform purchase orders from the requisitions, they have to select the correspondent vendor taking into account the different variables that can take part in the decision: price, discounts, availability,...
Generic employee
These are users that work for the organization implementing ADempiere in a variety of roles and that are involved in a given business process on an occasional basis. Because of the infrequent nature of their involvement in the process, their primary concern is ease of use, defined as the ability to perform a new task without having to read any documentation.

Business process definition

A definition of the process is expected in order to know what business capabilities are supported.

User stories

A good approach to understand the problem is trying to explain it with real cases that happen in the real world.

Functional requirements based on business processes

Use this space to provide detailed information on the various functional requirements. If possible this should include process diagrams and mock ups of files or material that gets used within the process. The more information regarding the process the better as this will give the developers the relevant information to understand the process and allow them to provide functionality that meets the requirements.

User Interface Mockups

A picture tells a thousand words

Providing a mock up of how the user interface should look provides a very clear definition of what the developer needs to create. The developer will not implicitly understand how the user will use the screen so the results may not be as user friendly as they could be. This is where the mock up comes into it's own.

Think about

  • how the user will complete the screen,
  • where will they go first,
  • what is the most important information to gather,
  • what are the mandatory fields required

A good screen design will make the implementation so much easier and the customer happier.

Acceptance criteria

ID Expectation

QA and test cases


Development infrastructure

Table with standard info that is required for documentation and task handover:

Name User, Date (Signature) Description

Stab-SCM (URL)



Explanation of table:

  • Name: Name of information item
    • Devel-SCM: URL of SCM repository location where the devolopment is done (SCM="source code management")
    • Stab-SCM: URL of SCM repository into which developed work is merged for stabilization
    • SQL-Skripts: List of URLs to migration Skripts (inside SCM) that are applied to a DB for rollout
    • Community: List of URLs to BFs and FRs that came up development
  • User/Date: Signature (~~~~) of the person who last edited the row
  • Description: Value, Comment, Description or List of URLs depending on "Name".

Technical Requirements

This area will generally be left to the developers and custom development to complete. However if there are specific technical requirements from the implementation then this is the place to state them. Good information here would be the environment into which the final solution will be deployed.

Data Requirements

Are there specific requirements for the handling of data? Put this information here, one such example may be that no information is to ever be physically deleted from the database and should only be made inactive. Perhaps the system is to take data from another database and work with that....anything data goes here.

Non-Functional Requirements

Non functional requirements are the soft touches that the system needs to cater for. Are there speed requirements for the system, what about issues with skinning, language, jargon?

Open Discussion Items

ADempiere is an open source project, and it is aimed that anybody in the community can expose his/her point of view. The points that need to be discussed will be exposed in this section and the achieved resolutions will appear in the next section. Here is the place too, where Functional and Technical Teams can put their discussion Points about the concept.

Closed Discussion Items

Once one conflictive point has been discussed, the achieved resolution is presented into this point.


This is the template with all the points useful to cut & paste into your new functional specification pages:

= My Project - Functional Specifications =
== Status  ==
== Contributors ==
== Overview ==
== Purpose ==
== References ==
== Design Considerations ==
=== Assumptions ===
=== Dependencies ===
=== Constraints ===
== Glossary ==
== Functional Requirements ==
=== User roles & profiles ===
=== Business process definition ===
=== User stories ===
=== Functional requirements based on business processes ===
==== User Interface Mockups ====
== Acceptance criteria  ==
== QA and test cases ==
== Development infrastructure  ==
== Technical Requirements ==
== Data Requirements ==
== Non-Functional Requirements ==
== Open Discussion Items ==
== Closed Discussion Items ==

Meetings of Functional Team

We meet at Thursday 15:00 hours GMT via Skype. Minutes of Meetings are to be written on the following Friday latest and published on the wiki page until evening.

20101209 (together with Technical Team)

Agenda Minutes

  1. Channel for regular meetings
  2. Frequency of regular meetings
  3. Rules and rights of every team
  4. Communication between both teams
  5. Misc

20101216 (together with Technical Team)

Agenda Minutes

  1. Review task list from last meeting
  2. Templates for teams
  3. Repository (Mercurial)
  4. Codebase
  5. Misc
  6. Next meeting
  7. Next moderator

20110106 (together with Technical Team)

Agenda Minutes

  1. Review task list from last meeting
  2. Repository (Mercurial)
  3. Codebase
  4. Misc
  5. Next meeting
  6. Next moderator

20110113 (together with Technical Team)

Agenda Minutes

  1. Review task list from last meeting
  2. Misc/ Next Steps
  3. Next meeting
  4. Next moderator

20110120 (together with Technical Team)


20110127 (together with Technical Team)

Agenda Minutes

  1. Mercurial direcories
  2. Patches
  3. Test framework
  4. HG Repo Permissions

20110203 (together with Technical Team)


20110210 (together with Technical Team)

Agenda Minutes

  1. Review task list from last meeting
  2. Test Framework
  3. Bug Fixes
  4. Status of new functionality
  5. Migration Tool see [1]

20110210 (together with Technical Team)

Agenda Minutes

  1. Review task list from last meeting
  2. Mercurial directories
  3. Test framework
  4. Integration of Bug Fixes and review of new functionality
  5. Migration Tool
  6. Misc

20110224 (together with Technical Team)

Agenda Minutes

  1. Migration Tool
  2. Status of renaming in Mercurial/ Mercurial directories
  3. Review task list from last meeting
  4. Test framework
  5. Integration of Bug Fixes and review of new functionality
  6. Misc

20110303 (together with Technical Team)

Agenda Minutes

  1. General
  2. Mike McKay as Functional Team member
  3. ADempiere Server Test
  4. Testing framework evaluation status
  5. Starting with the revision the pacth a new mercurial
  6. PMC in Adempiere wiki
  7. Next meeting


Agenda Minutes

  1. General
  2. Organization of meetings
  3. ADempiere Server Test
  4. Test Concept


Agenda Minutes

  1. Discuss Email Notificatinos -> some FT members haven't been receiving them
  2. Test Server Status
  3. Test Concept
  4. Other issues
    • Next Meeting Date
    • Moderator


Agenda Minutes

  1. Test Server Status
  2. Test focus
  3. Other issues
    • Next Meeting Date
    • Moderator


Agenda Minutes

  1. Jenkings Server
  2. Tests


Agenda Minutes

  1. Single item: Organizing test towards release

20110810 (together with Technical Team)

Agenda Minutes

  1. Decide over Daniel Tamm's changes
  2. New seed for mysql
  3. Official statement about trunk and contributions
  4. Final steps towards release

20111026 (together with Technical Team)

Agenda Minutes

  1. Management of Copyrights (commiters, authors)
  2. Service Pack release
  3. Hotfix proces
  4. Service Pack Distribution

20111121 (together with Technical Team)

Agenda Minutes

  1. Decision about pulling changesets from Carlos Ruiz
  2. Mavenizing ADempiere
  3. Service Pack release
  4. Service Pack Distribution

20111123 (together with Technical Team)

Quickmeeting Minutes

    • Emiliano: Statement from FT/ TT about author erasure. Post with suggestion from partial Team.
      • []

20111205 (together with Technical Team)


Drafted Agenda/ Date/ Time: to be confirmed

  1. Discussion/ Decision about

20111219 (together with Technical Team)

Drafted Agenda/ Date/ Time: to be confirmed

Discussion/ Decision about
  1. Status of lasts meeting's TODOs
  2. Proposal to
  3. Manufacturing Light(ML) integration approach -

20120116 (together with Technical Team)

Agenda Minutes

  1. Roadmap to new release
  2. Feature requests management

20120510 (together with Technical Team)

Agenda Meeting Minutes

  • Date / Time: May 10th 2012 / 14:30h - 16:00h GMT
Discussion/ Decision about
  1. Release 3.7.1
  2. Reschedule meetings

20150721 (together with Technical Team)

Agenda Meeting Minutes

  • Date / Time: July 21st 2015 / 12:00h - 12:59h GMT
Discussion/ Decision about
  1. New Contributions
  2. New Releases