For the Thursday I had nothing planned for learning, since I spent my night watching Perseids out of the city.

Knowledge Evaluations is very close, so I just reviewed all of the items I should know for it.

To lot leave this post empty, I decided to write at least about something. I feel, that I still have some weak areas like Networking. But it turns our that for .NET Desktop Profile, I need only basic knowledge of it, like understanding networking itself, application layer protocols, IP, TCP, UDP, SMTP, and so on and so forth. So for my luck I have basic ideas how all of that works and glues the world together.

Networking

We often use these abbreviations, but do we always know what they mean?

local area network (LAN)
wide area network (WAN)
metropolitan area network (MAN)
personal area network (PAN)
virtual private network (VPN)
campus area network (CAN)
storage area network (SAN)
Simple Mail Transfer Protocol (SMTP)
Multipurpose Internet Mail Extensions (MIME) 
User Datagram Protocol (UDP)
… what more??

In the evening there will be post about how KE went and what are outcomes.

P.S. I feel myself very nervously at the moment…

Today is the second day when I spend some evident time on preparing to my knowledge evaluation. For today I had Engineering Management, Requirements and OOD.
Engineering Management is something that I read few articles on wikipedia and OOD is something that is not possible to learn per one night. So regarding Requirements I noted only few things.

Requirements

Requirements is very important part of the process of building software. The better and cleaner requirements you get – the better understanding of the system and its design you create; the better you communicate requirements to development team – the better product will be built. And what is the most important as per me – you can evaluate requirements before you started developing something and find out if it is feasible.

So how can requirements look like?

• Business Requirement – defines needs from software that can help reach goal of the business.
• User Requirement – defines how people (users) will interact with system and what should it do from their perspective.
• Functional Requirements – define functional specification to the system, developers must build to satisfy the other requirements.
• Quality of Service Requirement – performance, scalability 

Evaluating the Requirements for the Application

• Requirement perspectives
• Unambiguous
• Complete
• Necessary
• Feasible

I’m preparing to the Knowledge Evaluation, which should let me get next step in my career. Today I spent about 5 hours on learning the Communication area of requirements for me. I read dozen different articles and reviewed many presentations. Very important part of communication is Team communication and Coaching, but I’m off for sleep. Indeed want to write something about it. You just need kick me to do that next week. Here in this post you will see some random lists on different communication items created or mixed from other resources by me.

All of us know how that is critical to be competent in written communications, specially with client, so while preparing I created some lists of things to be remembered.

Be clear in your e-mails:

• Keep in mind your reader
• More verbs instead of nouns 
• Concrete, not abstract 
• More active instead of passive 
• Making sense – managing stress (Put old or known information at the beginning of the sentence and new or complex information at the end)
• Be simple (Foggy phrasing often reflects foggy thinking)

Requirements

Software Requirements documents consist with:

• Introduction (Purpose, Scope, Definitions, References, Technologies, Overview)
• Overall Description (Use-Case Model, Architecture Diagrams, Assumptions and Dependencies)
• Specific Requirements (Use-Case Reports, Supplementary Requirements)
• Supporting Information,
• Concerns if any

Questionnaire

• Short
• Target carefully
• Start with interesting questions
• Limit, or avoid, the use of open-ended questions
• Put your questions in logical order

Meeting Minutes

Meeting minutes document what occurred at the meeting. They are not an opportunity to present a position or to add new materials and comments.

Format of Meetings Minutes should follow the agenda closely:

• Date & Time, Place of meeting, Attendees
• Purpose of Meeting
• Each issue addressed and highlights of the discussion
• A notation of any materials handed out at the time
• Outcome or decisions made

Always attach copies of materials distributed at the meeting or note where to find
them.

Proposals

Should have Executive Summary and answer for the following questions:

• Why are you doing this project?
• What will you be doing?
• How will you be doing it?
• Who will be doing it?
• Where will it be done?
• How long will it take?
• How much will it cost?

Conference calls

I’m sure that you can anourmous amount of information on how you can effectively provide your conference calls.

Here is my own list:

• Be always prepared for the call. Have pen & paper handy.
• If you do a call or if you receive a call, always know what is the purpose of it and if right persons are selected.
• Be honest and oriented to help, never say that it is not your job or policy.
• Track if meeting goes by agenda, direct and drive when needed.
• Try to exceed expectations, ask something like “While you’re on the line would you like me to…”
• Always have summary of the call outcomes in the end.

 If this is bad post, let me know.