You look good or you are good!!

Being is desirable because it is identical wih Beauty, and Beauty is loved because it is Being....We ourselves possess Beauty when we are true to our own being; ugliness is in on going over to another order; knowing ourselves, we are beautiful; in self-ignorance, we are ugly. - Plotinus

Some days back a friend of mine said to me," You look good!" I appreciated the compliment, of course, but I also felt a little amused. I almost wanted a reply." What do you mean? I am good." Some people are mostly concerned with the looking good.We should not be content with that.If we want a compliment, we should be good and then others will say "You are good".

"You look good and You are good" - both sentences have a marked difference.Today, it is said that the image has become the person.If the public realtions people can make you look good, you come to believe that you are good.

We should never allow ourselves to emulate or admire images that merely look good.Whether in sports or entertainment or politics, celebrities offer good role modles only when they stand for lasting values. Coutresy (Words To Live - By E.Easwaran)

Writing Effective Project Requirements - By Jim Swanson

Writing effective project requirements is one of the most important stages in any project development. Following article by Jim Swanson throws some light how to write the effective project requirements.
Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Importance of Requirements
Requirements are considered by many experts to be the major non-management, non-business reason projects do not achieve the "magic triangle" of on-time, on-budget, and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies, have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems, the most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst's dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn't ask, the stakeholder doesn't state requirements.The requirements phase is also considered by many experts to be the most difficult part of any project due to the following:

1 ) Business people and IT people tend to speak different "languages."
2 ) Business: "It has been determined that if we convolute the thingamajig or maybe retroactive the thatamathing, our profitability may, if we are extremely lucky, rise beyond the stratospheric atomic fundermuldering."
3 ) In other words, English is an ambiguous language, and we tend to speak and write in a manner that makes it even more ambiguous, convoluted, and unclear.

Building Valid Requirements

The requirements analyst truly is responsible for the failure or success of the requirements on a project. With that at stake, building valid requirements up front is crucial. The four steps to this goal are: elicitation, analysis, specification, and validation.

Elicitation

The term elicitation is the industry-accepted term for getting the requirements from the stakeholders. Elicitation, however, implies much more than just capturing or gathering the requirements from users.The truth is, one of the surest ways to fail in requirements is to say to your users, "Give me your requirements," then stand back and "catch" them.Why doesn't this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

Analysis

Analysis involves refining (or analyzing) the stakeholder requirements into system, then software requirements. Analysis is a critical step, that is too often omitted or bypassed in projects.Analysis is the critical transition from stakeholder or business terminology, to system or IT terminology. For example, stakeholders talk about "Monthly Marketing Report," while systems talk about file "MoMktRpt.doc."Analysis involves brainwork, but it is not a magic process (nor is any other part of software engineering, for that matter). Analysis is usually done in conjunction with various modeling techniques. Modeling-creating diagrams using standard notations-allows analysts to more fully understand processes and data in a rigorous manner. This understanding allows them to convert the often non-rigid stakeholder requirements into more concise, rigid system and software requirements.Common modeling techniques include the following:

1 )Traditional systems
2 ) Dataflow diagrams to understand processes and activities
3 ) Entity-relationship diagrams to understand data
4 ) Object-oriented systems:
5 ) UML (Unified Modeling Language) diagrams, especially class diagrams for analysis, but also possibly collaboration diagrams

Specification

The specification sub-phase involves documenting the requirements into a well-formatted, well-organized document. Numerous resources are available to help with writing and formatting good requirements and good documents. For general writing assistance, books on technical (not general) writing should be used. A major resource is the set of IEEE Software Engineering Standards

Validation

Once a requirements specification is completed in draft form, it must be reviewed both by peers of the author and by the project stakeholders in most cases. If detailed stakeholder requirements were written and signed off by the stakeholders, they may not need to participate in reviews of more technical system and software requirements. This presumes good traceability matrices are in place.The specifications are reviewed by a group of people to ensure technical correctness, completeness, and various other things. Often checklists are used to ensure all requirements in all possible categories have been elicited and documented correctly.Validation is actually a quality assurance topic. All documents produced throughout a project should undergo validation reviews.

Accepting change and its impacts

It has been quite often seen that people resist change very stubbornly, even when its for their own benefit. The main reason being that change generally provokes physiological discomfort. Change is something that pressurizes us out of our comfort zone. That is the reason why all of us are a little hesitant towards it.

So, how well does one agree to this famous quote by Charles Darwin - "It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change."Agreed! One important reason why we should change is because it helps to reduce monotony in life. Change the way you think, change you wardrobe, change you room settings and see the impact it will have on you. When you change something at the onset, you might feel bad about it but gradually you start accepting the change and hence start adoring it. For instance the other day when I was asked to change my seating place in office I felt a little repressive about it but gradually with the advent of time I became quite comfortable. So perceive change as an important aspect of life. Many a times we don’t accept change because we don’t want to be out of our comfort zone. We should recognize change as boon.

Change does bring us out of our comfort zone because with change comes the need to grow and hence adapt. Recognizing change helps us have a sense of rising and hence allows us face the challenge of life. It increases our confidence and builds our ability to deal with whatever life tosses our way. Change helps us to be at our best. Resisting change is constrictive and deadens energy. So, always change for the good and feel the difference in your life.