In most companies, good teamwork is considered essential. Teams are often formed for a particular project or to achieve a specific goal, and the team members can come from different departments in the company. But one of the biggest problems that teams face is lack of communication, or miscommunication.

If you are heading a team, these tips will help you develop strategies to communicate well with all members, so that you can monitor progress of the project, get feedback, and make sure that everyone feels involved..

Tailor what you say to your team members

Different types of people like information presented in different ways. Some like to know the answer to “why” questions (Why is this project important?); while others want the answer to “how” questions (How can we increase sales by 5% in a recession?); to “what” questions (What is this project about / What is the deadline?); or to “What if” questions (What if we only concentrated on the European market?)

One way to involve all your team members – and to make sure that they all listen to you – is by tailoring what you say to answer these four types of questions beginning “Why?”, “What?”, “How?” and “What if?”

Use different communication styles to reach everyone

As well as respecting different reasons for listening (as above), try to also respect different generations within your team, as different age groups also have preferred communication styles.

For example, older team members tend to prefer formal organisation structures and planned meetings, but they may not use up-to-date communication methods. People in their 30s or 40s are more likely to have a direct, informal communication style. Younger team members prefer working together and want regular feedback. They are also much more likely to demand a fun working environment, and have career (rather than company) loyalty. Having grown up in the internet age, they are also used to a variety of communication styles, such as email, messaging, blogs and so on.

Using the right style for different team members will help you ensure that all members feel included and valued.

Use different communication forms

A combination of different communication forms helps you to be both “human” and clear. Use verbal communication for informal situations, but back it up with a written confirmation if the message is important, or likely to be misinterpreted. Written communication provides a permanent record of what was agreed or said, and is particularly useful in avoiding situations where individuals have remembered things differently from one another. Bear in mind, too, that if you appear positive and enthusiastic in your body language, you will be able to reinforce your spoken message.

You might choose to use some or all of these following methods of communication:

Team meetings / one-to-one meetings / Performance appraisal meetings (Often annual, these are formal opportunities to report on individual performance)
Minutes (which are either emailed or printed out, or more informal verbal follow-up from meetings)
Telephone conversations (follow up if necessary by written communication)
Instant messaging / chat (also useful for informal, regular feedback)
Video presentations / conferencing
Presentations (give summaries and handouts at the end)
Training sessions / courses
Memos (particularly useful for formal communication to all staff)
Progress reports (consider also sending these company-wide or to other work teams)
Newsletters (Weekly, bi-weekly and monthly newsletters can also be useful to report on progress)
Emails (limit to brief messages and use attachments for longer messages)
Web pages / blogs / microblogs such as Twitter to keep people informed of your whereabouts / texting

Five strategies for good communication

1. Structure what you say or write so it is clear, logical and concise

2. Only hold meetings if they are essential. Make sure you have clear meeting objectives, and then start and end the meeting on time. Summarise at the end of the meeting and clarify any points.

3. Be open and honest. Make sure your team knows what your vision and goals are. Also, realise that as a team leader you might need to make – and communicate – difficult decisions.

4. Listen to team members, and give and get feedback from your team members on progress.

5. Be available and flexible. Let your team members know when and how they can communicate with you. This means you might need to get up to speed on different communication forms and styles.

A use case association is a relationship between use cases important types of use case associations:

Include, Extends, Generalization

Include: A use case uses another use case (”functional decomposition”)

Extends: A use case extends another use case

Generalization: An abstract use case has different specializations

You must ask this entire question to get all scenario

What needs to be done to report a” cat in a tree “?

What do you need to do if a person reports a “Warehouse on Fire”?

Who is involved in reporting an incident?

What does the system do, if no police cars are available?

If the police ca r has an accident on the way” cat in a tree “incident?

What do you need to do if the” cat in a tree “turns into a Grandma have fallen from the Ladder?

Can the system cope with a simultaneous incident report “Warehouse on Fire”?

Example: page 27

The 3 scenario for the same action with specific actors.

in the first paragraph of “Report Emergency”

Example: the scenario is a candidate for a use case

Describe each of these use cases in more detail

• Participating actors
  
• Describe the Entry Condition
  
• Describe the Flow of Events
  

• Describe the Exit Condition
  
• Describe Exceptions
  
• Describe Special Requirements (Constraints, Nonfunctional )
  

• Identifying actors
  (type of actor that use system in all cases-normal and abnormal-)
  
• Identifying scenarios
  (different scenario with different actor –is specific scenario with specific
  

  
  Actor-)
  

• Identifying use cases (define use case and its actor)
  
• Identifying relationship among actors and use cases (relation
  use case and its actor)
  
• Identifying initial analysis objects (object that need in this use case)
  
• Identifying non-functional requirements (type of used in cases object’s)
  

1.B.4.0-Identifying actors

Questions to ask

Which user group is supported by the system to perform their work? – Customer of system. (Owner of car)

Which user groups execute the system’s main functions? - Who execute function (Driver of car)

Which user groups perform secondary functions (e.g. maintenance and administration)?

(Mechanical man) (Service station – in fuel system)

With what external hardware or software systems the system will interact? -Type of external environment that effect in system design.

1.B.4.1-Types of Scenarios

A concrete, focused, informal description of a single feature of the system used by a single actor.

Usually uses during the software lifecycle:

Requirements Elicitation: As-is scenario (Current) used in re-engineering

, visionary scenario (in future) used in Greenfield engineering, reengineering

Client Acceptance Test: Evaluation scenario. (System that will produce)

System Deployment: Training scenario. (Simulate action to train it)

How to find the scenarios?

Ask client discussion question don’t ask (yes, no) question?

Ask yourself or the client the following questions:

    What are the primary tasks that the system needs to perform? – System function

    What data will the actor create, store, change, remove or add in the system?

    What external changes does the system need to know about? – By which actor

    What changes or events will the actor of the system need to be informed about?

However, don’t rely on questionnaires alone.

Insist on task observation
if the system already exists (interface engineering or reengineering)

مثال كشاف النور: عند كل عنوان يكتب بعض الملاحظات التى تساعده فى العمل – صغيرة ولاكن مهمة – مثل (كلب فى الحديقة – متواجدين بع الساعة 11).

• Ask to speak to the end user, not just to the software contractor
  
• Expect resistance and try to overcome it.
  

Greenfield Engineering

Development starts from scratch, no prior system exists, and the requirements are extracted from the end

users and the client Triggered by user needs

Re-engineering

Re-design and/or re-implementation of an existing system using newer technology Triggered by technology

Enabler.

-must understand business role and logic.

Interface Engineering

Provide the services of an existing system in a new environment triggered by technology enabler or new market

needs

Usually performed:

Requirements engineering

Requirements analysis

System delivery.

Validation criteria:

    Completeness:

All possible scenarios, in which the system can be used, are described, including exceptional behavior by the

user or the system.

Like: bank customer gets all cash money account Will close or not.

I feel with completeness according customer talk about future of next version.

Consistency:

There are functional or nonfunctional requirements that contradict
each other

-Portioning user in categories (users, customer-GM-) and it will be different in its requirement.

-If I have contradiction I can make face to face meeting and handling this contradiction or ignore this point

view if this contradiction with business role.

Clarity:

A requirement cannot be interpreted in to mutually exclusive ways.

-Check requirement that have clarity in rights of function with other colleague.

Correctness:

The requirements represent the client’s view. Check requirement with user.

Realism:

Requirements can be implemented and delivered. Requirement is logical=can implement.

Verifiability:

Repeatable tests can be built to demonstrate that the system fulfills the requirements specification.

    The product shall have a good user interface

    The product shall be error free

    The product shall respond to the user within 1 second for most cases.

Verify all requirements May by more than 1 type of design and by how to do it? To be aware related

Requirement if I have change

Traceability:

Each system function can be traced to a corresponding set of functional requirements.

Like: Save how to do it by (CTRL+S, File>save) we must document requirement with option to know what is

Related requirement.

Requirements change very fast during

Requirements elicitation → Validation is hard during elicitation.

Tool support for managing requirements:

• Store requirements in a shared repository
  
• Provide multi-user access
  
• Automatically create a system specification document from the repository
  
• Allow change management
  
• Provide traceability throughout the project lifecycle
  

Requisite Pro from Rational

http://www.rational.com/products/reqpro/docs/datasheet.html

——————————————————————————–

environment independent from implementation

Nonfunctional requirements:
User visible aspects of the system not directly related to

functional behavior.

Constraints (”Pseudo requirements”): Imposed by the client or the environment in which the system operates

• Functionality: Clear Function in Model.
  
• Usability: Malty of use and easy to use (user view).
  
• Performance: Mainly we mean time.
  
• Dependability:
  
  • Reliability: Trust in model that can do its function any time.
    
  • Robustness: Model can capable of overload of not.
    
  • Safety: of using system under most probable environment.
    
• Supportability: Effort and time to maintain and support (developer view).
  
  • Adaptability: Change function usage.
    
  • Maintainability: Change request.
    
• And OTHER
  

1.B.1-What is usually not in the requirements?



System structure, implementation technology

    Development methodology

    Development environment

    Implementation language

    Reusability

*It is desirable that none of the above are constrained by the client. Fight for it!

Don’t accept any of this constrains until customer have very strong reason.

1.A-Current Situation: The Problem to Be Solved

What is the problem in the current situation?

    Examples:

    the response time when playing letter-chess is far too slow. (Change SW for new technology-new in solution domain-)

    I want to play Go, but cannot find players on my level. (Application domain)

What has changed? Why can we address the problem now?

there has been a change, either in the application domain or in the solution domain

    Change in the application domain

    A new function (business process) is introduced into the business

    Example: We can play highly interactive games with remote people

    Change in the solution domain

    A new solution (technology enabler) has appeared

    Example: The internet allows the creation of virtual communities.

1.B.0-Types of Requirements

    We must identify the:

Purpose of a system? : That determined which tools and technology I have to use.

System boundary: What is inside, what is outside the system and sub system?

Like:
saving account in ATM will be by ATM system or Bank system.


Requirements process consists of two activities:

    Requirements Elicitation:
-User Language-

Definition of the system in terms understood by the customer (”Problem Description”)

    Requirements Analysis: -Developer Language-

Technical specification of the system in terms understood by the developer (”Problem Specification”)

• Define system boundary is often difficult?
  

Difficult to get specific and right system processes

So we can do it by dealing with more than categories of user (Customer-Manager- and system user)

with different back ground.

• How to make function Model?
  

  Ask user in
  scenarios
  like examples of what is action and interaction happened to do process x?
  

But this not all ways to do this process, this is only 1 scenario.

So
we need to have more scenarios that declare relevant and irrelevant

in (system and Function-Use Case-).

1. Problem Statement Generation: export (problem Statement, Requirements Elicitation).
   
2. Problem Statement Document: define system purpose and boundary.الورق المستخدم فى المناقصة
   
3. Requirements Elicitation: export Step 4 and written with (user Lang.). مثال: العمارة عاوزها شكله …و الوجهة….
   
4. System Specification Model: represent model with (user language) describe user view.
   
   

   Natural Language can be understood by more mean Like (Boy (No) Girl).
   

5. Requirements Analysis: -will going throw it in chapter 5- but we going on between (elicitation and analysis)
   

   
   According to prosperity or not until we get clear requirement and make
   

6. Analysis Model: represent clear and specific model by graphical language UML
   

or formal and semiformal lang..

1. Understand requirements.
2. Determined needed from requirements (Function).
3. Determined if needed is possible or not as logic.

    

• And begin in steps of dealing will complexity (abstract-decomposition-hierarchy).

Designer: deal with models to
determined details of models that needed
(if it declared or not).

To deal with Complexity
we have 2 ways (function Decomposition-Function oriented-, object oriented)

Function Decomposition: partitioning system to function to be understandable (use case).

Object oriented: deal with obj. and details of use case (Class diagram and dynamic behavior).

Software Lifecycle Questions

• Which activities should I select for the software project?
  
  • According to life cycle type.
    
    • What are the dependencies between activities?
      
    • How should I schedule the activities?
      
  • Estimate right time for project.
    
    • What is the result of an activity?
      
  • Result of activity is the only role that to determined which finished and not from life cycle.