3SL: Requirements management and model driven systems engineering from concept to creation.
Cradle®
Login:
Username:
Password:
 
Search:  
Visitor not logged in, You are: Home > Reference > Project > Personnel
 

Personnel


Clients

The client must be satisfied with the finished and delivered system. Where the system is being developed for in-house consumption, the roles of the client and the customer may be filled by the same person. If the client cannot be identified, then the motive for building the product is questionable.

 


Customers

The customer is the person, or group of people who are ultimately responsible for deciding whether or not to buy the product from the client. The product must be built to satisfy the aims of the customer/s whilst conforming to the constraints of the client. Even if the customer/s are people who work for another part of the client's organisation, they might still have the authority to decide whether or not to invest budget in the new product.

In the case of in-house development the roles of the client and the customer are often played by the same person. In the case of the development of a mass market product there may be several people playing the role of customer. In the case of a product that is being developed for an international market, there might be a different customer (or customer profile) in each country.

 


Developers

The Developers develop the system, they interpret the models and impliment that interpretation of the model in a real functioning way.

 


Sales

The process of persuading a client or potential client that an existing system or potential system meets the clients needs and that a contract be created to exchange the system for a financial reward.

 


Users

Users interface with the product in some way. The role of the client is to pay for the development of the product and the role of the customer is to buy the product. The role of the user is to use the product to do work. The characteristics of the users can be used to define the usability requirements for the product.

There could be many diverse users of a system, for example, schoolchildren, clerical staff, students, road engineers, foreigners, lawyers, remote users and project managers. Such a potential diverse set of user groups will have widely differing business knowledge and technological experience. There may also be differences between user groups that may influence system design such as:

  • Physical abilities/disabilitiesIntellectual abilities/disabilitiesAttitude to jobAttitude to technologyEducationLinguistic skillsAge group
  • Gender

Each user group can be prioritised indicating importance and precedence. Suggested categories of user are:

  • Key users: Users critical to the continued success of the product. Requirements generated by key users are given greater importance. Secondary users: Users of the product, but whose opinion of it has no effect on its long-term success. key users requirements take precedence.
  • Unimportant users: Users of lowest priority. They include infrequent, unauthorised and unskilled users, and people who misuse the product.

State if some users are considered to be more important than others as this should affect the design of the product. For example, a large customer who specifically asks for a product, must get want they asked for, or there may be a significant loss of business.

Many projects fail through lack of user participation. This can be because the required degree of participation was not made clear. When people have to make a choice between getting their everyday work done and working on a new project, the everyday work takes priority. State from the outset of the project, the level of the participation and type of contribution (e.g., business knowledge, useability requirements) from a category of user that will be necessary to provide the requirements.


[Copyright © 3SL 2008 | Last Updated: Sat Jul 19th, 2008 ]
Registered office: 2 Highfield Road, Barrow in Furness, Cumbria, LA14 5PA, Registered in England No. 2153654