Knowledge Sharing Pattern Language


Pattern

KSP08
Created Skeleton

Dimensions and Knowledge Flow:
 


I1
Knowledge Sharing
in a Project Team

 


Requirements
L1 Project Establishment
 

Project
Manager  

<----> 

Project Team Member

   


Problem Project team members having only very general knowledge about what the results of a project should be..
 
Initial Context A new project is about to start and a project team is assigned to it. A preliminary understanding of project objectives exists (Shared Understanding, KSP05).
 
Roles Project team members and a project manager or a person in the role of Requirements Manager.
 
Forces Requirements are a structured way to introduce what is required from a project. One of the origins for requirements is the customer and what the customer wants from the project. Requirements thus represent a customer need/problem that is to be solved with the results from the project.

Requirements are linked to all parts of the project implementation trough the traceability information. Those are a sort of a skeleton for a project.

In addition to agreeing upon the requirements with the customer, those requirements must also be communicated effectively among the project team to really utilize this "skeleton" and to assure correct final results. Requirements specification represents the first real understanding of what results the project should expect. 

A good way to communicate the requirements in a project team is to involve as many persons from the project team as possible to define the requirements.
 

Solution

  1. Define Requirements. As much as possible, use all team members for defining requirements. Define the first baseline of requirements. (See: Discovered Bones, KSP06)
  2. Establish Environment. Establish the working environment for requirements management including storing, and initiate the use. In a small project this could be an Excel sheet of requirements and in a bigger project a dedicated database.
  3. Establish Traceability. Use the main requirements as a basic unit when defining what to implement when and where and what to test when. Describe the traceability chains in reasonable way. If possible, utilize tools to automate the linking.
  4. Communicate Requirements & Study Requirements. Assure that project team members have the correct and adequate understanding of the requirements.
     
Resulting Context Requirements for the project are well known among the project team making cooperation possible and allowing separate sub teams to work with different tasks. A basis has been created to trace information.

One potential pitfall is that project team members are not having adequate possibilities to be involved in defining/accepting requirements resulting in a situation where they do not understand the reason for all requirements. This might affect their commitment to the project and to the implementation.
 

Instances To be used always when a new software engineering project is established.

One potential pitfall is a case where the requirements are defined by the project team and no proper commitment is asked for or received from the customer. This could result in project work results that the customer can not approve. -> importance of the Discovered Bones, KSP06 with strong customer participation.
 

Process Connection Requirements Management

 

Home
Catalog

Last changes at 26th December 2007