“Keyword” approach

The “Keyword” approach in functional description.

Functional requirement is part of the “System Requirements” document and is written while analysing processes to be automatized. In a normal way, this part of the “Project Folder” has to be driven by a professional used to manage interview with people able to describe business or production activities.

During interview analyst will listen to people describing activities and ask questions about processes, rules, actions and roles. He will write-down all collected information in a document and will build a document that will be, then, validated by a committee. Each analyst has his own rules and know-how to catch the aim of the discussion with users in order to sort-out information, processes, actions and rules to be automatized.

When facing difficulties to get the information the most common way is to ask people to use simple word that qualify their activities, production of business processes, rules and roles.  We use this way in GPDEF the dedicated web service to help people in writing-down functional requirements describing their needs for software development.

Even if we are speaking about software development the word “Keyword” we use is to be understood from a linguistic point of view, as a word which occurs in a business description more often than we would expect to occur by chance alone. Keyword, in GPDEF is not as in computer programming a reserved word or an identifier.

Definition

Keyword: A keyword is a word or a group of words that will represent either an entity, either a process, either a result of a process, either a relation.

Entity: An element that is necessary for the business activities, like a person, a group of person, an object, a place, a tool, a vehicular or whatever else that comes in a business description is defined as an Entity.

Process: An action, a group of actions that are computed in order to get a result like a simple addition or a complex payroll calculation is defined as a Process

Process result: Simple information like a number or a complex tax statement resulting of a computation is defined as a Process Result.

Relation: A link between element entering in a business description, between computed action, and information resulting of a computation is defined as a Relation.

Figure 1 - Keyword definition

Entity, Process, Process result and Relation are here to qualify “Keyword”. User will have to set qualification to the “Keyword” in order to continue the functional description. We are going step by step. Once it is set, user will be able to enter more information to continue the function description.

Qualifying a keyword as an entity

Qualifying a key word as an entity is to describe the entity, attribute if any and related action that will be performed by the software.

Figure 2 - Entity representation

User can set a name different from the keyword related to the Entity. Usually the Entity should have the same name as the Keyword, but sometimes it is useful to be able to set it under a different name. Short description is to make a presentation of the Entity in few words. Long description is to set the full description of the Entity. Attribute can be set at this stage. By attribute we shall have all information that can describe the entity. Actions are here to describe what will be performed with the Entity. An Entity can be linked to a group. The notion of group will be developed later in this document.

Actions, in second step, can be used to generate detail specification document. In this document user will be able to give more information about action to be performed.

Qualifying a keyword as a process

A process is a systematic series of actions directed to some end. Qualifying a keyword as a process is to describe the “phase” that system will have to compute. In GPDEF we use phase and not task, phase is more general, task is more technical. As we target non-technical user, we use more general words. A phase can be composed of several actions or task that can be described in a detail specification document.

Figure 3 - Process representation

User can set a name different from the keyword related to the Process. Usually the Process should have the same name as the Keyword, but sometimes it is useful to be able to set it under a different name. Short description is to make a presentation of the Process in few words. Long description is to set the full description of the Process.

The next topic we shall find in process presentation in GPDEF is “Menu”. It will certainly chock some purist to find here in a functional description a link to some concrete part of a software, but don’t forget that we are targeting non-technical people who, while speaking about needs, are projecting in their mind the final solution. Having here menu description is a choice to help people in expression of their needs on a real way.

As for the Entity, a Process can be linked to a group. The phase can be multiple. They are here to describe step by step actions or tasks that the system will have to perform. As for “Action” link to keyword, “Phase” described within the Process will allow user to generate a Detail Specification Document. In this document user will be able to give more detail of phase and action of the process.

Qualifying a keyword as a process result

A result is the consequence of action of a process. This step is a key point in functional description. Describing the result awaited by a process or a set of processes should be done carefully. Often it is when seeing the awaited result that people understand the purpose of the previously described process.

Figure 4 - Process result representation

User can set a name different from the keyword related to the Process Result. Usually the Process Result should have the same name as the Keyword, but sometimes it is useful to be able to set it under a different name. Short description is to make a presentation of the Process Result in few words. Long description is to set the full description of the Process Result.

A Process Result will be defined as a:

• simple data,
• data to be saved,
•  data to be printed,
• data to be displayed,
• drawing to be saved,
• drawing to be printed,
• graphic chart,
• report to be printed,
•  electronic report,
•  formatted file,
• datasheet file.

These are common result of a process performed by a computer. It is important that user set the type of result should be.

If needed, data resulting of the computation can be stored as following:

• In a table (DB),
•  In an XML file,
• In a text file,
•  In a RTF file.

Qualifying a keyword as a relation

A relation is a significant association between entity, process or process result. This step is may be the more complex to understand for non-professional people. A relation is an important notion that will explain link: for example relation between employees and company will be “is employed” one company can employ several people, so the parity will be set to one-to-N.

Figure 5 - Relation representation

User can set a name different from the keyword related to the Relation. Usually the Relation should have the same name as the Keyword, but sometimes it is useful to be able to set it under a different name. Short description is to make a presentation of the Relation in few words. Long description is to set the full description of the Relation.

Parity is to describe the properties and quantity in relation. Type is here to define what object are in relation: Entity, Process or Process Result. Choice one will be fulfilled by the system, for example, by all Entities recorded in the System is Type is set to Entity/…. And choice two will be fulfilled, for example, by all processes if Type is set to …/Processes

The notion of group in GPDEF

Group here is to design a functional link between Entities, Processes, Process Results and Keyword. The result of this link could design a function of the software.

The notion of domain in GPDEF

Domain here is to design a functional link between Groups. The result of this link could design a module of the software.

Both group and domain are important features in requirements design within GPDEF. It is to be seen as a functional organisation for the design of the software.

Keyword approach as used in GPDEF allows collecting information on needs from users. Professional will be able, then, to find point to be clarified and to be improve by a special interview on relevant points.

PierreTsaguria