Functional Team

From ADempiere ERP Wiki

Revision as of 15:11, 15 March 2011 by Trifonnt (Talk | contribs)
Jump to: navigation, search

Contents

Staff

  • Victor Perez
  • Ramiro Vergara
  • Mario Calderon
  • Mark Ostermann
  • Kai Schaeffer
  • Michael Judd (Accounting/BI/Processes)
  • Paul Aviles
  • Enrique Ruibal
  • Mike McKay
  • [User:Trifonnt]
  • <please add your name when you want to join the team (4 hours minimum work per week)>

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

Responsibilities

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

Process

  • 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 http://wiki.openbravo.com/wiki/Functional_Specification_Style_Guide.

Status

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

Contributors

Sponsoring: <contributor name(s)>

Concept: <contributor name(s)>

Implementation: <contributor name(s)>

Testing: <contributor name(s)>

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

Overview

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

Purpose

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

References

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.

Assumptions

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 ??

Dependencies

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

Constraints

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

Glossary

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

ff

Development infrastructure

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

Name User, Date (Signature) Description
Dev-SCM (URL)

Stab-SCM (URL)

SQL-Skripts

Community

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.

Template

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)

Minutes

20110127 (together with Technical Team)

Agenda Minutes

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

20110203 (together with Technical Team)

Minutes

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
Personal tools